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)
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.
Comment 2•8 years ago
|
||
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!/
Comment 4•8 years ago
|
||
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.
Updated•8 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago → 8 years ago
Resolution: --- → WONTFIX
Comment 5•8 years ago
|
||
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.
Description
•