Media Pipeline TF Teleconference (Web and TV IG)

Clarke: mostly only one item on the agenda, review of content protection use cases.

Clarke: Several questions and comments around scope and definitions on DRM.
... We'll discuss that.
... Anything else to add?

TV services media transport mapping (ISSUE-39)

<Clarke> ISSUE 39:http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Discussions/TV_services_transport_mapping

Clarke: raised by Bob several weeks ago.
... mapping table.
... The basic idea of the use case is mapping existing traditional TV services that TV actors and potentially regulators might want to have, to the video element.
... Anyone who would object to accepting this use case?

Igarashi: Let me clarify. The use case assumes that Web page provider is different from content provider?

Bob: That's one of the motivations of the use case, yes.

ISSUE-39?

<trackbot> ISSUE-39 -- TV Services and Media Transport Mapping -- raised

<trackbot> http://www.w3.org/2011/webtv/track/issues/39

Bob: For some services, even if they are the same, you still need to define how to translate the info at the application level.
... We don't know in advance what transport layer may be used and how this data might be transported.
... For in-band tracks, that mapping is done by user agents. The user agent has to recognize the data and builds the DOM objects related to the tracks and fill it with info.

Jan: My assumption is that the UA has some capability of that type. Some way, we need to document the mapping.

Jan: Personal opinion: for W3C it may be tricky to define interoperability of topics that sit outside of W3C.
... There might be organizations that have that expertise.

Bob: Couple of comments. When you look at the current HTML5 draft, section that refers to textable sourcing of inband tracks, you will see that it explicitly references an external spec that will define how this mapping is done.
... We've got acknowledgment from WhatWG that agree that this mapping needs to be done.
... Question is whether this can be done in W3C.

Jan: I think it's fundamental that this be done, but from what you tell me, W3C is not entirely agnostic to the source.
... How would you reflect this mapping?
... Let's say I take MPEG2-TS component, somehow you need to map them to the track.

Bob: we've been doing most of our work with MPEG2. Audio mapping is a good example.
... The mapping would describe how user agents would recognize audio tracks. Regional stuff.
... And then there's the question for the various types of audio track, how do you assign the "kind" attribute.
... This particular one is linked to the bug I filed on the HTML5 spec.
... Today, there's only one kind, and we may need two to do pre-mux.
... Mapping would precise which kind needs to be specified.

Jan: I did a little diagram to understand the components and identified 7 areas to refine.

Mav: two different directions, one is mapping, the other is more detailed description as you suggest.

<rberkoff> Can a link in Issue-39 to the discussion be added. I think that our usual procedure?

Bob: For each one of these boxes, how do you recognize the track format. W3C HTML5 describes how these get exposed to the Web page.
... HTML5 is silent on format of text track. Depending on transport stream, different things need to be specified.
... We're in the process of prototyping some of this.

Clarke: hearing some discussion on how we might do this, but no objection to accept this as a use case.

Bob: Maybe we need to list a number of requirements. About what is the type of work that needs to be done in the next stage.

Clarke: yes, use cases first, then requirements.

Bob: I have identified what I think needs to be standardized.

<kaz> issue-18?

<trackbot> ISSUE-18 -- Video tag support of MPEG2-TS -- raised

<trackbot> http://www.w3.org/2011/webtv/track/issues/18

Jan: in ISSUE-18, I touched upon MPEG2-TS, may need to reformulated in the light of the discussion here.

Clarke: yes, would be very useful as we try to extract requirements.

Bob: Jan, it looks to me that we should merge these two use cases.

Jan: Yes, that was my purpose. I did not think W3C would be the right place for that discussion.

Clarke: may I suggest that Jan and Bob work together and see if they can be merged?

Bob: yes

Jan: yes.

Igarashi: comment about previous discussion.

Igarashi: mapping not restricted to media formats, mapping guidelines would be helpful.
... Beneficial for W3C to standardize such mapping.

Bob: We identified that for metadata tracks, we wanted to track them to expose ad insertion messages, content rating messages. The current HTML5 spec does not provide any information to differentiate between metadata tracks.
... No way for the JavaScript to tell what's in the metadata track.
... We raised that to the HTML WG.
... I agree that it's not clear whether W3C should do that or not.

Igarashi: I think W3C should discuss how to expose this information.

Clarke: one of the points raised that it would be useful to have participation from country orgs, or orgs that we're referencing to alert them on what we intend to do.

Igarashi: That's correct.
... How to do [??] is out of scope for W3C.

Bob: I agree with that. Different standards. This work would reference these standards. The work that remains to be done is point 3.
... It's not totally obvious in the case of MPEG DASH that it's been entirely defined how this information flows here.
... So work here could be to raise a flag that something needs to be done in that space.
... We could e.g. go back to other orgs and say that something needs to be added.

Igarashi: think there should be more in the motivation section for this use case.

Clarke: maybe you could communicate directly with Bob for that.

Igarashi: ok.

Content delivery in distribution windows (ISSUE-40)

<Clarke> issue 40;http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Discussions/Delivery_in_distribution_windows

Clarke: some of the discussion going on on the reflector seems to be concerned that we are trying to standardize on the DRM.
... That's not the goal, we propose to standardize on the "enable" level to make playback of protected content possible.
... What we want to enable here is a way to specify parameters that to play a video you need to support some sort of DRM, etc.

Bob: Good clarification. No intent for a single DRM. We expect content to be protected with different types of DRM.
... The idea is to be able to continue to use the <video> tag to play protected content.
... Lots of details below that, but the high level need is that.

Clarke: OK, if you think that ISSUE-40 is out of scope here, please speak up.

Narm: It might be a good idea to add a clarification along the lines of what you just said to the issue.
... so that it's clear.

Clarke: good point.

Bob: I can, but question for the group. All the comments are on the requirements, more than on the use cases.

<rberkoff> Issue-40 need to link back to Wiki discussion

Bob: I'm fine to add the clarification to the requirements doc.
... Is that the appropriate place to do it?

Clarke: I think so. ISSUE-40 doesn't imply any kind of DRM.
... That seems pretty generic to me.

Bob: OK, I'll put in some clarification text, and others can comment whether that's suitable.

Clarke: Specifically, on ISSUE-40, any objections to accepting the use case?

Russell: question on the use of "enforce"

Bob: suggestion for an alternative?

Clarke: what you mean is that HTML5 does not need to enforce anything, should simply enable the use of something that does the enforcement.

Russell: that's what I would think.

Bob: I'm open to alternatives, but that's what I had in mind with the use of "enforce".

Clarke: Boiling down to allowing/disallowing playback is good, I think.

Russell: sounds like license enforcement, more than DRM.

Clarke: could you suggest some alternative text?

Russell: The DRM agent can never go back to the user agent and say "don't do this".
... Maybe the use case should be framed in terms of DRM agents. Requirement such as the HTML5 user agent should enable DRM agents.

Bob: why don't you send that to the list?

Russell: ok, will do.

Clarke: ok, we'll wait for Russell suggestion, probably can accept that one afterwards.

Support of content owner rights (ISSUE-41)

<Clarke> ISSUE 41: http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Discussions/Content_owner_rights

Clarke: another variation. This one mentions UltraViolet in particular. Do you want to keep that or is there a way to keep that more generic?

Bob: I can go either way. It's a more generic problem.

Clarke: I would prefer to have UltraViolet as an example rather than as a use case.

[exchanged missed on UtlraViolet, licensing and re-encoding]

[scribe stepped out for a minute]

Bob: there is no re-encoding in UltraViolet, actually. ISSUE-40 is broader than ISSUE-41.
... The comment is that if we generalize ISSUE-41, how is it different from ISSUE-40?

Russell: DECE supports 5 different DRMs, right?

Bob: yes, but common encryption, you just give it a different license.

Clarke: just to clarify there. In ISSUE-41, if there are different DRMs systems available, is that negotiated before the content is delivered?
... I'm wondering if there's something unique to ISSUE-41.

Bob: I try to tie in needs for content protection with business needs.
... We can certainly have a discussion on whether implementations will be different or the same between the 2.

Clarke: We should identify use cases that lead to specific requirements.
... If there aren't any specific requirements, then maybe both issues should be merged.

Bob: ISSUE-41 touches upon the common encryption mechanism.

<rberkoff> I agree w/Bob's description

Clarke: the idea to identify a DRM with a common encryption that gets negotiated somehow sounds like a different requirement.

Bob: yes.

<rberkoff> yes

Juhani: If DECE requirements are to be taken into account, why don't we ask DECE about them?

Clarke: you're suggesting DECE should write clarifications to this use case.

Juhani: the best source of information for this would be DECE members if we talk about a specific system.

Clarke: So we're DECE members, so don't know if you're suggesting stronger links or not

Bob: I heard the comment to precise what needs to be standardized in a more DECE-focused form.

Juhani: yes, if it's an example, no need to do that, but if we want to highlight DECE as a requirement in particular, maybe there should be a direct request to DECE to precise the requirements.

Bob: Let me take that as an action item to see how much more specific I can get right now.
... The more specific requirements we get, the better, I think.

Clarke: OK, so we're out of time. Thanks, let's continue discussion on the mailing-list.

[Call adjourned]

<kaz> ACTION: lund to see how much more specific issue-41 description could be [recorded in http://www.w3.org/2011/09/01-webtv-minutes.html#action01]

<trackbot> Created ACTION-74 - See how much more specific issue-41 description could be [on Bob Lund - due 2011-09-08].