Re: track events.

Hi Sean,

This is indeed fascinating. I'll try and help with how I understand
how it works.

On Thu, Mar 3, 2011 at 4:44 AM, Sean Hayes <Sean.Hayes@microsoft.com> wrote:
> New Agenda item for today's call if possible.
>
> I have been attempting to implement the current Text Track API, and in particular the event mechanism and I've run into some issues with the current text which I'd like to discuss today; with a view to possibly raising some bugs on the current text.
>
> My understanding of the current text track api is that initially the text track's list of cues is empty. When the text tracks mode is set to anything other than disabled the track resource is fetched and cues may start to get added to the track.cues list.
>
> So far so good.
>
> The text tracks list of cues is written to by the parser for the resource being loaded, and can be updated dynamically while the track state is loading, but there is seemingly nothing in the spec that prevents the parser from continuing to update and completing after the loaded event has been fired. And in the loading state, if the track is being parsed from interleaved in-band data, then each cue may well not be parsed and entered into the cue list until the video playback reaches a point just before the cue is due to be used. Therefore a TextTrackCueList object can contain an indeterminate number of cues. There is no event to tell when or if this list is complete, or any way for an author to easily detect that new cues have been added.


I was under the impression that the "oncuechange" event on the track
is being fired when the cue list changes. Thus, this event will tell
you when a new cue has been added to the list. "onload" will indeed
only tell you that something is available now. But I thought
"oncuechange" would give you the notice that you need to re-read the
list of cues and activecues in the TextTrack.


>                Q1: Should the loaded event be delayed until after the text parser has completed?

What is "completed"? There is no notion of "these are all the cues
available" for a live stream, so the notion of "complete" has
deliberately been avoided IIUC.


>                Q2: Should there be an event or some other mechanism while in the loading state to detect that the list has changed

The events are indeed a bit underspecified. IIUC "onload" is fired
when the "decoding pipeline" for this track has finished loading - for
a TTML or WebVTT file this would probably mean when the file or the
beginning of the file has been downloaded - for a longer video when
the first cue is available or the track is made available.


>                Q3: Should there be an event or some other mechanism to detect that the list is final

"Final" is relative. It is more important to know that a new cue is
available rather than that "all" cues have been received - in
particular since in a streaming scenario we will never know what "all"
is.



> An author wishing to detect the entry and exit of cues needs to set event handlers individually on each cue in the list, the EventTarget API gives no means of detecting whether a handler has been set. So it is problematic, given that cues may be arriving in a 'just in time' manner, for an author to be able detect the addition of a cue, know whether it has a handler set on it, and to have time to attach an event handler to it  before the playhead passes its active point.

This is a different issue to the one above, IIUC. I agree, that this
is a concern. Maybe it would be better to move the onenter/onexit
events to the track rather than the cue? Maybe they should be called
oncueenter/oncueexit ?


>                Q4: Should the onentry/onexit events be removed from cue; and update the oncuechange event on track to receive a list of incoming and a list of outgoing cues as argument so that a) It is possible to set the handler before any cues are added at all, b) so that only a single handler needs to be set, c) make the 'activeCues' list redundant, and d) clear up where these events would bubble to.

I think this sounds reasonable. It all makes sense to me.

Cheers,
Silvia.


> Thanks,
> Sean.
>

Received on Thursday, 3 March 2011 00:18:31 UTC