Bugzilla

This is the same situation as bug 1909750.

When the new sample interval does not [overlap any existing sample start time](https://searchfox.org/mozilla-central/rev/6ad5adeba2b4353c53fd3c714223becd78cda029/dom/media/mediasource/TrackBuffersManager.cpp#2475-2486,2490), no overlapping frames are removed and so [no dependent frames are removed](https://searchfox.org/mozilla-central/rev/6ad5adeba2b4353c53fd3c714223becd78cda029/dom/media/mediasource/TrackBuffersManager.cpp#2542-2555), which is consistent with the corresponding [Coded Frame Processing steps](https://w3c.github.io/media-source/#sourcebuffer-coded-frame-processing).

Not even dependencies of [truncated overlapping frames](https://searchfox.org/mozilla-central/rev/6ad5adeba2b4353c53fd3c714223becd78cda029/dom/media/mediasource/TrackBuffersManager.cpp#2506-2507,2520) are removed.

`CheckNextInsertionIndex()` might be [assuming that the truncation should have introduced a gap in `mBufferedRanges`](https://searchfox.org/mozilla-central/rev/6ad5adeba2b4353c53fd3c714223becd78cda029/dom/media/mediasource/TrackBuffersManager.cpp#2305-2310), but that did not happen due to bug 1909750.

In this case, there is a gap in `mBufferedRanges` between a key frame and some of its depended frames, presumably small and due to rounding of timestamps and durations.  The insertion index is set to correspond to this gap, so the inserted frame separates dependent frames from their keyframe, which the [failing assertion](https://searchfox.org/mozilla-central/rev/6ad5adeba2b4353c53fd3c714223becd78cda029/dom/media/mediasource/TrackBuffersManager.cpp#1838-1841) was asserting would not happen.

I don't know whether the new frame should be inserted in decode timestamp order, separating dependent frames from their keyframe, or before the next keyframe so that dependent frames are adjacent to their keyframe.

Or perhaps there is a bug in the spec and dependent frames of truncated frames should be removed, which was my expectation before reading the spec.

This is ~~the same~~ a similar situation ~~as~~ to bug 1909750.

When the new sample interval does not [overlap any existing sample start time](https://searchfox.org/mozilla-central/rev/6ad5adeba2b4353c53fd3c714223becd78cda029/dom/media/mediasource/TrackBuffersManager.cpp#2475-2486,2490), no overlapping frames are removed and so [no dependent frames are removed](https://searchfox.org/mozilla-central/rev/6ad5adeba2b4353c53fd3c714223becd78cda029/dom/media/mediasource/TrackBuffersManager.cpp#2542-2555), which is consistent with the corresponding [Coded Frame Processing steps](https://w3c.github.io/media-source/#sourcebuffer-coded-frame-processing).

Not even dependencies of [truncated overlapping frames](https://searchfox.org/mozilla-central/rev/6ad5adeba2b4353c53fd3c714223becd78cda029/dom/media/mediasource/TrackBuffersManager.cpp#2506-2507,2520) are removed.

`CheckNextInsertionIndex()` might be [assuming that the truncation should have introduced a gap in `mBufferedRanges`](https://searchfox.org/mozilla-central/rev/6ad5adeba2b4353c53fd3c714223becd78cda029/dom/media/mediasource/TrackBuffersManager.cpp#2305-2310), but that did not happen ~~due to bug 1909750~~.

In this case, there is a gap in `mBufferedRanges` between a key frame and some of its dependent frames, small and presumably due to rounding of timestamps and durations.  The insertion index is set to correspond to this gap, so the inserted frame separates dependent frames from their keyframe, which the [failing assertion](https://searchfox.org/mozilla-central/rev/6ad5adeba2b4353c53fd3c714223becd78cda029/dom/media/mediasource/TrackBuffersManager.cpp#1838-1841) was asserting would not happen.

I don't know whether the new frame should be inserted in decode timestamp order, separating dependent frames from their keyframe, or before the next keyframe so that dependent frames are adjacent to their keyframe.

Or perhaps there is a bug in the spec and dependent frames of truncated frames should be removed, which was my expectation before reading the spec.