We stream lots of live MJPEG streams using a pretty simple client that is based on the testRTSPClient example. In very rare cases we see a delay/lag that I can't explain.
When it happens it is like the live video is delayed 2s. If I at the time start the same stream in VLC and specify a cache of 2000ms the videos play in sync. The thing is that we don't buffer anything, and the fact that any other instance of our program, or any other player, shows the video live tells me it's not the server. The instance where the delay can be seen will continue to do show the delay for all following streams (using the same live555 event loop), i.e. if I switch to another stream the delay is still there. It should be noted that the video plays smooth (no visible frame dropping), just that there is a consistent 2s lag. As mentioned, this is very rare and I've only seen it twice in the last four months, so it's not something that I can recreate. I didn't think live555 really buffer anything, but when trying to look for any explanation at all to this "magic delay" I stumbled upon some old posts that mention a buffer used for sorting RTP packages that are received out of order. It also mentions that setPacketReorderingThresholdTime() can be called to minimize this time. I believe we have quite a bit of packet loss and I will try to check this out, but since we can't reproduce the issue it's like a ghost hunt and it would be great to get some feedback on this. - Is there any possibility that a "delay" (>1s) can somehow be introduced in live555 (e.g. during heavy packet loss)? - Has anyone else experienced any delayed live streams like this? /Claes
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
