1108787 - dispatch progress even when timer runs late

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[Karl Tomlinson (:karlt)]

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.

Comment 1

[Karl Tomlinson (:karlt)]

Attachment: dispatch progress even when timer runs late

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.

Comment 2

[Karl Tomlinson (:karlt)]

Attachment: use NowLoRes() for progress event timing

Not directly related to this bug, but easy to do while here.

Precision is not required, and is more costly on some platforms.

Comment 3

[Karl Tomlinson (:karlt)]

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.

Comment 4

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/6ff5dad95494
https://hg.mozilla.org/mozilla-central/rev/e72d2f6bfa3a