1117903 - 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

Status: RESOLVED WONTFIX

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

Description

[Bobby Holley (:bholley)]

See the bottom of bug 1093133 comment 12.

Comment 1

[Bobby Holley (:bholley)]

Anthony, do we have any reason to believe that this can't happen? What priority should it be?

Comment 2

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

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.

Comment 3

[Karl Tomlinson (:karlt)]

(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

Comment 4

[Ralph Giles (:rillian)]

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

Comment 5

[Jean-Yves Avenard [:jya]]

This issue can't occur with the new MSE architecture, marking it as WONTFIX for the old MSE.