Re: TextTrack questions

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?
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.
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?
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?

Aaron


>
> eric
>
>
>
> >
> > On Sat, Jan 18, 2014 at 3:56 AM, Eric Carlson <eric.carlson@apple.com>
> wrote:
> >>
> >> On Jan 16, 2014, at 6:17 PM, Philip Jägenstedt <philipj@opera.com>
> wrote:
> >>
> >> How about every time the buffered
> >> ranges change in MSE, all cues for in-band tracks which do not overlap
> >> with the new buffered ranges are thrown out? (Out-of-band and
> >> script-created tracks would best be left alone I think.)
> >>
> >>
> >>  Would we only want to do this for MSE? What about live streams or very
> >> long downloaded files, where we may end up with a huge number of cues in
> >> memory for time ranges which are no longer buffered?
> >>
> >> eric
> >>
> >>
>
>