RE: tvapi-ACTION-39: Look into parental control

Hi Bin

I guess either way would work – id we already have TVBufferedMediaStream and expect an HTMLMediaElement [1] to “handle it” then putting necessary functionality in there to is the way to go. The elementary streams delivered in the transport stream can then be directly mapped to AudioTrackList, VideoTrackList and TextTrackList attributes.

Paul

[1] http://www.w3.org/TR/html5/single-page.html#htmlmediaelement


From: HU, BIN [mailto:bh526r@att.com]
Sent: Tuesday, September 15, 2015 12:19 PM
To: Sean Lin
Cc: Paul Higgs; TV Control API Community Group
Subject: RE: tvapi-ACTION-39: Look into parental control

Sean,

Thank you for the proposals. It seems that 1st option (i.e. extending MediaStream API and returning TVBufferedMediaStream) is more flexible for web apps and less constraint on UA vendors, and it also addresses both “channel.tracks” and “program.data.video” requirements.

Paul and everyone,

What do you think?
Thank you

Bin

From: Sean Lin [mailto:selin@mozilla.com]
Sent: Tuesday, September 15, 2015 1:21 AM
To: HU, BIN
Cc: Paul Higgs; TV Control API Community Group
Subject: Re: tvapi-ACTION-39: Look into parental control

I put my comments inline below.

Please feel free to share your ones.

Sean Lin
Mozilla Taiwan
selin@mozilla.com<mailto:selin@mozilla.com>

On Tue, Sep 15, 2015 at 1:23 PM, HU, BIN <bh526r@att.com<mailto:bh526r@att.com>> wrote:
Paul,

Thank you for your great analysis and insight.

Sean,

Do you have any comments on:

-          Constraints of MediaStream as Paul analyzed, and the suggestion to completely drop MediaStream approach. Instead, finding a way of setting the videoTracks, audioTracks and textTracks of the HTMLMediaElement<http://www.w3.org/TR/html5/single-page.html#media-element> to satisfy “channel.tracks” requirement.
I'm thinking of two possible ways.

1. We may extend MediaStream API, just like what we were suggested to have a seekable media stream for recording, to have methods getting text tracks and supporting video/audio tracks other than camera/microphone. And TVTuner.stream may become to return TVBufferedMediaStream [1] instead.

2. TVTuner.stream still uses MediaStream. But the spec asks the UA to keep track of the stream and "carry" the text tracks and additional video/audio tracks implicitly even though these data are not exposed to the application via MediaStream API. And when it comes to assign the media stream to a media element, the UA auto hooks these data to the media element. Then the application is able to use HTMLMediaElement API [2] to access these data.

[1] http://w3c.github.io/tvapi/spec/#tvbufferedmediastream-interface

[2] http://www.w3.org/TR/html5/embedded-content-0.html#media-element


-          Suggestion of defining “dictionary TVVideoChannelData” to satisfy “program.data.video” requirement.
HTMLVideoElement [3] provides some APIs to get video dimensions. Yet if we still really need codec or some other additional info, we may define the new interface, or add extra attributes to TVBufferedMediaStream interface (once we take the first proposal for channel.tracks).

[3] http://www.w3.org/TR/html5/embedded-content-0.html#the-video-element



Thanks
Bin

From: Paul Higgs [mailto:paul.higgs@ericsson.com<mailto:paul.higgs@ericsson.com>]
Sent: Monday, September 14, 2015 6:58 AM
To: HU, BIN; Sean Lin

Cc: TV Control API Community Group
Subject: RE: tvapi-ACTION-39: Look into parental control

Hi Bin

Here are some comments on the two remaining requirements….

channel.tracks : The API SHALL be able to enable the webapps to switch the video/audio/text tracks of a channel.

•         As we have discussed on several occasions the method we use to “output” from the TVTuner to the HTML5 <video> element is the MediaStream [1], which only supports video (through a camera stream) and audio (through a microphone stream) [2], see also MediaStreamTrack.kind [3]

o   Because of this, I do not see how we can meet the requirement (or indeed the minimum usability requirement) for subtitle/caption support.

o   Since there is only one video stream in the MediaStream, we will not be able to do video subtitles (such as the sign language subtitles used in the UK)

o   Unless we overcome this constraint in MediaStream, we have an unusable API.

•  It would be unreasonable to expect the UA to “mix” in the subtitle information into the video plane.

•         Perhaps we need to drop the MediaStream approach completely

o   This would mean finding a way of setting the videoTracks, audioTracks and textTracks of the HTMLMediaElement<http://www.w3.org/TR/html5/single-page.html#media-element>, - not sure if the <source> elements can be “streams”, they seem to just be files!



•         If the received transport stream supports multiple video and audio elements then the TV Control API needs some way to present these to the WebApp and allow the WebApp to select which one should be sent via the MediaStream

o   OIPF describes this as “component selection” in DAE 7.16.5 Extensions for Playback of selected media components [4].

o   A similar method could be described, i.e. an array of transport stream components and a selection method

•  It could be that a simple “selected” boolean is added to each component, which when set to true causes the others to be set to false. There are some limitations to this approach.


program.data.video : For video stream: such as quality, codec used, etc.

•         What do we have to satisfy the “[program.data.audio] For audio: such as language supported, codec used, etc.”  requirement? The current implementation just shows language – omits codec, channels, audio type (main, commentary…)

•         As we are completely unsure what the full makeup of this video related program data, all we can really define is a string attribute that contains a JSON representation of the received video program data. The WebApp can then provide this to some network/cloud application along with channel identification information (from channel.name<http://channel.name>, channel.type) and hope to get back some usable information.

•         There are probably two types of program video data

o   Some which is generally well known and can be determined when the program is received/decoded

o   Some which is region specific – this could be put into the JSON representation (with UUencoded binary values etc)

•         Thus a TVTideoChannelData type could be defined and added as an attribute to TVTuner (I pick this because it is probably only known when the channel is tuned to, not when the channel is scanned or queried through metadata)
dictionary TVVideoChannelData {
      readonly attribute DOMstring? codec;
      readonly attribute unsigned long? width;
      readonly attribute unsigned long? height;
      readonly attribute DOMstring? otherInfo;
}




[1] https://w3c.github.io/tvapi/spec/#dfn-mediastream

[2] http://www.w3.org/TR/mediacapture-streams/#track-source-types

[3] http://www.w3.org/TR/mediacapture-streams/#widl-MediaStreamTrack-kind

[4] http://www.oipf.tv/web-spec/volume5.html#extensions-for-playback-of-selected-media-components



Paul