RemovedFromMediaSource (and perhaps MSE + HTMLMediaElement specs) doesn 't explicitly shut down streams |
||
Issue descriptionWhen MediaSource is transitioning to 'closed' readyState, or when the MSE app makes a valid removeSourceBuffer() call, and the tracks associated with the SourceBuffer(s) have enabled audio track(s) or selected video track, then the specs appear to leave the state of the media element with respect to continued rendering of previously buffered media a bit underdefined. This bug tracks investigation of specs and impl to clarify intended behavior.
,
Nov 8 2017
When a SourceBuffer is removed from MediaSource the flow goes: WebSourceBufferImpl::RemovedFromMediaSource -> ChunkDemuxer::RemoveId (which destroys the corresponding SourceBufferState by removing it from the map at https://cs.chromium.org/chromium/src/media/filters/chunk_demuxer.cc?rcl=905e5b5cd96bfd7dd5b51525cad1d398c7850f10&l=721) -> ~SourceBufferState -> SourceBufferState::Shutdown, which puts all streams/tracks owned by that SourceBuffer[State] into SHUTDOWN state. And when a track is in SHUTDOWN state the EOS for reads is returned here: https://cs.chromium.org/chromium/src/media/filters/chunk_demuxer.cc?rcl=905e5b5cd96bfd7dd5b51525cad1d398c7850f10&l=436
,
Nov 8 2017
Ah that makes sense. And even better, it's not conditioned on any flag (even if on-by-default) like kBackgroundVideoTrackOptimization or media tracks enabled. Thanks for the rapid response, servolk@.
,
Nov 9 2017
|
||
►
Sign in to add a comment |
||
Comment 1 by wolenetz@chromium.org
, Nov 8 2017