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

VERIFIED FIXED in Firefox 38

Status

()

defect
P2
normal
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: cpearce, Assigned: jya)

Tracking

(Blocks 1 bug)

unspecified
mozilla39
x86_64
Windows 8.1
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox37 wontfix, firefox38 verified, firefox39 verified)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

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.

Updated

4 years ago
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)

Updated

4 years ago
Assignee: nobody → jyavenard
(Assignee)

Comment 2

4 years ago
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+
(Assignee)

Comment 4

4 years ago
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.
(Assignee)

Updated

4 years ago
Attachment #8570199 - Attachment is obsolete: true
https://hg.mozilla.org/mozilla-central/rev/afa562ac56af
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
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]

Updated

4 years ago
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.