[vlc-devel] Earlier frame displayed despite start-time option?

brezhoneg1 brezhoneg1 at yahoo.fr
Thu May 16 21:59:14 CEST 2013


    I also noticed this issue. Actually vlc starts buffering (by 
default, 300ms for local files) for start-time  0.  Then, when this 
buffering is terminated, the seek control with the initial start-time 
provided by the user is fetched, the seek is issued and a second 300 ms 
buffering is then performed.

   In the source code, it seems this first buffering could be avoided if 
the check for controls was performed prior to starting a first demux 
rather than after doing it. Or, if not possible, at least the seek for 
this initial start-time should be performed first thing if different from 0.

   As for the reason why only one frame is seen, this is because all 
frames are retained at the decoder level till the end of buffering, all 
frames but the first video frame that is allowed to reach the display as 
soon as it is decoded. I guess this makes the system more responsive 
from a user's viewpoint if buffering takes too much time, and it also 
allows for seeking while in pause mode and maybe other reasons ...

   Anyway, the solution would rather be to avoid the entire first 
buffering and, as a consequence, the issue you describe would be solved.


Le 16/05/2013 19:42, Jérôme Forissier a écrit :
> Hello,
> I have observed a suspicious behavior with the start-time option (I think).
> I call libvlc_media_add_option to add "start-time X", before starting playback (libvlc_media_player_set_media and libvlc_media_player_play).
> Unexpectedly, my displayFrame callback receives a frame that obviously belongs to the beginning of the video before it gets the video from the requested offset. This frame is typically displayed for a short duration (a fraction of a second), but it can be longer depending on the video file. I guess this is the time it takes to seek to the requested frame. In any case this is always noticeable.
> This can be reproduced with the command line, for instance :
>    /Applications/VLC.app/Contents/MacOS/VLC test.mp4 --start-time=20.5
> (using VLC 2.0.6 on MacOSX 10.6.8)
> Looks like a bug to me. What do you think?
> Any suggestion for a fix or a workaround?
> Thanks,

More information about the vlc-devel mailing list