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

xxcv xxcv07 at gmail.com
Sat Jul 18 03:37:03 CEST 2009


git version control wrote:
> vlc | branch: master | Laurent Aimar <fenrir at videolan.org> | Thu Jul 16 14:50:16 2009 +0200| [2f9d9766dfe25f100ef04d0d812aebdd18401c0d] | committer: Laurent Aimar 
>
> Let the input bufferize more data when possible.
>   
Hi,
I just noticed that ... now vlc will take "a bit longer" to finish 
quitting it seems to be waiting for more data to come.
Time is increased between "main decoder debug: removing module 
"avcodec"" and "main input debug: releasing aout".
For a HD clip it took approximately 1.5 seconds (or more) to finish 
quitting vlc.exe process with a lot more decoder warnings.
 > main decoder warning: can't get output picture

 > main decoder debug: thread times: real 0m10.375000s, kernel 
0m0.046800s, user 0m9.344459s
 > avcodec decoder debug: ffmpeg codec (SVQ-3 (Sorenson Video v3)) stopped
The binary is with --disable-optimize-memory support.
>  The input will try to read 20% faster the source until a certain amount
> of data is buffered by the fifo of the decoders (for now 10Mbytes or
> 500kbytes when OPTIMIZE_MEMORY is defined for the sum of all fifos).
>   
This problem affects "avcodec" decoder.
>  This buffering adds up to pts_delay without any additional delay but can
> only work when VLC controls the source pace.
>   
Shutting down got delayed. Is it possible that video decoders get killed 
at first priority?
>  It has a drawback with the current way the meta data works: they are seen
> too soon.
>   
So that it won't have to wait for more data?




More information about the vlc-devel mailing list