We correctly discard Opus CodecDealy (ffmpeg decoder) and DiscardPadding (audio discard helper), but we do account for this in FrameProcessor, nor when reporting buffered ranges.

This manifests in a few ways.

1. Buffered time appears longer than it should (it includes the CodecDelay, which is not really a part of the media timeline)

2. Append window trimming is imprecise. 

The frame processor doesn't know that the encoded timestamps its seeing need to be rebased to subtract CodecDelay.

appendWindowStart almost works. Because the timestamps haven't been rebased yet, frame processor will save buffers in the CodecDelay + buffers after the appendWindowStart boundary. But buffers that straddle the boundary will need use discard padding, and this will not work in AudioDiscardHelper which only applies discard padding when decoder output is not delayed by more than one buffer.

appendWindowEnd: trims too much. Because codec delay has not been subtracted out, frame processor will discard buffers a little before it should.