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

Received on Wednesday, 26 August 2015 22:36:05 UTC