Re: ACTION-30: Skim the work done by the media pipeline tf

Hi Bin and Chris,

I completely agree with you both, and thought some of the MPTF
requirements might have been useful as guidelines or suggestions to
our TV Control API discussion.

And I also would say thank you very much for Chris's great work.
Thanks, Chris!

Regards,

Kazuyuki



On Sat, Aug 29, 2015 at 12:04 AM, HU, BIN <bh526r@att.com> wrote:

> Chris,
>
> That's great and thank you very much for your time and great work.
>
> Have a nice weekend
>
> Bin
>
> -----Original Message-----
> From: Chris Needham [mailto:chris.needham@bbc.co.uk]
> Sent: Friday, August 28, 2015 7:51 AM
> To: HU, BIN; Kazuyuki Ashimura; public-tvapi@w3.org
> Subject: RE: ACTION-30: Skim the work done by the media pipeline tf
>
> Hi Bin,
>
> I agree that the MPTF scope is quite different to ours. My aim was to use
> their work as inspiration to see if we've missed anything, so what I tried
> to do is pick out the few parts from their requirements that may be
> relevant to us. I am certainly not suggesting that we follow up on
> requirements that are not in scope of our own work in this CG.
>
> Best regards, and have a nice weekend!
>
> Chris
>
> ________________________________________
> From: HU, BIN [bh526r@att.com]
> Sent: 26 August 2015 23:35
> To: Chris Needham; Kazuyuki Ashimura; public-tvapi@w3.org
> Subject: RE: ACTION-30: Skim the work done by the media pipeline tf
>
> Chris,
>
> Thank you for your great work in this analysis, and completing your
> Action-36.
>
> A key question of reviewing MPTF is - what is the role of MPTF
> Requirements [1] to the work that we are doing here? I am not sure if it
> has any binding effect on us.
>
> It seems to me that those MPTF Requirements [1] are targeted to improving
> HTML5 specifications, and many bugs and issues have been opened to HTML5
> specification. It is my understanding and expectation that those gaps be
> addressed by the evolutions and later versions of HTML5.
>
> I am not sure if it is appropriate to revise / add those MPTF
> requirements/gaps into our Technical Requirement [2], because certainly we
> are not expected, and not capable to address those gaps that will be
> ultimately addressed by HTML5 itself.
>
> IMHO, because the role of MPTF is targeted to HTML5 and has no binding
> effect on us, for the best interest of web community, we as a Community
> Group should not try to re-invent the wheel (of what HTML5 will do). Our
> requirement work has been closed since October 2014.
>
> Thus my suggestion is that
> - We keep our Technical Requirement [2] as is
> - We focus on addressing the gaps between our current ED and Technical
> Requirement [3]. Refer to Paul's analysis of how to complete our ED through
> addressing those gaps [4].
> - Let us still target to complete TS Draft by the end of 2015.
>
> If there are additional use cases which may bring additional requirement,
> let's address it in the next version.
>
> Thank you again for your great work of analyzing it. We know there are
> still some gaps in HTML5, and we will expect those gaps be addressed by
> evolution and later versions of HTML5.
>
> Thanks
> Bin
>
> [3] https://www.w3.org/community/tvapi/wiki/Main_Page/Progress_Measurement
> [4] http://lists.w3.org/Archives/Public/public-tvapi/2015Aug/0011.html
>
> -----Original Message-----
> From: Chris Needham [mailto:chris.needham@bbc.co.uk]
> Sent: Wednesday, August 26, 2015 2:14 AM
> To: Kazuyuki Ashimura; public-tvapi@w3.org
> Subject: RE: ACTION-30: Skim the work done by the media pipeline tf
>
> Hi all,
>
> I've taken a look at the MPTF requirements [1] in more detail. Thanks Kaz
> for the suggestion to look at these, there's certainly useful information
> there.
>
> I haven't yet updated our Technical Requirement page [2], as I thought I'd
> share the information here for discussion first. I'll be happy to update
> the wiki if you think the changes I suggest below are OK.
>
> The Design Goals section in [1] mentions security:
>
> > A conforming specification needs to address the security concerns
> > of end-users, authors, distributors and device manufacturers by
> > recommending appropriate security policies and programming behavior.
> > A conforming specification must also consider the distribution and
> > deployment security requirements as they relate to authors and vendors.
>
> I don't think we've discussed security requirements as far as I know. One
> concern I have is that an API that allows any web page to discover the list
> of TV channels available, and the list of scheduled recordings, can be used
> for fingerprinting, so impacts end-user privacy. Malicious web content
> could also manipulate the scheduled recordings.
>
> I think this is something we'll need to consider as we move towards an
> initial stable specification. I believe W3C has published some guidance for
> spec authors, but I don't have the correct link to hand. I think it would
> be useful to look at existing W3C specifications to see the approach taken
> there, as well as the security aspects of the OIPF DAE.
>
> I suggest adding a new Security Requirements section, to say that our spec
> shall conform to the published guidance for security and user privacy, and
> then review our work from this point of view.
>
> The MPTF requirements document follows with the list of numbered
> requirements:
>
> R1. Combined Main + Description Audio Track
>
> > Playing descriptive audio tracks, which come in two forms:
> > * Description pre-mixed with main audio (e.g. USA, Canada)
> > * Description not mixed with main audio (e.g. Europe)
>
> This requirement resulted in a change to the categories returned by
> AudioTrack.kind() and VideoTrack.kind().
>
> I think the requirement to support alternate streams is covered in
> [trigger..sources], but our spec doesn't mention the use of AudioTrack and
> VideoTrack. Maybe this is more an issue of API design than requirements -
> our Technical Requirement page has a section "Integration with HTML <video>
> and <audio> Elements" where we could add this level of detail if needed.
>
> R2. Key Metadata Types
>
> > An ability to distinguish specific types of metadata should be added
> > so that key metadata types can be handled appropriately by a User Agent.
>
> The MPTF document did not identify any gaps, so I think no change is
> needed here.
>
> R3. Handling of In-band Tracks
>
> > Playing in-band multiplexed media streams (e.g. broadcast
> > television, live events and recorded movies) with track elements
> > that come and go over time (e.g. secondary audio, subtitles in
> > different languages, application signaling and content ratings.)
>
> Here, I suggest a couple of changes:
>
> Modify [trigger.types.caption] to add "in all available languages".
>
> Add a new requirement [trigger.sources.notifications] The API shall be
> able to notify web apps when the the set of available tracks (audio, video,
> subtitles etc.) changes, i.e., when tracks are added and removed.
>
> In practice, if we're using the AudioTrack and VideoTrack APIs, these
> generate events when the set of available tracks changes.
>
> R4. Content Authorization Parameters
>
> > A method for securely informing web content of a media item's content
> > rating or other authorization parameters should be developed. This should
> > be delivered when the media is loaded and whenever the authorization
> > parameters change.
>
> This is covered in our parental control and CAS requirements, but not the
> part about changes to the authorization parameters.
>
> This raises questions such as what should happen if a live stream is being
> displayed and the programme content changes such that authorization is
> required to view. Should the browser stop media playback if user
> authorization has not been given, or is this an application-level
> responsibility?
>
> I suggest adding the following requirement:
>
> [parental.notification] The API shall be able to notify web apps of
> changes in the protection status of the programme content, e.g., when age
> restrictions are applicable.
>
> R5. Content Authorization Failure
>
> > A method for securely informing web content that a media item
> > could not be played due to an authorization failure and the
> > reason for the authorization failure.
>
> As far as I can tell this isn't covered in our requirements, so I suggest
> adding:
>
> [parental.authorization] The API shall provide a method for informing the
> web app that a media item could not be played due to an authorization
> failure and the reason for the authorization failure.
>
> and
>
> [cas.authorization] The API shall provide a method for informing the web
> app that a media item could not be played due to an authorization failure
> and the reason for the authorization failure.
>
> R6. Adaptive Bit Rate Format Support
> R7. Additional Media Parameters
> R8. Additional Media Feedback and Errors
>
> These requirements concern adaptive bitrate playback, so aren't directly
> applicable to the TV Control API, as they are covered by Media Source
> Extensions for web-based media delivery (although some of the requirements
> must be handled by an application-level adaptive streaming client).
>
> R9. Security and Digital Rights Management Identification
> R10. Content Protection Parameters
> R11. Content Protection Feedback and Errors
>
> These requirements concern content protection and DRM, which I believe are
> covered by our own CAS requirements, but I suggest it would be useful if
> someone else who has more time could look at these.
>
> Best regards,
>
> Chris
>
> [1] http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Requirements
> [2] http://www.w3.org/community/tvapi/wiki/Main_Page/Technical_Requirement
>
> ________________________________________
> From: Kazuyuki Ashimura [ashimura@w3.org]
> Sent: 30 June 2015 14:12
> To: public-tvapi@w3.org
> Subject: ACTION-30: Skim the work done by the media pipeline tf
>
> Hi Bin and group,
>
> Based on my action item (ACTION-30):
>   http://www.w3.org/community/tvapi/track/actions/30
>
> I've skimmed the Requirements document generated by the Media Pipeline
> TF of the Web and TV IG at:
>   http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Requirements
>
> There are the following 11 requirements in the document, and I think
> this could be a good check list for our requiremnts document at:
>  https://www.w3.org/community/tvapi/wiki/Main_Page/Technical_Requirement
>
> and the table at:
>  https://www.w3.org/community/tvapi/wiki/Main_Page/Requirements_Mapping
>
> Delivery of Television Services:
> --------------------------------
> - R1. Combined "Main + Description" Audio Track
> - R2. Key Metadata Types
> - R3. Handling of In-band Tracks
> - R4. Content Authorization Parameters
> - R5. Content Authorization Failure
>
> Adaptive Streaming of Media Content:
> ------------------------------------
> - R6. Adaptive Bit Rate Format Support
> - R7. Additional Media Parameters
> - R8. Additional Media Feedback and Errors
>
> Content Security and Digital Rights Management:
> -----------------------------------------------
> - R9. Security and Digital Rights Management Identification
> - R10. Content Protection Parameters
> - R11. Content Protection Feedback and Errors
>
> Also I think it would be useful for us to revisit the Media Accessibility
> User Requirements:
>   http://www.w3.org/TR/2014/WD-media-accessibility-reqs-20140814/
>
> For example, we might want to consider how to handle:
> - described video
> - text video description
> - extended video descriptions
> - clean audio
>
> Thanks,
>
> Kazuyuki
>
>
>


-- 
Kaz Ashimura, W3C Staff Contact for Auto, TV, MMI, Voice and Geo
Tel: +81 3 3516 2504