I've reviewed HTML5 LCWD with some broadcasters, and we noticed that the design of time, clock and cue in HTML5 LCWD may be insufficient to deal with a couple of significant use cases that are common in broadcasting services: e.g. live programs (sports programs etc) with interaction, and emergency information services as for disaster prevention. The model of time, clock and cue in HTML5 LCWD looks mainly based on the use cases of movies or 'packaged video'.
Note: We've reviewed HTML5 LCWD only from the perspective of what broadcasters have already established in their actual services with their existing standards. But we haven't reviewed it from the perspective of the-next-generation TV that should be one of the central topics of 'Web and TV' IG. And the review is not exhaustive. We believe we'd better continue our consideration in 'Web and TV' IG and also create a new task force like 'Web and Broadcasting' to address these issues in the IG. * Use cases ** Use case #1: Broadcaster sends immediate trigger in live program 1. A user is watching a live program. (e.g. boxing matches) 2. The broadcaster provides sports betting service with browser. 3. The match ends suddenly. 4. The broadcaster want to close their bet immediately. And they will open next bet when next match get started but the start time is not sure. *** Problem with HTML5 LCWD? - The broadcaster can not designate the star time and end time of the timed text cue. - The broadcaster can not designate that the cue must be immediately processed with highest priority. - There is a possibility that the cue will be skipped over because of long queue. ** Use case #2: Broadcaster sends immediate trigger for emergency information 1. A user is watching a program. (e.g. drama) 2. Big quake happens. Tsunami will arrive in 5 minutes. 3. A broadcaster wants to notify users of the tsunami immediately. The duration to show the emergency information can't be defined the moment when the broadcaster sends the cue. *** Problem with HTML5 LCWD? - The broadcaster can not designate the star time and end time of the timed text cue. - The broadcaster can not designate that the cue must be immediately processed with highest priority. - There is a possibility that the cue will be skipped over because of long queue. ** Use case #3: HDD recorder sends immediate trigger in recorded live program 1. A user records the live boxing program of use case #1 with some kind of HDD recorder, it means, the HDD recorder records all tracks related to the program including timed text tracks. 2. The user watches the program from the HDD recorder after the match finished. 3. The broadcaster don't want to provide sports betting service for non-live viewers (users). So the behavior of the recorded live program must be different from that of the original live program. *** Problem with HTML5 LCWD? - The document can not distinguish the current program is real live or recorded live. ** Use case #4: Broadcaster sends immediate trigger after passing a leap second 1. Users are watching a live program. (e.g. boxing matches) 2. The broadcaster provides sports betting service with browser. 3. A leap second passes. 4. The match ends suddenly. 5. The broadcaster want to close their bet immediately. And they will open next bet when next match get started but the start time is not sure. *** Problem with HTML5 LCWD? - Because of lack of the description (esp. the procedure to create the associated timeline for media controllers) on how to deal with leap seconds, The document can not distinguish the current program is real live or recorded live. * Suggestion on how to solve these problems - Make the start time and end time properties of cues not mandatory. - Add 'immediate' flag property to cues. And add appropriate interfaces to access them. - Add 'submit time' property to cues. And add appropriate interfaces to access it. - Modify the procedure to deal with queue of cues not to skip over the cue with immediate flag. - Add 'Media.currentOriginalTime' interface to obtain original date time of media data. - Modify the lowest limit of frequency of polling the queue from 4 Hz to 10 Hz. Because 10 Hz is the most typical lowest frequency to deal with hooks for interactive content in digital broadcasting. ** Related sections - 2.5.5.3 Times - 4.8.10.6 Offsets into the media resources - 4.8.10.8 Playing the media resource - 4.8.10.12.1 Text track model - 4.8.10.12.3 Sourcing out-of-band text tracks -- Yosuke Funahashi co-Chair, W3C Web and TV Interest Group Researcher, Keio University Research Institute at SFC Board Director, Tomo-Digi Corporation
