[vlc-devel] commit: Let the input bufferize more data when possible. (Laurent Aimar )

[xxcv]

Laurent Aimar wrote:
>  Are you sure it is related to this commit?
>   
I think so (at least happened to my build).
I reverted this patch then the problem is gone but this problem is much 
more likely to happen to me
because I'm using ffmpeg-mt which isn't supported and quit takes longer 
when compared to trunk-NB
and trunk-NB quit takes longer when compared to 1.0.
This takes more longer time if FPS is higher then normal (double) and 
when the codec is avc1 or svq-3
>  The commit does not force waiting for more data, it just lets the input
> read the file a bit faster until enough data are buffered. It should not
> slowdown VLC in anyway.
>   
I just downloaded the NB of "vlc-1.1.0-git-20090719-2203" and then tried 
with some HD files again.

Also noticed there's a little bit more delay.

I also noticed that if the picture is frozen (lots of late picture) 
during this time when pics are frozen closing vlc is instantaneous
This mean that 0 buffers left ?
without any (main decoder warning: can't get output picture).
 > main video output warning: late picture skipped (9065 > -21570)
 > main libvlc debug: deactivating the playlist
 > main playlist debug: Deactivate
However if the picture is not frozen then the remaining buffers (counts) 
will still need to be processed by the core which is the exact cause of 
this problem during this time it displays many
until buffers are all processed (I guess).
 > main decoder warning: can't get output picture
So if there are any more remaining buffers left to be read it will still 
play it (but couldn't get any picture probably because the buffers are 
not valid anymore)
that's why there are so many increased decoder warning during quit.
>  Does it happens with a local file? Could you test with multiple types of
> files?
>   
I tested only with local files this seems to only bother the decoder 
module avcodec and I am not sure why.

> Regards,
>
>