[vlc-devel] Earlier frame displayed despite start-time option?
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 :
> 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?
More information about the vlc-devel