MP4 video started with start-time displays the first frame before going to the start time

Steps to reproduce: Start a video from the command line with --start-time Expected behavior: the first frame displayed is at or near the start-time Actual behavior: the first frame of the video is displayed, then VLC goes to the start time

Example: run vlc.exe --start-time=4 start-time-issue.mp4 You should see the blue philips ad text But instead you see the actor for a frame, then the blue ad. Note that this can be hard to see, because the initial frame is shown only briefly.

Environment: Windows 7 VLC version 2.0.7 jb (June 7 2013 23:02:31)

Video for demoing start-time issue

Added attachment:

• start-time-issue.mp4

added Component::Core: Input label

Still happens on VLC 2.1.3.

Also on VLC 2.1.4

Original author: dmitry zamula

Is it possible to escalate this problem? So many other bugs have now been fixed, it's the one last thing stopping me from upgrading from 1.0.5 Goldeneye.

Replying to [comment:4 ukgeorge]:

Is it possible to escalate this problem? So many other bugs have now been fixed, it's the one last thing stopping me from upgrading from 1.0.5 Goldeneye.

Isn't that a bug that was always present?

It's true there can be the occasional funny with Goldeneye especially when what's being played hasn't yet been cached. But with 2.1.3 so far as I can see, the problem manifests itself every time without exception. Obviously if the first frame of the clip happens to be black, then you shouldn't notice it.

I did some research with versions from www.oldapps.com. ukgeorge is right, the defect is not there in 1.0.5 and earlier (also checked 1.0.0). But it is there in 1.1.0 and later (also checked 1.1.1, 1.1.3, 1.1.6, 1.1.11).

Is there anything else we can do to help with this?

Thanks!

I'm afraid it's a core bug, quite hard to fix...

I know this thread is a bit outdated, but I found the problem quite irritating.

I therefore managed to find a fix in the source code (v2.1.0 because it's the only Visual Studio compatible version I found).

The problem lies in the output video loop whoch requires the file to be read from the beginning before the actual "start" position is reached (the "seek" process). I found that whatever video codec it called, they all call a generic "video callback" signal to display the frames while it's read. I then managed to put a condition in the callback saying that if the current video timing has not reached the start frame, then nothing is displayed... and it actually worked.

I will try to submit a bug fix, hoping it'll be done in the next version!

Regards. Gorgo Treize.

The real fix is to process controls Mainloop once before demux on each new input item

mentioned in issue #17843 (closed)

mentioned in issue #19132 (closed)