Issue metadata
Sign in to add a comment
|
Incorrect frame shown at currentTime
Reported by
egorapol...@gmail.com,
Apr 13 2018
|
||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.91 Safari/537.36 Example URL: Steps to reproduce the problem: 1. Open bugreport.html file 2. Type timestamp 20.541 at the bottom of page and click "Set currentTime" button What is the expected behavior? "Encoded, contains B-frames" video should show frame with ice, hand and glass What went wrong? All videos shows frame with musicians. Did this work before? Yes 61.0.3163.91 / Ubuntu 16.04 x64 Is it a problem with Flash or HTML5? HTML5 Does this work in other browsers? N/A Chrome version: Channel: n/a OS Version: Flash Version: Contents of chrome://gpu: Explanation: 1. "Original" is H264-encoded file with Constraint Baseline profile in mp4. 2. "Encoded, contains B-frames" is "Original" file encoded using libx264 Main profile with 3 B-frames option. 3. "Encoded without B-frames" is libx264 Main profile with 0 B-frames option. Explanation: there is keyframe on 20.541. Extraction frame of timestamp 20.541 using ffmpeg utility produces frame with ice, hand and glass. ffmpeg utility version: $ ffmpeg -version ffmpeg version 3.3.4 Copyright (c) 2000-2017 the FFmpeg developers built with gcc 5.4.0 (Ubuntu 5.4.0-6ubuntu1~16.04.9) 20160609 Last time there was an issue with incorrect seeking on videos without B-frames there in #66631 issue. For Chrome 61 I encoded video with B-frames and that was a fix. Yesterday I got that issue again and researched bug list. Something similar is there in #810094 issue. Last comment recommended to encode without B-frames at all. As I see that didn't fix seeking problem in Chrome v65
,
Apr 13 2018
I'm not sure I understand. If the behavior change only affect the video with B-frames, and the behavior is now consistent with "correct", non-B-frame behavior, is the overall behavior not more correct now? Perhaps related is issue 810094, for which it looks like a rounding error may actually be responsible. Do small timestmap offsets significantly change your result? Thanks!
,
Apr 16 2018
I'd like to clarify the problem. Let's take pictures using ffmpeg utility from each video: ---------------------- $ ffmpeg -ss 00:00:20.541 -i encoded_contains_bframes.mp4 -vframes 1 -q:v 1 contains_bframes_ffmpeg_20.541.jpg $ ffmpeg -ss 00:00:20.541 -i encoded_without_bframes.mp4 -vframes 1 -q:v 1 without_bframes_ffmpeg_20.541.jpg ---------------------- You can see both pictures are about hands, ice and glass. Also let's analyse I-frame structure of each video: $ ffprobe -select_streams v -show_frames -of csv -show_entries frame=pkt_pts_time,pict_type encoded_contains_bframes.mp4 | grep I > contains_bframes_keyframe_list.log $ ffprobe -select_streams v -show_frames -of csv -show_entries frame=pkt_pts_time,pict_type encoded_without_bframes.mp4 | grep I > without_bframes_keyframe_list.log You can see there is keyframe at 20.541666 inside both video files. If you try to round currentTime to 20.542 you won't see ice picture but mans with guitars. So, what I see no one video shows correct picture, it doesn't matter there are B frames or not since releases later than Chrome v61
,
Apr 16 2018
I believe that this issue here is in edit list handling. These media files have an audio edit offset of 0.023s (1024 / 44100), meaning that the audio track begins with 0.023s of audio which should be discarded. (Note: this is unusual. It's much more common for audio to have no offset and for video to be offset by the first frame's composition offset.) Instead, the audio track start time is being computed as -0.023, which by the standard start time rules is shifted to time 0. We can confirm this by looking for where the first frame (black) switches to the second frame (visible logo), which turns out to be 0.064888s ~= (1 / 24) + (1024 / 44100). You can work around the issue in M65 by adding the audio edit offset to seek times.
,
Apr 17 2018
Did you mean the audio track start time was computed with Chrome player? I'm asking because ffprobe utility shows info about audio and video streams without any start time offsets. I've executed those commands: -------------------- $ ffprobe -show_format -show_streams -i encoded_contains_bframes.mp4 > contains_bframes_ffprobe_streams.log $ ffprobe -show_format -show_streams -i encoded_without_bframes.mp4 > without_bframes_ffprobe_streams.log -------------- Both media files have "start_time=0.000000" for each stream.
,
Apr 17 2018
ffprobe shows processed metadata, and it's not always easy to map to Chrome's interpretation, even though Chrome does use FFmpeg for demuxing. I recommend MP4Box.js's File Analyzer (http://download.tsi.telecom-paristech.fr/gpac/mp4box.js/filereader.html) for quickly inspecting MP4 metadata. The 'File Overview' tab includes a summary of the edit lists, and the raw track timestamps are summarized in the 'Sample View' tab.
,
Jun 14 2018
Thank you for nice tool, I've analyzed my files and confirmed your explanation. Is there any other alternative solutions instead of that front-end/JavaScript workaround you mentioned above? I mean can I use some encoding params in order to guarantee correct seeking? For example, I'm planning to use h.264 codec. Could you recommend which profile, level, b-frames setups e.t.c. will fix this issue? Another question: will be this problem fixed in next chrome build? Chrome v67 also contains this bug |
|||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||
Comment 1 by dalecur...@chromium.org
, Apr 13 2018Status: Assigned (was: Unconfirmed)