W3C home > Mailing lists > Public > public-web-and-tv@w3.org > February 2012

[MEDIA_PIPELINE_TF] minutes - 16 February 2012

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Fri, 17 Feb 2012 01:58:06 +0900
Message-ID: <4F3D359E.7040707@w3.org>
To: public-web-and-tv@w3.org
available at:

also as text below.

Thanks a lot for taking these minutes, Dave!



       [1] http://www.w3.org/

                                - DRAFT -

                Media Pipeline Task Force Teleconference

16 Feb 2012



    See also: [3]IRC log

       [3] http://www.w3.org/2012/02/16-webtv-irc


           Clarke, glenn, Dave_Mays, MarkW, Juhani, Bob_Lund,
           John_Simmons, Duncan, Kazuyuki, Philipp, Mark_Vickers, Jason,
           Narm_Gadiraju, Joe_Steele, Giuseppe


           Dave_Mays, davidmays


      * [4]Topics
          1. [5]Agenda
          2. [6]open bugs
          3. [7]Model 3 Architecture
      * [8]Summary of Action Items

    <trackbot> Date: 16 February 2012

    <davidmays> scribe: Dave_Mays

    <davidmays> scribe: davidmays


    Clarke: welcome Joe Steele from Adobe

     Joe is a content protection expert

     describing agenda

    <joesteele> thanks! I am still trying to dial in -- bad phone setup
    on my side

     asking Mark Watson about updated content protection proposal

    Mark Watson: will be updating sometime next week, working offline
    with other companies

    Clarke: next week's main topic will be content protection

open bugs


       [9] http://www.w3.org/2011/webtv/wiki/MPTF#Bugs

    Bob Lund: I was asked by Ian to provide pointer to a spec for

     I posted a spec for AC3 audio that matches this

     no response from Ian yet

     LC13359 - long discussion thread, I supplied some more detailed
    information. Ian thinks this is complicated. The ball is in Ian's

    Clarke: need to add LC13358. Maybe it's already resolved?

     asking for other comments on the rest of the bugs

Model 3 Architecture

    Clarke: mentions that Kilroy was going to summarize comments from
    last week's call, will follow up with Kilroy.

     any other comments on Chromium WIP proposal?

    Mark Watson: if people have comments on chrome media extension, they
    should contact the author

    Clarke: let's look at Adaptive Bitrate control section and get

     Video tag makes it easy to discern what's in the HTML, instead of
    using something like <OBJECT>

     proposal from Chromium meets this criteria

    Bob Lund: couple of comments

     1 issue is whether the tag is video/object

     2 whether the solution needs to support <video>

     strongly supporting the use of <video> element, rather than
    <object> due to all the HTML5 work that has already been done

    Clarke: common time reference

     kilroy brought up overlapping tracks need to be handled

     any disagreement on the common time reference requirement?

    Glenn: in trick modes (play speed !=1) is there a good model for
    time for this in HTML or is it left to the underlying protocol and

    Bob Lund: there is a definition for playspeed in HTML5. pretty clear
    cut what UA behavior should be for different playback rates

     similarly for seeking within stream - also well defined using
    seekable range objects or attributes

    Clarke: what is the range relative to?

    <glenn> +q glenn

    <Juhani> I am on the call

    Bob Lund: it's sourced off the video, complicated with multiple
    videos. base ref defined from one of the videos in HTML5 spec

    Mark Watson: it would depend on protocol using to retrieve the video
    - no server involvement on HTTP streaming, but with RTSP there is
    server involvement

    Clarke: HTML5 spec does not say if you change play speed, how to
    make use of underlying protocols

     other specs may cover it, but not HTML5

    Glenn: the spec *could* say that resolution of play-time is governed
    by protocol in use by the referenced URI

    Mark Watson: it's mainly up to client capability to support FF/RW

     depends how it interprets the media data from the server

    glenn: i have concerns about a lack of any language in this area in
    the spec

     e.g. if the server is delivering video over HTTP and it is
    performing trick-play on the server, does the client know that?

    MW: that's a media protocol/format issue, not an HTML5 issue

    Clarke: agree

    Bob Lund: HTML5 API is agnostic to that. just use the specified
    attributes to specify play speed

     haven't seen a deficiency in that area

    Clarke: to double play speed in HTTP, specify in HTML that you want
    a play speed of 2. presumably the UA would issue the correct

     after that the HTML doesn't need to know

    Glenn: b/c HTML5 defines a playspeed attribute that is mutable, JS
    can change that value

     any server-initiated change handler is unspecified

     should HTML5 provide a mapping that gives guidance to implementors

    Bob Lund: in DLNA we saw that it was necessary to provide that

     in HTTP adaptive, the goal has been to make use of standard HTTP
    without any further mapping

     does not seem to be a part of the HTML5 spec

    glenn: not suggesting that it should be, but HTML5 leaves it blank
    as to how mutations of play speed should be mapped

    Clarke: try to come up with a use case where there is ambiguity in

    MW: HTML5 doesn't specify protocols, so this isn't the right place
    for that kind of thing

     should be included in the protocol specification instead

    Clarke: mixing of tracks with different time references - does HTML5
    specify anything like a "master" track?

    Bob Lund: don't know enough details about time management to answer

    Clarke: let's see if we can resolve time reference issues

    Bob: kilroy should bring up some use cases to illustrate this

    MW: multi-track support in HTML, each element has a timeline from
    start to zero, and all those need to be aligned

     if multiple inbound tracks from a media format, we depend on the
    format to provide alignment

     if switching between bitrates, need to make sure that segments are

     just need to be clear about where the timelines need to be

    Clarke: i will open an issue on this and we can put up some use

     anything more about search and trick-play to talk about?

     want to determine ASAP if a UA can handle a type of content

     let's come to a consensus on this

     does this req't need restatement


      [10] http://www.w3.org/2011/webtv/wiki/MPTF#Adaptive_Bit_Rate

     no different wording proposed

     how do we best resolve this?

    Dave Mays: reading the requirement from the wiki - "The ability of
    the user agent to play a piece of content must be determined quickly
    and with reasonable accuracy (e.g. using CanPlayType(codec, level,
    profile) or other means)"

    Clarke: the less we have to process before getting an answer, the

     if you can get it from mime type or canPlayType() that's better
    than going into the UA and getting an error

    Bob: may want to restate it a little bit

     "what in the various adaptive formats needs to be reflected in the
    mime type to support the existing HTML5 spec behaviors"

     need to talk about specifics in the protocols/formats that would
    identify this

     we need to get down to specifics

    *problems with Bob's audio*

    Jason Lewis: we have apps where we need to find out whether we *can*
    use the Video tag on a particular device

     want to get a list of supported playback types from the UA

     maybe inject flash instead, or no video container at all

    Bob: in HTML5 today there is fallback to object element

     need more than that?

    Jason: wrapping in objects until one succeeds works, but rather
    query an API for supported types

     want the application to make an active decision rather than use

     want to query the UA somehow

    Bob: do that with a JS function and call canPlayType() to query now

    Glenn: that means you have to have a list in mind first

    Clarke: is there a precedent for anything similar?

    Dave Mays: does that expose an information security issue? "what do
    you handle" vs "do you handle x"

    Jason: does that try to download content at all?

    Bob: No

    Jason: comfortable with this requirement now

    Clarke: point about sniffing may also be relevant. most things in
    HTML are asked in the form of "do you support x" rather than "what
    are all the things you support"

     asking for other requirements that should be in this list

     talk about procedure

     when something gets listed in req'ts list, i'll put an indication
    whether it's "OPEN" issue or not

     will link to an actual Wiki ISSUE

     leave open until we get resolved

     keep dashboard relevant for current topics

     any other topics for today?

     dive into content protection next week, hope to see netflix

    <kaz> [ adjourned ]

    you're welcome

Summary of Action Items

    [End of minutes]

     Minutes formatted by David Booth's [11]scribe.perl version 1.136
     ([12]CVS log)
     $Date: 2012/02/16 16:50:24 $

      [11] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [12] http://dev.w3.org/cvsweb/2002/scribe/

Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
Tel: +81 466 49 1170
Received on Thursday, 16 February 2012 16:59:09 UTC

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