<div dir="ltr"><div>Thanks for the info. From reading your linked threads, it seems I should contact the camera manufacturer (hiQview) and tell them they should modify their cameras to send smaller NAL units. I'm often seeing some 150KB NAL units, so I had set my buffer to 300KB just for safety. Assuming the hardware manufacturer doesn't give me an overnight firmware update to fix it (highly unlikely!), for now I'll stick with 300KB buffer and try to get testRTSP working as well as openRTSP does. I did notice that openRTSP calls:<br>    subsession->rtpSource()->setPacketReorderingThresholdTime();<br></div>And also<br>    setReceiveBufferTo()<br><div>Whereas testRTSPClient doesn't call those.<br><br>So perhaps that's what I need. Let me know if you can think of anything else that might cause a difference, but if not I'll try the 2 functions above and let you know how it goes.<br><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><span>Cheers,<br>Shervin Emami.<br>Senior Embedded Vision Engineer,<br>DIB Australia.<br></span><span>1/41 Botanical Drive,<br>Labrador, QLD 4215<br>Australia<br>+61 431 845 843<br><a href="http://dibaustralia.com.au/" target="_blank">http://dibaustralia.com.au/</a><br><br></span></div></div></div></div></div>
<br><div class="gmail_quote">On 23 December 2015 at 13:25, Ross Finlayson <span dir="ltr"><<a href="mailto:finlayson@live555.com" target="_blank">finlayson@live555.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> When I run "openRTSP -b 300000 rtsp://<a href="http://192.168.2.101" rel="noreferrer" target="_blank">192.168.2.101</a>" on the H.264 stream of my IP camera it works perfectly, but when I tried modifying testRTSPClient to do the equivalent (ie: saving NAL packets to a H264 raw bitstream file), it works perfectly sometimes but occasionally the video looks broken.<br>
<br>
</span>(Argh, this is not going well.  Resending again.)<br>
<br>
...From what I can tell (from your description of your modification to “testRTSPClient”), there should be *no* difference between the behavior of “openRTSP” and your modified “testRTSPClient”, in this case.  I suspect that you’ve been running your modified “testRTSPClient” more often than “openRTSP”, and that if you ran “openRTSP” more often, you’d see the issue there as well.<br>
<div class="HOEnZb"><div class="h5"><br>
Does your H.264 video stream really have NAL units that are close to 300000 bytes in size?? If so, then that’s the problem.  NAL units this large are *much* to large to be streamed over RTP.  They should instead be encoded as a sequence of smaller ‘slice’ NAL units.<br>
<br>
Please read<br>
        <a href="http://lists.live555.com/pipermail/live-devel/2015-November/019773.html" rel="noreferrer" target="_blank">http://lists.live555.com/pipermail/live-devel/2015-November/019773.html</a><br>
and the links therein.<br>
<br>
<br>
Ross Finlayson<br>
Live Networks, Inc.<br>
<a href="http://www.live555.com/" rel="noreferrer" target="_blank">http://www.live555.com/</a><br>
<br>
<br>
_______________________________________________<br>
live-devel mailing list<br>
<a href="mailto:live-devel@lists.live555.com">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>
</div></div></blockquote></div><br></div>