1128397 - 480p video doesn't not enter ended state at end

Status: VERIFIED FIXED

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

Description

[Chris Pearce [:cpearce (Not reading bugmail)]]

STR:
1. Open https://www.youtube.com/watch?v=Yu7GPWS2FKE and select 480p quality stream.
2. Either watch through the video, or seek to near the end and then play back the last few seconds.
3. Once playback reaches the end, open the web console, and enter this js:
document.getElementsByTagName("video")[0].ended

Expected Result: true
Observed Result: false.

On other videos in this series, and on lower quality streams on this video, this error does not happen.

Comment 1

[Matt Woodrow (:mattwoodrow)]

The video track is 177739us shorter than the audio track for the stream.

MediaSourceReader::IsNearEnd is using 125000us as the fuzz factor to determine if we've reached the end, so we're failing this test and think that more data needs to be appended.

Comment 2

[Jean-Yves Avenard [:jya]]

Attachment: Work around EOS detection in MSE

layman approach at handling audio and video having different duration. Should we be in ended mode, and close to the sourcebuffer.buffered.end(), treat it as EOS

Comment 3

[Matt Woodrow (:mattwoodrow)]

Comment on attachment 8570199 [details] [diff] [review]
Work around EOS detection in MSE

Review of attachment 8570199 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/media/mediasource/MediaSourceReader.cpp
@@ +1062,5 @@
> +    aType == MediaData::AUDIO_DATA ? mAudioTrack : mVideoTrack;
> +  nsRefPtr<dom::TimeRanges> buffered = new dom::TimeRanges();
> +  trackBuffer->Buffered(buffered);
> +  if ((mMediaSourceDuration - buffered->GetEndTime()) * USECS_PER_S <= 2 * EOS_FUZZ_US) {
> +    return aTime >= buffered->GetEndTime() * USECS_PER_S - EOS_FUZZ_US;

Why do we need the fuzz for this comparison? Since we're using the end time of the track buffer that aTime relates to, then it should be exact if we're done, right?

Comment 4

[Jean-Yves Avenard [:jya]]

Attachment: Work around EOS detection in MSE

Carrying r+, I used std::floor on the value, because I don't want to get caught with rounding error with the double value again.

Comment 5

[Jean-Yves Avenard [:jya]]

remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/afa562ac56af

Comment 6

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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

Comment 7

[Ralph Giles (:rillian)]

Comment on attachment 8570332 [details] [diff] [review]
Work around EOS detection in MSE

Approval Request Comment
[Feature/regressing bug #]: MSE
[User impact if declined]: Spec compliance, difficultly uplifting later changes.
[Describe test coverage new/current, TreeHerder]: Landed on m-c some time ago.
[Risks and why]: Risk is low. This only affects MSE and has had plenty of time to bake.
[String/UUID change made/needed]: None.

Comment 8

[Ralph Giles (:rillian)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/d543a39ac7b2

Comment 9

[Mohammad Maruf Islam]

I have reproduced this bug with Firefox Nightly 38.0a1(Build: 20150201030209)on windows 8.1 pro x64 with the instructions from comment 0 .

Verified as fixed with Firefox release 38.0.5(2015-02-01) (Build ID: 20150525141253)

 Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0

Verified as fixed with Firefox beta 39.0 (Build ID : 20150601171003) 
 	
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0

[bugday-20150603]

Comment 10

[Mohammad Maruf Islam]

I have reproduced this bug with Firefox Nightly 38.0a1(Build: 20150201030209)on windows 8.1 pro x64 with the instructions from comment 0 .

Verified as fixed with Firefox release 38.0.5(2015-02-01) (Build ID: 20150525141253)

 Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0

Verified as fixed with Firefox beta 39.0 (Build ID : 20150601171003) 
 	
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0

[bugday-20150603]