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

Thanks a lot, Chris!!!

Kazuyuki

On Wed, Aug 26, 2015 at 6:14 PM, Chris Needham <chris.needham@bbc.co.uk>
wrote:

> 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