Closed Bug 1108787 Opened 8 years ago Closed 8 years ago
dispatch progress even when timer runs late
MediaDecoder::Progress() will dispatch a progress event if the repeating timer runs and data has been received with the most recent timer period. If data arrives soon after the previous timer ran and the next timer event runs late, then the data receipt may be ignored and a progress event may be skipped.
The key change here is replacing the now - mDataTime <= TimeDuration::FromMilliseconds(PROGRESS_MS) test with mDataTime > mProgressTime. There are some related tweaks to make the new test work out. The comment change to mention "first progress" is documenting existing behavior. The spec wording "every 350ms (±200ms) or for every byte received, whichever is least frequent" is not clear on whether the first progress event should be fired at the beginning or end of the 350ms interval, but this patch does not change behavior there.
Attachment #8533367 - Flags: review?(cpearce)
Not directly related to this bug, but easy to do while here. Precision is not required, and is more costly on some platforms.
Attachment #8533368 - Flags: review?(cpearce)
Attachment #8533367 - Flags: review?(cpearce) → review+
Attachment #8533368 - Flags: review?(cpearce) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/6ff5dad95494 https://hg.mozilla.org/integration/mozilla-inbound/rev/e72d2f6bfa3a It may be possible to write a test for this with MSE, but the timing involved makes it difficult.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
You need to log in before you can comment on or make changes to this bug.