[Live-devel] RTP/H264 low latency streaming + source, change

[Stéphane SARAGAGLIA]

Le 15/06/2010 01:00, live-devel-request at ns.live555.com a écrit :
>> I am using Live555 libraries to stream H264 video provided by a
>> >frame grabber, via RTP (not RTSP).
>> >I use VLC and VLC activeX as a RTP/H264 client.
>> >
>> >Sometimes, I need to change the camera used by the framegrabber, so
>> >I close the RTP sink, the framer, the source, and I open them again
>> >with the new video. Doing that, (even with the same video
>> >parameters), the client often hang (but not every time), and
>> >sometimes go on playing again but with a big delay.
>> >How can I prevent the client from freezing the video or display the
>> >video with delay ? Sending some missing frames ? Special trick to
>> >warn client ?
>> >My main objective is LOW latency, some image skips are not a problem.
> I suspect that your problem is caused by the fact that each sending
> camera (server) necessarily uses a different RTP timestamp base, and
> so when you switch to receiving from a new camera, the received
> data's presentation time will briefly be inaccurate, until you
> receive a new RTCP "SR" packet from the new source.  (I'm assuming
> that your servers send RTCP as well as RTP; because you're using our
> software, that should be the case.)
>
> One way to reduce this problem is to increase the average RTCP
> sending frequency, which you can do by increasing the "totSessionBW"
> parameter that you pass to "RTCPInstance::createNew()".  (This
> parameter is intended to represent the stream's bitrate in kbps.  It
> is used - by the RTCP code - to figure out how often to send RTCP
> packets.)

Oups...
I have not set up a RTCP flow. Just RTP.
The fact is that in my case the streaming client cannot reach the 
streaming server (simplex communication). So I guessed RTCP should not 
be used.

Thank-you for your advice, I am going to try playing with RTCP (even in 
simplex session) and timestamps.

Regards