[wpt-sync] Sync PR 19461 - MSE: Prototype experimental new non-preemptive eviction policies
Categories
(Core :: Audio/Video: Playback, task, P4)
Tracking
()
People
(Reporter: wpt-sync, Unassigned)
References
()
Details
(Whiteboard: [wptsync downstream])
Sync web-platform-tests PR 19461 into mozilla-central (this bug is closed when the sync is complete).
PR: https://github.com/web-platform-tests/wpt/pull/19461
Details from upstream follow.
Matt Wolenetz <wolenetz@chromium.org> wrote:
MSE: Prototype experimental new non-preemptive eviction policies
Naming of the new eviction policies may change during discussion/feedback on the incubation
proposal/explainer, which also needs updating to reflect design decisions taken during
this prototype's development so far. Versus the explainer, this prototype:
Gives exception on changing the eviction policy after "first initialization segment
received flag" is true. Later spec smithing could re-allow this, for instance, to
switch back to "normal" to accomplish a (deterministic) seek, if this limitation is
undesired.Prevents seeking if using 'before-next-demuxed' eviction policy in an active SourceBuffer.
Seeking would introduce complexities such as indeterminate behavior especially if asynch
append, perhaps on worker context, is concurrent with seek, and seek evicts all
"partial GOPS" whose keyframes are no longer buffered. Later spec smithing could re-allow
this if such indeterminacy is non-prohibitive.Mechanism: HTMLME::seekable reports empty range if any activeSourceBuffer is using
before-next-demuxed.set,clearLiveSeekableRange unchanged, since the ::seekable logic for before-next-demuxed
returns early with empty rangeDoes not condition behavior relative to background suspend or track enable/disable; if the
'before-next-demuxed' evicts the keyframe for the current GOP, then resumption following
suspend or track re-enablement may require rebuffering (especially if there is no keyframe
that could satisfy the seek).
App-visible 'waiting' event should occur, as per usual playback stall requiring re-buffering
(or seeking if the GC mode allows that via non-empty seekable ranges). If app receives
'waiting' while currentTime is in a buffered range, it could be decoder underflow, or an
internal disabling/reenabling of the track without a keyframe nearby; difficult for app to
decipher. To reduce this confusion, multiple options might be considered for development,
including at least:
- If background track disable, explicit track disable, or (Android) WMPI suspend occurs,
rebuffering media beginning with a keyframe at currentTime will likely be required before
playback can proceed following track enable/WMPI resumption. Some mitigation might be to
prevent stream disabling related to background video track optimizations for players
using MSE with any SourceBuffer using the 'before-next-demuxed' eviction policy.- Alternatively, use the existing tracks selected/deselected + eventing when any explicit (or
implicit-due-to suspend/resume or backgrounded-video-optimization) track changes occur. This
would probably require a bit of work to ship AudioVideoTracks RuntimeEnabled feature beyond
experimental, and connect the implicit track enable/disable select/deselect behavior into
the corresponding track(s) in Blink to emit those events.- Also, upon internal preroll when track ever becomes re-enabled, if the seek to begin preroll
cannot find keyframe before the seek time, yet that time is within a buffered range, then
perhaps consider dropping the partial GOP containing the seek time, such that app can detect
lack of it being buffered.- Also, since the "before-next-demuxed" mode chains to "normal" mode if not enough is evicted
to make room, consider automatically evicting partial GOP containing currentTime for disabled
tracks when in "before-next-demuxed" mode and doing the prepare append algorithm's GC. This
would enable more proactive visibility of real "buffered" for disabled tracks, assuming an
append of any size, even 0, had been done just prior, to the SourceBuffer containing the
disabled track(s) in "before-next-demuxed" mode.Explainer:
https://github.com/wicg/media-source/blob/mse-eviction-policies/mse-eviction-policies-explainer.mdBUG=963717
Change-Id: I33c7839995a32dd490201c5b672a5e9bf946abc0
Reviewed-on: https://chromium-review.googlesource.com/1616976
WPT-Export-Revision: e99cc73c680c59b6d6d0268c8904d761b0fe21a9
|
Assignee | |
Updated•6 years ago
|
|
|
Assignee | |
Comment 1•6 years ago
|
||
|
|
Assignee | |
Comment 2•6 years ago
|
||
|
|
Assignee | |
Comment 3•6 years ago
|
||
|
|
Assignee | |
Comment 4•6 years ago
|
||
|
|
Assignee | |
Comment 5•6 years ago
|
||
|
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Updated•5 years ago
|
|
||
Updated•3 years ago
|
|
|
Assignee | |
Updated•1 year ago
|
Description
•