In bug 261994, we added a 1s audio webm file made of 0.5s of audio with 40ms packets and .5s of audio with 20ms packets. While the file plays and no longer error, audio playback quality is bad. The reason for this is that we have small gaps between each packets due to incorrect muxing, as the gap quickly adds up to be over 15ms, we stop correcting them. This is an audio only file, there's no A/V sync to be worried about, we shouldn't attempt to smooth the gap; we could completely ignore the container timestamps and entirely rely on the number of frames decoded so far.
<rdar://problem/115929491>
it was an issue in the frame size calculation done in bug 261994. *** This bug has been marked as a duplicate of bug 261994 ***