Closed Bug 1345808 Opened 8 years ago Closed 8 years ago

Video seek is broken if seek out of buffer

Categories

(Core :: Audio/Video: Playback, defect)

51 Branch
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: n1k1ta8613, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 Steps to reproduce: - open video stream http://1006734.nvtest.web.hosting-test.net/manifest.mpd in any demo player, e.g.: http://dashif.org/reference/players/javascript/1.4.0/samples/dash-if-reference-player/ - start video playback - seek out of buffer Actual results: only audio continues playback from new position Expected results: Synced video/audio should continue from new position. It is not reproduced in firefox 50 or in chrome. Looks related to these changes: https://bugzilla.mozilla.org/show_bug.cgi?id=1300296
Another option is to have possibility to disable behavior added in Bug 1300296: P2. Don't rely on MP4 container to properly report if a frame is a keyframe.
Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core
Or a better possibility is that you fix your invalid MP4 file by properly remuxing the content so that keyframes are properly marked as such and then regenerate the manifest so that timestamps are correct. You have overlapping and gap in the segments added. Per spec: https://w3c.github.io/media-source/index.html#sourcebuffer-coded-frame-processing "6. If last decode timestamp for track buffer is set and decode timestamp is less than last decode timestamp: OR If last decode timestamp for track buffer is set and the difference between decode timestamp and last decode timestamp is greater than 2 times last frame duration: ... 5. Set the need random access point flag on all track buffers to true. " so the need random accesspoint flag is set, no new frame will be added until a keyframe (a real one) is seen. So you end up with a buffered range that has only audio, and playback will stall as per spec. (you won't get that only audio is playing) Having said that, while frames are incorrectly tagged, if you let playback go to the end without seeking it works all fine. Seeking is mostly fine too, the bulk of bad frames is around the 1 minute mark
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
Hi, thank you for quick reply. As I can see from 1300296 comments the motivation was to fix errors after seek if frame wrongly marked as key-frame. But according to h264 decoder can use SEI recovery points (are not on IDR frames) to decode valid picture and use it as a seek point. Does it mean that seek will not work properly in Firefox for such videos? Related discussions/commits in vlc and ffmpeg: http://git.videolan.org/gitweb.cgi/vlc.git/?a=commit;h=33778d4d8c5d4b53793bdfe699315dac4e5baf68 http://ffmpeg.org/pipermail/ffmpeg-devel/2009-December/062992.html Looks like something similar with detection of correct key-frames was done in chrome: https://chromium.googlesource.com/chromium/src/media/+/a3349c1718dab71b3896390fb90b9d5c086fb2f5%5E!/
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
We're at the mercy of what the H264 decoder provided by the OS supports. Not all supports this, you'll get the same behaviour in Edge or Safari or even with some hardware decoder (as would chrome use). ffmpeg supports things other decoders don't. Seeking will work, just that it will always seek starting from a valid IDR.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago8 years ago
Resolution: --- → WONTFIX
note that i can perfectly seek in your video sample... the only time there was a stall was when it took a while to download the segment.
You need to log in before you can comment on or make changes to this bug.