[FFmpeg-user] RTSP stream: long delay to start video

[Roger Pack]

On 12/19/12, Dâniel Fraga <fragabr at gmail.com> wrote:
> On Tue, 18 Dec 2012 21:53:01 -0700
> Roger Pack <rogerdpack2 at gmail.com> wrote:
>
>> So you think it fixed one problem and introduced another? which commit was
>> it?
>
> 	I sent this message to Marton Balint too.
>
> 	Roger and Tom, thanks for replying. The commit which introduces
> the delay to start the RTSP stream is this one:
>
> 3166a6fc379789b3782f431dd232033c2069c443 is the first bad commit
> commit 3166a6fc379789b3782f431dd232033c2069c443
> Author: Marton Balint <cus at passwd.hu>
> Date:   Sun Oct 14 00:47:15 2012 +0200
>
>     ffplay: if there is no audio stream, use external clock by default
>
>     Otherwise playing the video could be much slower than realtime if the
> system
>     can't decode or display the frames fast enough.
>
>     Signed-off-by: Marton Balint <cus at passwd.hu>
>
> :100644 100644 95a6ac4635f227c7d72edf2ee6b3bd75ca0d87f6
> c6cf880ccc2c3090749c00508e8a037977c98cbe M      ffplay.c
>
> 	***
>
> 	The problem is: Marton Balint knows about it, but he's taking
> too long to fix it. Is there some other developer interested in this bug?
>
> 	To sum up: after this commit, ffplay takes 10 seconds to start
> the stream. As the description says, it is for streams without audio, but
> even
> that is wrong because ffplay is not detecting the audio stream also.

So this commit fixed another bug but introduced the latency? Did it
detect the audio stream before? Do other players detect the audio?
does setting analyzeduration help?
(Barring that, you could go into the heart of the ffplay code and try
and figure out why it's taking so long, or maybe run it with -loglevel
debug and see if it outputs anything useful/interesting?)