See the bottom of bug 1093133 comment 12.
Summary: If an MP4 B-frame is in a different media segment than its I-Frame, we will block indefinitely trying to read the I-Frame → If an MP4 B-frame is in a different media segment than its I-Frame, we could block indefinitely trying to read the I-Frame
Anthony, do we have any reason to believe that this can't happen? What priority should it be?
The way B-frames work is that they have a presentation order that is different from the decode order. However they are only allowed to be out of presentation order within a GOF. According to the spec: http://www.w3.org/TR/2013/WD-media-source-20130129/#media-segment "Segments must start with a random access point to facilitate seamless splicing at the segment boundary." Given that a new keyframe (random access point) starts a new GOF I think we're covered.
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #2) > "Segments must start with a random access point to facilitate seamless > splicing at the segment boundary." That was removed in https://dvcs.w3.org/hg/html-media/rev/668a1c82fb88
In particular, this is for compatibility with Apple's Http Live Streaming. Sounds like we want to skip ahead to the next keyframe if we find we're missing data. "Media segments don't have to start with RAPs now. The splice happens at the first RAP, in each track, encountered in an append sequence." https://www.w3.org/Bugs/Public/show_bug.cgi?id=20899
This issue can't occur with the new MSE architecture, marking it as WONTFIX for the old MSE.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.