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 bo
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.
On Sep 18, 2014 6:14 PM,
> 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.
> here is my command line
>
> ./OpenRTSP -v -Q -D 1 -n rtsp://: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
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://:554/11 | ffplay -loglevel
