Preroll selects the wrong frame when seeking before the first keyframe.
Reported by
qian...@gmail.com,
Feb 29 2016
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36 Example URL: Steps to reproduce the problem: Hi I found this issue with Chrome browser This is my browser user agent Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36 Please check this http://jsfiddle.net/k5qbjykp/ When you click play, the video hangs at very beginning, then it starts to play; click back to the beginning, video freezes. What is the expected behavior? What went wrong? The video should play smoothly Did this work before? No Is it a problem with Flash or HTML5? HTML5 Does this work in other browsers? Yes Chrome version: 48.0.2564.116 Channel: n/a OS Version: 6.3 Flash Version: Shockwave Flash 20.0 r0
,
Mar 4 2016
Seems like bad encoding; over to sandersd@ to double check.
,
Mar 7 2016
It is true that the encoding is bad (the first keyframe is frame 45, which is explicitly not valid for H.264). However, it's also surprising that playback freezes when seeking earlier than 3s when using software decoding. This file has an audio and video track, both starting at time zero, but no video keyframe until 3s. When playing back, the software decoder displays the 45th frame until audio catches up. When seeking before 3s, audio plays but video freezes until it catches up the the frame that was visible before seeking. This is consistent with dropping frames with an earlier timestamp, but it doesn't explain why preroll fails without a decode error. I'll leave this bug open and investigate a little more.
,
Mar 7 2016
,
May 1 2017
this bug has been stale since 4/1/2016. I am marking it as StaleAssigned now. If you still want to keep it, please replace StaleAssigned with StakeKeep. Otherwise, I will resolve it as won't fix. Thanks
,
Jun 12 2017
this bug has been stale for > 1 year. resolve them as won't fix. StaleClosed label is added. if the bug owner want to keep it, please r-activate an assign appropriately. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by yini...@chromium.org
, Mar 4 2016Labels: OS-Mac
Owner: dalecur...@chromium.org
Status: Assigned (was: Unconfirmed)