Bugzilla

https://pernos.co/debug/jm31IX8m_dYmE21IFNorXA/index.html records a case where a zero-duration sample is appended when truncated by `appendWindowEnd`.
This happens because the (microsecond resolution) append window end is [converted to the sample time base after intersection](https://searchfox.org/mozilla-central/rev/6ad5adeba2b4353c53fd3c714223becd78cda029/dom/media/mediasource/TrackBuffersManager.cpp#2187-2188).

Arguably, the zero-duration sample might be a better approximation of the behavior expected by the client, but `mAppendWindow` is [rounded to microseconds](https://searchfox.org/mozilla-central/rev/5f641898e12dafdfb7d54a93f4f3164d2c1642b2/dom/media/mediasource/TrackBuffersManager.cpp#234-237) and so does not provide a true indication of what the client is requesting.

The spec allows dropping such a truncated frame:
> [If frame end timestamp is greater than appendWindowEnd, then set the need random access point flag to true, drop the coded frame, and jump to the top of the loop to start processing the next coded frame.](https://w3c.github.io/media-source/#sourcebuffer-coded-frame-processing)
> Some implementations MAY choose to collect coded frames with presentation timestamp less than appendWindowEnd and frame end timestamp greater than appendWindowEnd and use them to generate a splice across the portion of the collected coded frames within the append window at time of collection, and the beginning portion of later processed frames which only partially overlap the end of the collected coded frames. Supporting this requires multiple decoders or faster than real-time decoding so for now this behavior will not be a normative requirement. In conjunction with collecting coded frames that span appendWindowStart, implementations MAY thus support gapless audio splicing.

https://pernos.co/debug/jm31IX8m_dYmE21IFNorXA/index.html records a case where a sample is appended even though truncated to zero-duration by `appendWindowEnd`.
This happens because the (microsecond resolution) append window end is [converted to the sample time base after intersection](https://searchfox.org/mozilla-central/rev/6ad5adeba2b4353c53fd3c714223becd78cda029/dom/media/mediasource/TrackBuffersManager.cpp#2187-2188).

Arguably, the zero-duration sample might be a better approximation of the behavior expected by the client, but `mAppendWindow` is [rounded to microseconds](https://searchfox.org/mozilla-central/rev/5f641898e12dafdfb7d54a93f4f3164d2c1642b2/dom/media/mediasource/TrackBuffersManager.cpp#234-237) and so does not provide a true indication of what the client is requesting.

The spec allows dropping such a truncated frame:
> [If frame end timestamp is greater than appendWindowEnd, then set the need random access point flag to true, drop the coded frame, and jump to the top of the loop to start processing the next coded frame.](https://w3c.github.io/media-source/#sourcebuffer-coded-frame-processing)
> Some implementations MAY choose to collect coded frames with presentation timestamp less than appendWindowEnd and frame end timestamp greater than appendWindowEnd and use them to generate a splice across the portion of the collected coded frames within the append window at time of collection, and the beginning portion of later processed frames which only partially overlap the end of the collected coded frames. Supporting this requires multiple decoders or faster than real-time decoding so for now this behavior will not be a normative requirement. In conjunction with collecting coded frames that span appendWindowStart, implementations MAY thus support gapless audio splicing.