[Live-devel] Clarification on Live555

Ross Finlayson finlayson at live555.com
Mon Jun 11 15:32:01 PDT 2012


> We are streaming (over Wifi ) H264 encoded frames from a live source using the reference of testH264VideoStreamer class. Camera frame rate is 30 fps.
> Receiver is an iOS application referenced from testRTSPClient class.
>  
> We are able to stream with Initial propagation delay around 200ms but after a duration of 20 minutes we are observing a scenario in which we are not receiving any frames (afterGettingFrame is not getting called) in the receiver side for some very small duration(200-250 ms), and then a large propagation delay (more than 1 sec) is being observed in streaming. This scenario is being repeated every time.
>  
> We are trying to analyze the Live555 Source code to any solution for above

You are almost certainly on a "wild goose chase" here.

Delays like this are almost always due to buffering inside the operating system (and/or its device drivers).  It's important to understand that the LIVE555 code does not include any buffering of outgoing packets.  Nor does it delay the processing of incoming packets (except for a delay of 100 ms (by default) whenever a lost packet is detected, to allow for the possibility of the 'missing' packet arriving later, out-of-order; this is the "fThresholdTime" code).

It is especially noteworthy that you are streaming IP multicast over WiFi.  By default, WiFi networks use a lower bit rate for multicast traffic.  (Depending upon your network, it may be possible to increase this, though.)

(As always, you are assumed to be using the latest version of the LIVE555 code...)


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120611/125c9a09/attachment.html>


More information about the live-devel mailing list