OpenRTSP stream delay increasing with time

[Muhammad Ali]

I am using OpenRTSP to open an RTSP stream (IP Camera) and send it to
ffplay using Unix Pipes as input. I see the video playing which is roughly
1 to 1.5 sec delayed than live (Direct RTSP stream view of IP Cam) .

here is my command line

./OpenRTSP -v -Q -D 1 -n rtsp://<IP>:554/11 | ffplay -loglevel verbose
-fflags nobuffer -i pipe:0

Now this delay slowly keeps increasing from 1.5 sec upto 4~5 seconds in
about 20 minutes. And I assume it will continue to increase with time.

So my questions are :-
1 - what is causing the initial delay ?
2 - Why does that delay keeps increasing ?

Is there a way to disable "pre caching" of frames in OpenRTSP ?

I compare the delay by watching two videos of the same IP camera. One is
configured at angelcam.com and other I view locally via the above command
line.
Surprisingly, it is always Local stream that gets delayed. Angelcam stream
keeps functioning as it started.

Any help ?

[Ross Finlayson]

Post by Muhammad Ali
here is my command line
./OpenRTSP -v -Q -D 1 -n rtsp://<IP>:554/11 | ffplay -loglevel verbose -fflags nobuffer -i pipe:0
Now this delay slowly keeps increasing from 1.5 sec upto 4~5 seconds in about 20 minutes. And I assume it will continue to increase with time.
So my questions are :-
1 - what is causing the initial delay ?

I don't know, but it's not "openRTSP". (Our RTSP/RTP client software does not include any buffering, or significant delay.) The delay is probably some combination of the OS pipe (i.e., the "!") and "ffplay" itself (i.e., the decoding/rendering overhead).

Post by Muhammad Ali
Is there a way to disable "pre caching" of frames in OpenRTSP ?

There's no such thing.

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

[Ross Finlayson]

Post by Ross Finlayson
I don't know, but it's not "openRTSP". (Our RTSP/RTP client software does not include any buffering, or significant delay.) The delay is probably some combination of the OS pipe (i.e., the "!"

Oops, I meant 'the "|"', of course (I typed the wrong character).

Post by Ross Finlayson
) and "ffplay" itself (i.e., the decoding/rendering overhead).

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

[Muhammad Ali]

My next question would be what if some RTP packets are delayed? How will
the client behave? Will it wait for "x" seconds and continue. If it waits
then there will be a delay that may be carried on to the next time the
packets are delayed. Maybe that's where the delay is.

Post by Ross Finlayson
I don't know, but it's not "openRTSP". (Our RTSP/RTP client software does
not include any buffering, or significant delay.) The delay is probably
some combination of the OS pipe (i.e., the "!"
Oops, I meant 'the "|"', of course (I typed the wrong character).
) and "ffplay" itself (i.e., the decoding/rendering overhead).
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
http://lists.live555.com/mailman/listinfo/live-devel

[Ross Finlayson]

No. Our code delivers data (in this case, to the OS pipe, and from there to your "ffplay" command) once it arrives. The 'increasing delay' that you're seeing has to be caused by your downstream code (your "ffplay" command) not consuming data fast enough. Either your "ffplay" command is CPU bound, or else it's displaying at a frame rate that's slower than that of the incoming data.

In the latter case, what might be happening is that your receiving computer's clock is running at a slightly slower rate than the sending computer's clock. In that case - because you're using a simple FIFO (i.e., pipe) feeding into your application (i.e., "ffplay") - there's nothing that you can do. (A more sophisticated media player application would typically start dropping frames once it noticed that its internal 'jitter buffer' was filling up (due to mismatched clock speeds).)


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