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

[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> 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]
> *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 <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 <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
>
>
>
> 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
>
>
>
>
>