Is MSE remove() for in-band text cues fully spec'ed and implemented per spec? |
||||
Issue descriptionI'm wondering if the in-band text + MSE spec and implementation has a problem: 1. Buffer some cues at time [0,10). Play them. At that point, MSE SourceBufferStream -> media text_renderer -> Blink cuetimeline have been populated with the inband MSE text cues. 2. Now, do MSE SourceBuffer.remove(all the time range containing those cues). I suspect the blink cuetimeline still contains those cues though. I'm not sure this is fully spec'ed either. I'd assume that app-buffered cues via VTT file in track element or explicitly TextTrackCue additions to the TextTrack shouldn't be removed by MSE SourceBuffer.remove(...), but those from in-band MSE coded frame processing should be removed. Unlike a/v where the media demuxer owns the buffered timeline, text cues are owned by blink cuetimeline IIUC, and populated from in-band into that timeline when media pipeline reads from the text stream.
,
Oct 11 2016
Matt, did you file the bug for yourself? :)
,
Oct 12 2016
Spec is at https://html.spec.whatwg.org/multipage/embedded-content.html#sourcing-in-band-text-tracks In https://github.com/whatwg/html/issues/597 there are links to some track-related issues with much discussion, but maybe not this specifically. Something similar for audio and video tracks is in the spec: "If at any time the user agent learns that an audio or video track has ended and all media data relating to that track corresponds to parts of the media timeline that are before the earliest possible position, the user agent may queue a task to first remove the track from the audioTracks attribute's AudioTrackList object or the videoTracks attribute's VideoTrackList object as appropriate ..." Also removing whole TextTracks or some of the cues might be appropriate. I have a feeling this was discussed at some point, and an issue is that the individual cues are exposed to scripts and can be modified arbitrarily. That means either keeping track of where each cue came from, or just removing cues in a time range, which could also remove other cues that were added there. That's probably fine, tough, just need to define the precise timing and rules for removal.
,
Apr 28 2017
,
Mar 27 2018
Impl side, this may become moot soon: see bug 826419.
,
Mar 27 2018
|
||||
►
Sign in to add a comment |
||||
Comment 1 by yini...@chromium.org
, Oct 10 2016