Closed Bug 1128397 Opened 6 years ago Closed 6 years ago

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

Categories

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

x86_64
Windows 8.1
defect

Tracking

()

VERIFIED FIXED
mozilla39
Tracking Status
firefox37 --- wontfix
firefox38 --- verified
firefox39 --- verified

People

(Reporter: cpearce, Assigned: jya)

References

(Blocks 1 open bug, )

Details

Attachments

(1 file, 1 obsolete file)

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.
Priority: -- → P2
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.
Assignee: nobody → jyavenard
Attached patch Work around EOS detection in MSE (obsolete) — Splinter Review
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
Attachment #8570199 - Flags: review?(matt.woodrow)
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?
Attachment #8570199 - Flags: review?(matt.woodrow) → review+
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.
Attachment #8570199 - Attachment is obsolete: true
https://hg.mozilla.org/mozilla-central/rev/afa562ac56af
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
Blocks: 1141333
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.
Attachment #8570332 - Flags: approval-mozilla-aurora?
Attachment #8570332 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
QA Whiteboard: [good first verify]
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]
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]
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.