In bug 682141 we're tracking random failures of test_fragment_play. In this test we check the current time when playback of a media fragment ends. However the test is failing because playback is ending after the end of the media. Often we're ending ~8ms after the end time, less frequently it's ~17ms, and rarely playback is reaching the end without the media pausing at the fragment end time. We could implement fragments better to prevent the accuracy of our end time. Currently we compare the currentTime against the fragment end time in AdvanceFrame(), and pause playback if currentTime > fragment end time. But by the time the pause works its way through to the audio thread, we could have played quite a bit of audio (hence the test failure). I think the best solution is to change AudioLoop() to stop pushing audio to hardware after the fragment end time, then we can get sample-accurate fragments (at least in the case where we have audio). For further reference, initial implementation of fragments landed in these changesets: http://hg.mozilla.org/integration/mozilla-inbound/rev/dc1d14484d6e http://hg.mozilla.org/integration/mozilla-inbound/rev/1a1dbcc15b7e

> I think the best solution is to change AudioLoop() to stop pushing audio to hardware after the fragment end time, then we can get sample-accurate fragments (at least in the case where we have audio). Sounds good, I think I suggested something along these lines a while ago. Using AdvanceFrame() doesn't work if you have a low frame rate video with regular audio (e.g. slides with a voice over). I've linked to a 10 second per frame test video with a fragment of [15, 20.1] which should display 2 frames and play 5.1 seconds of audio, but ends up playing ~15 seconds of audio.

Mass closing do to inactivity. Feel free to re-open if still needed.