The generate_timestamps_flag-conditioned timestampOffset update implementation assumes that, if frame processing itself doesn't update timestamp_offset, then the predicted frame end timestamp (in SourceBufferState::OnNewBuffers()) should be used as the timestampOffset increment.

This over-increments timestampOffset if the bufferQueue ended with one or more frames completely dropped by appendWindow trimming.

When generate_timestamps_flag is true:
* The spec processes each frame using current timestampOffset, with PTS and DTS set to 0 before applying the offset, and (only if successfully processed and not dropped) updates the timestampOffset per each frame.
* Chrome processes a *sequence of frames* using currenttimestampOffset, with PTS and DTS beginning at 0 and increasing by frame duration (each sequence emitted from the MPEGAudioStreamParserBase resets the timestamp helper, so the next sequence (or after a config change) begins again with time 0). Chrome then assumes that, either FrameProcessor detected a discontinuity (or handled entry into sequence mode from segments mode) and updated timestampOffset accordingly; and if no discontinuity, it assumes the last frame in the sequence made it through processing successfully. This last bit is faulty, because appendWindow{Start,End} trimming can drop complete frames, including that last frame.

Note, this issue was found during code inspection. I'm unaware of this issue causing problems for web authors, but it is a compliance issue not currently covered by any tests.