This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Applications will typically access cues in a track by attaching a cuechange event handler which operates on the list of cues found in activeCues. This works well for most cues e.g. subtitles where the duration is likely to be at least a few seconds. Cues with a duration of less than 250ms may never appear in the activeCues list due to the way the time marches on algorithm (described in 4.7.10.8) operates. The algorithm is typically fired by the timeupdate event which in most browsers is every 250ms. Cues which start and end between two iterations will be "missed cues" and never appear in the activeCues list. To ensure all cues from a track would be fired, an application would have to do one of the following: Attach an enter/exit event to every cue with duration <250ms Inspect the full list of cues when cuechange is fired to check for missed cues. Use cues with a duration of >250ms. The problem has been highlighted by liaison from the HbbTV Association in relation to MPEG DASH stream events received by hybrid TV devices. Because of the media format and platform limitations the work-arounds listed above would be difficult to implement. Please see this mailing list post for further details: http://lists.w3.org/Archives/Public/public-inbandtracks/2013Dec/0005.html
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the Editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the Tracker Issue; or you may create a Tracker Issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Rationale: In my reading of the "time marches on" algorithm [1], all cues, including short cues that are missed by the time steps, will fire a cue enter and exit event. Part of firing that event includes a step called "Add track to affected tracks." and later on "For each text track in affected tracks, in the list order, queue a task to fire a simple event named cuechange at the TextTrack object, and, if the text track has a corresponding track element, to then fire a simple event named cuechange at the track element as well." Thus, when enter and exit events are raised, cuechange events are raised, too. So, I think your reading is incorrect, or has since been updated to address this issue. If implementations don't follow this spec, you will need to register bugs there. Please re-open if you think I have overlooked a case. [1] http://www.w3.org/TR/html5/embedded-content-0.html#time-marches-on
I don't believe this response fully addresses the original bug. I agree that a track where a cue has fallen between iterations of the time marches on algorithm will become an affected track and therefore fire a cuechange event. However at this point there is no sensible way to retrieve that missed cue. As an example consider the addition of the following attribute to the TextTrack interface: readonly attribute TextTrackCueList? missedCues; This missedCues TextTrackCueList would contain the list created in step 4 of the time marches on algorithm. An application which is notified via the cuechange event may inspect the activeCues list and find it empty. This would indicate a cue had ended or been missed. Without maintaining a copy of the activeCues list at the time of the previous cuechange, the cause is unclear. Inspecting the missedCues attribute would indicate to the application that a cue had fallen in the gap. The application could then access the data contained in the cue without having to parse the full cues list for cues with a start and end time in the last 250ms.
So what you really want to do is find out which cue(s) fired the oncuechange event?
Yes.
I'm thinking of extending the cuechange event to a CustomEvent with .detail containing the list of cues that triggered the event. Cloned the bug to WHATWG to get some more opinions on this.
Silvia, thanks for the clearer explanation in #24382 and forwarding to WHATWG. I agree a cue list in the event would also be a workable solution.
David, with the discussion and patch that were made on the WHATWG bug, are you happy that this bug was sufficiently addressed?
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the Editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the Tracker Issue; or you may create a Tracker Issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Partially Accepted Change Description: https://github.com/w3c/html/commit/e5ee67a8af7de132f2cf59eeab2b69c2ba15b295 Rationale: The preferred means of dealing with state information on text tracks is to make the cues the duration that the state is valid.
The Cue mechanism is being used here to represent/forward video-related events or triggers into the web (e.g. goals being scored, adverts to be inserted, ....). The current design is missing what's needed to work reliably where these are not known about in advance, e.g. for live video.
Timing of cues in live streaming is already being regarded in bug 14104 *** This bug has been marked as a duplicate of bug 14104 ***