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

Hi all,

I agree with the suggested approach to add a TVMediaStream, and that the available video, audio, and text tracks should be exposed using the audioTracks, videoTracks, and textTracks HTMLMediaElement attributes.

I suggest a very minor change to the wording of the spec [3] in section 5.1 (stream attribute), from:

* "by assigning the TVMediaStream (MediaStream) to the HTMLMediaElement"

to:

* "by assigning the TVMediaStream (MediaStream) to the HTMLMediaElement's srcObject attribute" (and reference the HTML 5.1 draft)

and similar in section 10.2, for the getStream method and section 11 (TVMediaStream).

Would we then have to define how the audio, video, and text tracks are sourced from the broadcast stream by reference to the appropriate DVB and ATSC, etc. specifications in a similar way to the "Sourcing In-band Media Resource Tracks from Media Containers into HTML" draft [2] (see section 3 for MPEG-TS), and define which tracks are selected by default?

Regarding the Media Capture and Streams spec, my colleague Nigel has been making the case for adding support for captions and other timed data events [4].

Finally, I must send my apologies for next week's phone conference as I have another meeting I have to attend. I'll look forward to seeing you at TPAC..

Best regards,

Chris

[1] http://www.w3.org/html/wg/drafts/html/master/semantics.html#mediaprovider
[2] http://dev.w3.org/html5/html-sourcing-inband-tracks/
[3] https://w3c.github.io/tvapi/spec/
[4] https://lists.w3.org/Archives/Public/public-media-capture/2015Aug/0014.html

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

Hi,

I just updated the draft based on our discussion. [1][2] The progress measurement [3] is also updated accordingly.

Please feel free to chime in with your comments/concerns/questions.

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

[1] https://w3c.github.io/tvapi/spec/#widl-TVTuner-stream
[2] https://w3c.github.io/tvapi/spec/#idl-def-TVMediaStream
[3] https://www.w3.org/community/tvapi/wiki/Main_Page/Progress_Measurement

On Wed, Sep 23, 2015 at 1:43 AM, HU, BIN <bh526r@att.com<mailto:bh526r@att.com>> wrote:
Paul,

Great and thank you.

Sean,

Looks like we have agreement for your next update of the spec.

Thank you
Bin

From: Paul Higgs [mailto:paul.higgs@ericsson.com<mailto:paul.higgs@ericsson..com>]
Sent: Tuesday, September 22, 2015 2:52 AM

To: HU, BIN; Sean Lin
Cc: TV Control API Community Group
Subject: 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

Received on Wednesday, 23 September 2015 10:37:15 UTC