Ambiguous behavior with Coded Frame Processing algorithm about media-source HOT 6 CLOSED

The proposal involves collapsing two frame removal steps (one with knowledge of frame decoding dependencies and one without) into one. I believe its most likely that implementations will fall into the latter type, and its best that it's requirements be explicitly stated (remove frames to the next random access frame).

from media-source.

@jdsmith3000, I tend to agree, though we perhaps shouldn't restrict implementations to not exercising their knowledge of decoding dependencies with finer granularity.
The proposal unifies the removal of decoding dependencies across steps 13 and 14 into the same logic in step 15. I like the proposal.

@jyavenard, regarding the proposal's side note that [removing all coded frames until the next random access point] 'doesn't appear to cater for B-frames found prior the "coded frames removed" and dependent on the frames removed. This could leave frames that can't be decoded in the track buffer.': the assumption in the spec is that the removal is done in decode, not presentation, frame order. Am I mistaken that there cannot be a B-Frame that depends on something with a decode time in the future?

from media-source.

From TPAC f2f for MSE today, sounds like there is good enough understanding to proceed with a pull request. @jyavenard and @jdsmith3000 please comment especially if you disagree with my comment 5 hours ago.

from media-source.

@wolenetz You can ignore my side note. At the time I had made that comment when I noticed our new implementation not working with a particular video file (which contained B-frame). I have since made the decision that it was incorrectly muxed.

@jdsmith3000 I do agree that I'd be extremely surprised if anyone implemented the detailed version for all possible data type, as it requires inner knowledge of some compression techniques and internal data; well out of scope for a web engine.. Having two different possible implementations, it also leaves room for discrepancy between implementation. So I'd be happy to see one removal option go. away.

from media-source.

Note that similar text (and I believe similar resolution to just the conservative alternative) exists in the coded frame removal algorithm. PR #62 now contains that fix as well, as of commit ddd5086.

from media-source.

PR #62 fixed this with commit 81b27bc

from media-source.