For example Mpeg 1 used 12 frames in an ipbbpbbpbbpb GOP (group of pictures) arrangement where i is an 'intra' frame which is effectively a jpeg still, a p is a predictive frame which encodes some movements between i and p frames, and b frames encode some spot fixups where the prediction didn't work very well. If you mean digital streaming and you want good compression ratios, ie 1080p over wifi, then you are out of luck if you want less than 100ms of latency with today's commodity hardware, because in order for a compression algorithm to give a good compression ratio, it needs a lot of context. If you need Over The Air streaming, this is the best low-latency option I've seen and it's very well thought out and the resolution will scale with hardware capability. Its latency can be under 63us (microseconds) ideally.įor digital streaming with quality approaching NTSC and a 40ms latency budget see rsaxvc's answer at 120hz. Well, for a really low latency streaming scenario, you could try NTSC. I would like to do a simple gui with a play and record button and 3 screens to stream from different video servers, I just don't know what kind of wrapper (which should be really fast) to use!
Since I am using ffplay currently, because it is the best so far. I am now getting higher than 100 ms which is not really efficient for me.
I would like to know if someone has a better suggestion about streaming a live stream with lower latency < 100 ms. To be honest, I don't know what kind of configuration I need to do it the gstreamer to get a lower latency.
The protocol I am streaming with is udp and I am getting a better values with ffplay than mplayer or gst-launch. I used different configuration values to get the lowest latency for each of them for example: ffplay -fflags nobuffer I tried gstreamer player (gst-launch-0.01), mplayer, totem and ffmpeg player (ffplay). I have been testing playing multiple live streams using different players because I wanted to get the lowest latency value.
0 kommentar(er)
