Re: TextTrack questions

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