See the bottom of bug 1093133 comment 12.
3 years ago
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.