W3C home > Mailing lists > Public > public-web-and-tv@w3.org > September 2011

[MEDIA_PIPELINE_TF] Minutes Call 2011-09-01

From: Francois Daoust <fd@w3.org>
Date: Fri, 02 Sep 2011 08:47:15 +0200
Message-ID: <4E607BF3.2020803@w3.org>
To: "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>

The minutes of yesterday's call are available at:

... and copied as raw text below.

Discussions around TV services mapping table (ISSUE-39), and first content protection use cases (ISSUE-40 and ISSUE-41).


Media Pipeline TF Teleconference (Web and TV IG)

01 Sep 2011


       [2] http://www.w3.org/2011/webtv/wiki/MPTF/Agenda_Telco_1st_September_2011

    See also: [3]IRC log

       [3] http://www.w3.org/2011/09/01-webtv-irc


           Kazuyuki_Ashimura, Steven_Wright, Duncan_Rowden,
           Francois_Daoust, Tatsuya_Igarashi, Bob_Lund, Jan_Lindquist,
           Narm_Gadiraju, Mark_Vickers, David_Corvoysier,
           Russell_Berkoff, Juhani_Huttunen, Panu_Markkanen




      * [4]Topics
          1. [5]TV services media transport mapping (ISSUE-39)
          2. [6]Content delivery in distribution windows (ISSUE-40)
          3. [7]Support of content owner rights (ISSUE-41)
      * [8]Summary of Action Items

    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

       [9] 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.


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

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

      [10] 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
    ... 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> [11]http://www.w3.org/2011/webtv/track/issues/18

      [11] 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
    ... 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

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

    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

    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:

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

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

    Bob: I try to tie in needs for content protection with business
    ... 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
    ... 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

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

Summary of Action Items

    [NEW] ACTION: lund to see how much more specific issue-41
    description could be [recorded in

    [End of minutes]
Received on Friday, 2 September 2011 06:47:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:44:04 UTC