4 ms·
Interframes are not a problem, as long as they only reference previous frames, not future ones. I was able to get latency down to 50ms, streaming to a browser
by phoboslab 6y ago
Interframes are not a problem, as long as they only reference previous frames, not future ones.
I was able to get latency down to 50ms, streaming to a browser using MPEG1[1]. The latency is mostly the result of 1 frame (16ms) delay for a screen capture on the sender + 2-3 frames of latency to get through the OS stack to the screen at the receiving end. En- and decoding was about ~5ms. Plus of course the network latency, but I only tested this on a local wifi, so it didn't add much.
[1] https://phoboslab.org/log/2015/07/play-gta-v-in-your-browser-sort-of https://phoboslab.org/log/2015/07/play-gta-v-in-your-browser...
- ekimekim 6y agoWouldn't you then hit issues where a single dropped packet can cause noticable problems? In an intraframe solution if you lose a (part of a) frame, you just skip the frame and use the next one instead. But if you need that frame in order to render the next one, you either have to lag or display a corrupted image until your next keyframe. I guess as long as keyframes are common and packet loss is low it'd work well enough.
- wmf 6y agoCorrupted frames happen; they're not too bad. You can also use erasure coding.
- deleted 6y ago[deleted]
- bob1029 6y agoIt's funny you mention MPEG1. That's where my journey with all of this began. For MPEG1 testing I was just piping my raw bitmap data to FFMPEG and piping the result to the client browser. I was never satisfied with the lower latency bound for that approach and felt like I had to keep pushing into latency territory that was lower than my frame time. That said, MPEG1 was probably the simplest way to get nearly-ideal latency conditions for an interframe approach.
- imtringued 6y agoInteresting. I guess I'll have to rewrite a lot of code if what you are saying is true.