<div dir="ltr"><div dir="ltr">Thank you all for your feedback. So with Ross's suggestion I implemented a rtsp client based on this live555 example: <a href="https://github.com/rgaufman/live555/blob/master/testProgs/testRTSPClient.cpp">https://github.com/rgaufman/live555/blob/master/testProgs/testRTSPClient.cpp</a>. The latency may have gone down a bit actually (looks like my client may have been at fault for some amount of latency). Now I am however experiencing some fairly significant artifacts on the screen when a video is playing over the screen. Any hints as to why that might be happening? </div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Dec 28, 2018 at 12:57 PM Warren Young <<a href="mailto:warren@etr-usa.com">warren@etr-usa.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Dec 28, 2018, at 10:31 AM, Ross Finlayson <<a href="mailto:finlayson@live555.com" target="_blank">finlayson@live555.com</a>> wrote:<br>
> <br>
> 1/ In your H.264 encoder - i.e., between the creation of a raw video frame, and the time that it is encoded into (one or more) H.264 NAL units.<br>
<br>
Ross didn’t go into any detail on this point, Kevin, so I thought I’d weigh in on it. <br>
<br>
I think this is the largest contributor to your stream’s latency. The simple fact is that H.264 is not designed as a low-latency codec. It can be *tuned* to be so, but only by throwing away most of its advantages over, say, MJPEG.<br>
<br>
Any time you introduce inter-frame compression — meaning that you need more than one frame in the decoder’s buffer RAM to decode at least some frames — you introduce a delay proportional to N * M where N is the inverse of frames per second in milliseconds and M is the maximum number of of frames needed.<br>
<br>
For 30 fps video, N is 33 ms.<br>
<br>
For H.264, M can vary considerably: <a href="https://planetcalc.com/3321/" rel="noreferrer" target="_blank">https://planetcalc.com/3321/</a><br>
<br>
If your encoder is configured to have a maximum reference frame span of 5 frames, and you’ve configured Live555 to send each frame out in true *streaming* fashion, then you can expect to have roughly 160 ms of latency minimum due to this factor alone. That’s human-scale latency!<br>
<br>
If you need to use H.264 and must achieve low latency, you’ll have to modify your encoder to use a very conservative GOP structure. Best to use no B frames at all.<br>
<br>
You can make an argument for no P frames, either. That is, I-frame-only video, like MJPEG, but with about 20 years of advancement on still picture coding, making it about 2x more efficient.<br>
<br>
Bottom line, TANSTAAFL. The high compression rate of an H.264 encoder tuned for low-bandwidth web streaming comes at a price, one facet of which is high latency.<br>
<br>
If you want an extreme counterexample for comparison, consider HD-SDI, which requires 1.485 Gbit/sec to send 1080p60 video, but it does so with as close to zero latency as is practical:<br>
<br>
<a href="https://en.wikipedia.org/wiki/Serial_digital_interface#Bit_rates" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Serial_digital_interface#Bit_rates</a><br>
<br>
You don’t get down into the single digit Mbit/sec range for the same frame size and frame rate without paying certain costs.<br>
_______________________________________________<br>
live-devel mailing list<br>
<a href="mailto:live-devel@lists.live555.com" target="_blank">live-devel@lists.live555.com</a><br>
<a href="http://lists.live555.com/mailman/listinfo/live-devel" rel="noreferrer" target="_blank">http://lists.live555.com/mailman/listinfo/live-devel</a><br>
</blockquote></div>