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

On Tue, Sep 15, 2015 at 1:23 PM, HU, BIN <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]
> *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, 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
>
>
>