- From: Philip Jägenstedt <philipj@opera.com>
- Date: Wed, 22 Jan 2014 10:06:03 +0700
- To: Aaron Colwell <acolwell@google.com>
- Cc: Eric Carlson <eric.carlson@apple.com>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, public-html <public-html@w3.org>
On Wed, Jan 22, 2014 at 3:31 AM, Aaron Colwell <acolwell@google.com> wrote: > > On Tue, Jan 21, 2014 at 8:05 AM, Eric Carlson <eric.carlson@apple.com> > wrote: >> >> >> On Jan 17, 2014, at 6:38 PM, Philip Jägenstedt <philipj@opera.com> wrote: >> >> > I hadn't thought about those case either. It would be nice (simple) to >> > just say that for all in-band tracks, when the buffered ranges are >> > updated, evict all cues which now do not overlap the buffered ranges. >> > Is that going to break something? >> > >> >> That does seem like the simplest (to implement and understand)) solution >> to this issue. >> >> I don’t know of anything that it will break. > > > I have a few questions about this: > > 1. Does "evict all cues" include ones added by JavaScript or just the ones > added by the inband track? All cues. If you don't want to lose them, put them in a script-created track or keep them around to re-insert later when that regions becomes buffered again. > 2. For out-of-band tracks is the application expected to remove cues from > unbuffered regions? I'm mainly thinking about a live broadcast where cues > are inserted by JavaScript instead of in-band. I don't think we should throw away cues for out-of-band or script-created tracks, no. The application will have to throw them away if it's an infinite stream. > 3. I'm assuming "when the buffered ranges are updated" is evaluated on a per > track basis and not actually what the HTMLMediaElement exposes since removal > of text track data does not necessarily imply removal of audio/video data. > Am I understanding the intended meaning correctly? I did mean HTMLMediaElement.buffered. AudioTrack/VideoTrack/TextTrack don't expose buffered ranges, so I'm not sure what the alternative would be. Do you mean something with SourceBuffer.buffered or some spec-internal concept I'm forgetting? > 4. MSE overlapping appends should be treated as a time range becoming > "unbuffered", so old cues are removed, and then "buffered" with the new cues > being appended. Right? So, assuming that an overlapping append causes HTMLMediaElement.buffered to modified at a time when scripts can observe it, yes, there would be an opportunity to evict cues. Basically, I think the HTML spec should have a hook that is run anytime that a script accessing .buffered would see something different than it did before that point. I haven't checked if that's implementable in an efficient way though, if one calculates the buffered ranges lazily on request then we have a problem... Philip
Received on Wednesday, 22 January 2014 03:06:31 UTC