1847754 - Figure out what to do with the wav test disabled in test_played.html

Status: RESOLVED FIXED

(Core :: Audio/Video: Playback, defect)

Description

[Paul Adenot (:padenot)]

Looks like a couple things landed close together and there a new failure, I disabled a test while landing bug 1840399, to avoid backing everything out.

Here's a pernosco session of the problem: https://pernos.co/debug/2RQdWrkBySR7mbjHztf45Q/index.html#f{m[BHVD,Fbg_,t[AZg,LWM_,f{e[BHUZ,5Y0_,s{af0hBQAAA,bAZY,uED/IhA,oEG4A0A___/

What happens is that suddenly there's a very high resolution value in the TimeRanges returned by played, and it's not equal to the duration (it has a lot more decimals).

TEST-UNEXPECTED-FAIL | dom/media/test/test_played.html | test2-big-short.wav-7: end time shall be duration - got 1.1145578231292517, expected 1.114558

It goes like this:

MediaDecoderStateMachine::UpdatePlaybackPositionPeriodically

is called. We have this:

auto maxEndTime = std::max(VideoEndTime(), AudioEndTime());
auto t = std::min(clockTime, maxEndTime);

here, AudioEndTime() used to be microsecond precision with a time base of 1000000, but has now the correct base, for the sample-rate (her, 22050), now that the WavDemuxer uses TimeUnit in the proper base.

maxEndTime is lower than clockTime, so it's picked out of the two and now used as the playback position. This means a precise TimeUnit starts going back to content (it has demuxer-precision, so down to the sample-frame).

It goes up and up until it's returned by HTMLMediaElement::CurrentTime() and used as part of the right boundary of the interval in HTMLMediaElement::Played().

We should probably just reduce the precision of maxEndTime in the code above.

Interestingly, this wasn't failing on the 2nd of August so something else was hiding this problem.

Comment 1

[Paul Adenot (:padenot)]

NI Karl and Alwu because I'm not sure what was the patch that uncovered this.

Comment 2

[Paul Adenot (:padenot)]

Attachment: Bug 1847754 - Make the precision of current position in the state machine always use the same precision. r?karlt,alwu

Comment 3

[Alastor Wu [:alwu]]

Probably related with D184445 because we were always round down before.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ae42b747beff
Make the precision of current position in the state machine always use the same precision. r=alwu

Comment 5

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/ae42b747beff