DevMeetupTokyo/Standards for TV
Use case example: http://www.w3.org/2014/05/28-webtv-minutes.html#item05
Split Triggered Overlay into two parts:
Possible to use text tracks as triggers, following the in-band tracks proposal: http://dev.w3.org/html5/html-sourcing-inband-tracks/#mpeg2ts
Broadcasting standards use text strings in elementary streams as triggers to control apps on TV sets. We can't use HTML5 text track cues for managing these triggers without defining details of the cue as the WebVTT report specifies WebVTT cues in detail.
Triggers can be from two sources:
- Predefined times
- Live/manually-triggered events
HTML5 lacks a built-in cue system/task scheduler with a high degree of precision that can accept triggers from a variety of sources.
Could be covered by In-band Resource Tracks.
HbbTV, Hybridcast can have multiple in-band trigger streams. Trigger streams have stream IDs called component tags in MPEG, which allow apps to identify them.
Could partially be covered by server-sent events.
Could be achieved by extending Sourcing out-of-band text tracks.
Hybridcast is sync (however if the unbound parameter equals to true, the program after this method calls will continue to execute, otherwise the program will be terminated), HbbTV is async
Hybridcast uses a tuneTo API, which is synchronous, returning the result of tuning to a channel. Parameter to specify whether app should die or continue running after the channel has changed.
HbbTV has the onchannelchange event handler, which catches channelchange events with a success or error status.
Need more information about the requirement, e.g. is it synchronous or asynchronous?
HbbTV: fingerprint is used for synchronizing multiple streams.
MPEG-2 TS, programs are referred to as events. When a program (event) changes, a new event ID is sent. Need an event/trigger fired when the program changes. Could be a "trigger" requirement, could be a "program" requirement.
E.g. trigger.types.program-changed Is this the same as trigger.types.content-boundary ?
Need more description of the trigger types. E.g. is trigger.types.caption when the caption changes or when a caption becomes available?
trigger.types.time exists in Hybridcast but not in HbbTV.
trigger.data.supplemental trigger.validity trigger.data.content-source trigger.sources Are all these necessary? What are the use cases?
Integration with HTML <video> and <audio> Elements
Couldn't use <video> tag for broadcast stream, using <object> instead, also for recorded content. Once video content is downloaded it's in the device and then there could be a namespace problem. <video> is used for VOD content.
Hybridcast uses <object> rather than <video>. Type: video/x-iptvf-broadcast
This has data attributes:
- broadcast wave
Object element's "video" parameter is important:
<object> <param name="video" value="arib://<original_network_id>.<transport_stream_id>.<service_id>[;<content_id>] [.<event_id>]/<component_tag>[;<channel_id>]"> </object>
FYI: These are MPEG TS terms.
- original_network_id = broadcast station
- transport_stream_id = transport stream used by broadcaster
- service_id = channel (but possible to have multiple services for one channel)
- event_id = program
- channel_id = audio channel
The problem was how to bind video decorder (hardware) and video element.
HbbTV (OPIF) has the state machine for the binding process specified very well. (Hybridcast terminals works in the same way internally but not specified in their spec.) HTML5 video element and MediaStream API lack this level of detail, which is one of the reasons why HbbTV haven't adopted the video element.
See OIPF-T1-R2 2014-01-24 page 190.
This can be specified for Web standards as well; just need time to build requirements, partially already done by MediaStream API.
MediaStream API or TV Control API is missing region specifier (arib://, etc.) and broadcaster ID.
TV Control API CG Feedback: Confirmed that the state machine structure is very different, not just the param value above.
Fullscreen feature is built into the object capability in Hybridcast. This is because the Fullscreen API work was discontinued.
Currently, W3C has no plans to continue work on this API - it will remain as a published Note. http://www.w3.org/TR/fullscreen/
Those wanting to use the Fullscreen API as a reference should refer to the WHATWG version.
Mute functionality is also built into object capability in Hybridcast. Need ability to resume to previous volume level even on such a device that apps don't know/have access to volume levels of the device.
For synchronization, time precision needs to be at least 100 milliseconds (0.1 seconds), e.g. for HbbTV. HTML5 media timeline is currently defined in seconds which is too rough.
See HbbTV spec 2.0, page 247: "Advert insertion guidance for content providers"
"Detecting when to perform the switch between <video> elements can be implemented in a variety of ways, including:
- Listening to "timeupdate" events from the currently playing media element.
- Polling the "currentTime" attribute of the currently playing media element.
- Listening to "cuechange", "enter" and "exit" events of a TextTrack on the currently playing media element.
For accurate timing, it is possible to combine these techniques. For example, a "timeupdate" event can be used to discover the approximate playback position and then, 500ms before the ad break, the application can switch to polling the "currentTime" attribute of the currently playing media element using setTimeout() or setInterval(). Note that the HTML5 Recommendation  only states that the terminal must emit a "timeupdate" event for this media element at least every 250ms, therefore relying on the "timeupdate" event might not provide sufficient accuracy for ad insertion by itself."
This is relevant for ad insertion and synchronization.
ACTION: ddavis to mention this to Device Timing CG
TV Control API CG Feedback: It may not just be seconds - there could be a need for improving per-frame accuracy.
In Japan, EWS - Emergency Warning System - triggers TV to turn on. The alerts are outside Hybridcast. If EWS is activated, video is shown fullscreen. In a real disaster, the priority is to close all apps and show an emergency broadcast fullscreen. This is because all terrestrial TV broadcasting companies are well-equipped and well-prepared to deliver live emergency broadcast on disasters so that they can immediately deliver disaster related information from their studios 24/7. Applications are useful later during the recovery phase and for less devastating disasters.
Emergency alerts are a type of trigger so a specific Emergency Alert section may not be needed.
Could be useful if the data source is separate to the media source, or if the action changes depending on the severity level.
Might be a need for "type", e.g. warning, danger...
Currently getPrograms is very generic (by necessity). The background/data source is much more complicated and varies by country/region. Maybe a mapping document similar to In-band Resource Tracks will be needed.
EPG data can be too big for TV-like devices. Need parameters to be able to filter, e.g. channels, content genre duration is already used for programs - change to end time
Typo in spec: retuen -> return
TV Control API CG Feedback: There's a case for not using this type of filtering, rather it could be a key-value schema-style kind of searching, e.g. query-name='actor', query-value='hanks'
In Japan, EPG has:
- short desc and long desc
- Whether it's 再放送
- Whether service is satellite or terrestrial broadcast
- Audio info is not just languages - could be different types of the same language. Clean audio is one example.
getAudioLanguages () and getSubtitleLanguages () are too narrow. Should be by type of tracks, e.g. text tracks, audio tracks.
TVChannelType is too limited. TV should also could include satellite, terrestrial, etc.
isFree is not necessarily by channel - often by program. Need to add to Program object.
Parental control can be in two forms:
- Blocked by parents, e.g. with PIN code. Application will not run.
- Programs are blocked based on Program.rating
Blocking by program means parental.channel blocking is not needed.
HbbTV has parental control in AIT. Applications won't launch without the PIN code.
If one application blocks content, it could be accessible using another application. Parental control needs to be at a lower layer. The problem at the moment is with the requirement - not enough details. Needed clearer premise.