Closed Bug 1272916 Opened 4 years ago Closed 4 years ago

MSE Sourcebuffer may reports contiguous buffered range but will stall attempting to play due to internal gap

Categories

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

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla49
Tracking Status
firefox47 + fixed
firefox48 --- fixed
firefox49 --- fixed

People

(Reporter: jya, Assigned: jya)

References

(Blocks 1 open bug, )

Details

Attachments

(1 file)

The issue can be seen with the http://streambox.fr/mse/hls.js.alt-audio/demo/ 

And even more so with this fragment:
https://people.mozilla.org/~jyavenard/hls.js/demo/?src=https%3A%2F%2Fpeople.mozilla.org%2F~jyavenard%2Fmediatest%2Fhls%2Fted%2Findex.m3u8&enableStreaming=true&autoRecoverError=true&enableWorker=true&levelCapping=-1

Playback will start but stall at 12s.

The buffered range reported is [0.08, 22.16]

The reason is that we have a 200ms discontinuity in the dts between the first 12s (TED announcement) and the actual video.

There is also a gap in the presentation range, however the gaps are smoothen out as we fuzz the content with +/- largest_duration_in_gop which happen to be here 161ms.

Which should stall playback and attempt to detect discontinuity if our public buffered range is contiguous, as the JS player has then no way of determining what's going on and for example skip over the gap.

This is blocking TED videos from switching from flash to HTML5/MSE videos.
[Tracking Requested - why for this release]: We have done most of the work in allowing TED and other sites to play properly using html5 in Firefox. This is the last blocker I hope.
See Also: → 1272959
Comment on attachment 8752563 [details]
MozReview Request: Bug 1272916: [MSE] P1. Don't rely only on dts gap to establish if we have a gap in our source buffer. r?gerald

https://reviewboard.mozilla.org/r/52640/#review49574

::: dom/media/mediasource/TrackBuffersManager.cpp:1992
(Diff revision 1)
> +  // Gap is too big. End of Stream or Waiting for Data.
> +  // TODO, check that we have continuous data based on the sanitized buffered
> +  // range instead.

Will you open a new bug to tackle this TODO?
Attachment #8752563 - Flags: review?(gsquelart) → review+
See Also: → 1272964
https://reviewboard.mozilla.org/r/52640/#review49574

> Will you open a new bug to tackle this TODO?

I will do so in my refactoring of data storage in TrackBuffersManager i have a bug opened for that already.
https://hg.mozilla.org/mozilla-central/rev/0f9a6f4ef56e
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
Comment on attachment 8752563 [details]
MozReview Request: Bug 1272916: [MSE] P1. Don't rely only on dts gap to establish if we have a gap in our source buffer. r?gerald

Approval Request Comment
[Feature/regressing bug #]: 1272916
[User impact if declined]: Stalls during playback
[Describe test coverage new/current, TreeHerder]: in central, manual testing, lots of mochitest
[Risks and why]: Very low, we have relaxed a test.
[String/UUID change made/needed]: None
Attachment #8752563 - Flags: approval-mozilla-beta?
Attachment #8752563 - Flags: approval-mozilla-aurora?
Comment on attachment 8752563 [details]
MozReview Request: Bug 1272916: [MSE] P1. Don't rely only on dts gap to establish if we have a gap in our source buffer. r?gerald

Media playback issues, Aurora48+, Beta47+
Attachment #8752563 - Flags: approval-mozilla-beta?
Attachment #8752563 - Flags: approval-mozilla-beta+
Attachment #8752563 - Flags: approval-mozilla-aurora?
Attachment #8752563 - Flags: approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.