[FFmpeg-trac] #10181(undetermined:reopened): Imprecise seeking in mp4 generated by ffmpeg.

[FFmpeg]

#10181: Imprecise seeking in mp4 generated by ffmpeg.
-------------------------------------+-------------------------------------
             Reporter:  Dale Curtis  |                    Owner:  (none)
                 Type:  defect       |                   Status:  reopened
             Priority:  normal       |                Component:
                                     |  undetermined
              Version:  unspecified  |               Resolution:
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Changes (by sroucheray):

 * status:  closed => reopened
 * resolution:  invalid =>

Comment:

 Hi, I am the reporter on 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.
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/10181#comment:2>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker