[Bug 13692] New: Last call comments on HTML5 from broadcaster's point of view

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13692

           Summary: Last call comments on HTML5 from broadcaster's point
                    of view
           Product: HTML WG
           Version: unspecified
          Platform: Other
               URL: http://www.w3.org/mid/FB4150D2-5F03-42F7-9014-44613438
                    1EBE@tomo-digi.co.jp
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P3
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: mike+html-wg-mailbot@w3.org
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org


public-html-comments posting from: Yosuke Funahashi <yfuna@tomo-digi.co.jp>
http://www.w3.org/mid/FB4150D2-5F03-42F7-9014-446134381EBE@tomo-digi.co.jp

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

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Saturday, 6 August 2011 10:45:45 UTC