Imprecise seeking in mp4 generated by ffmpeg.

[Dale Curtis]

Summary of the bug:
Seeking to 10s yields frame for 10.10s.

Originally reported at: ​https://bugs.chromium.org/p/chromium/issues/detail?id=1410446

While the issue reproduces on tip of tree, reporter notes it doesn't happen with 4.4.2-0ubuntu0.22.04.1. However, when I checkout origin/release/4.4 I'm still able to reproduce, so I'm not sure what the Ubuntu version maps too.

How to reproduce:

% ffmpeg -t 60 -f lavfi -i color=c=black:s=1280x720 -c:v libx264 -tune stillimage -pix_fmt yuv420p -vf "drawtext=fontfile=DroidSansMono.ttf: timecode='00\:00\:00\:00': r=23.976: x=(w-tw)/2: y=20: fontcolor=white: box=1: boxcolor=0x00000099" -y output.mp4

% ffmpeg -ss 00:00:10 -i output.mp4 -frames:v 1 out-bad.png
Observe that out.png says "10:10" at the top instead of "10:00"

% ffmpeg -ss 00:00:09.6 -i output.mp4 -frames:v 1 out-correct.png

ffmpeg built today:
ffmpeg version N-109818-g8ed1d6b5e4 Copyright (c) 2000-2023 the FFmpeg developers
  built with gcc 12 (Debian 12.2.0-10)
  configuration: --enable-static --enable-libx264 --enable-gpl
  libavutil      58.  0.100 / 58.  0.100
  libavcodec     60.  0.100 / 60.  0.100
  libavformat    60.  0.100 / 60.  0.100
  libavdevice    60.  0.100 / 60.  0.100
  libavfilter     9.  0.100 /  9.  0.100
  libswscale      7.  0.100 /  7.  0.100
  libswresample   4.  9.100 /  4.  9.100
  libpostproc    57.  0.100 / 57.  0.100

[Dale Curtis]

File from reporter.

[Dale Curtis]

Incorrect timestamp.

[Dale Curtis]

Correct timestamp

[Balling]

That video has 6 keyframes, ffmpeg.exe -i output.mp4 -vf "select=eq(pict_type\,I)" -vsync vfr thumbnails-%02d.png

will extract all keyframes, and thumbnails-02.png has 00:00:10:10. That keyframe has best_effort_timestamp_time=10.000000 indeed. That is coded picture number = 250 (counting from 0, not 1). Open in YUView shows that 250 frame from 0 is 00:00:10:10.

That means your generated timestamp in the video is wrong, i.e. you use 25 fps video yet the timecode is for 24 fps.

[sroucheray]

Video with proper 25fps timecode burned in

[sroucheray]

Hi, I am the reporter of the Chromium bug. The original problem I had was that in Chrome when seeking to 1/25, the displayed burned TC in the video was 00:00:00:00. Which is not the case in Firefox (where it is well 00:00:00:01).

As you mentioned I did a mistake generating the video for the minimal test case. Sorry for that. So I regenerated a video with proper 25fps timecode, with command :

ffmpeg -t 60 -f lavfi -i color=c=black:s=1280x720 -c:v libx264 -tune stillimage -pix_fmt yuv420p -vf "drawtext=fontfile=DroidSansMono.ttf: timecode='00\:00\:00\:00': r=25: x=(w-tw)/2: y=20: fontcolor=white: fontsize=60: box=1: boxcolor=0x00000099" -y output25.mp4

With this example I have the exact same problem reproduced: seeking to 1/25 in Chrome lead to a displayed timecode 00:00:00:00. The problem is not present neither in Firefox nor in YUViewer though. But I have a similar problem in VLC pausing, seeking to 0, then pressing E for next frame, I am still at TC 00:00:00:00.

In Chrome you can open the file directly and in the devtools console type $('video').currentTime = 1/25

I have seen the same problem on many other videos.

I originally reported the problem in the Chromium bug tracker, but I am wondering if that could be a FFMPEG problem.

[Balling]

But I have a similar problem in VLC pausing, seeking to 0, then pressing E for next frame, I am still at TC 00:00:00:00.

VLC is buggy as hell. It is not at all surprising, VLC does not even have step backward. mpv works correctly (it has . and , buttons to step forward and backward) and so does MPC-HC (Ctrl-Left, Ctrl-right).

As for output25.mp4​ it works correctly: ffmpeg.exe -ss 00:00:00.01 -i C:\Users\ZAQU\Downloads\output25.mp4 -frames:v 1 out-b.png

as for chrome it switches between 0.040 (1/25 is 0.04000) and 0.040001, so you need to find out why is that, but 1/25 is not actual number used in Chrome. (1/25).toFixed(69)
'0.040000000000000000832667268468867405317723751068115234375000000000000'

[sroucheray]

Oh ! Thanks for your debugging and insights. Going back to Chromium bug.

[Balling]

I opened a bug. ​https://code.videolan.org/videolan/vlc/-/issues/27847

[Dale Curtis]

Thanks for debugging! Sorry I missed that the fps * time was incorrect.

[Balling]

VLC was fixed and backported even into ​https://code.videolan.org/videolan/vlc/-/commits/3.0.x and it will soon be here (not righ now, soon): ​https://artifacts.videolan.org/vlc-3.0/nightly-win64/