[MEDIA_PIPELINE_TF] minutes - 16 February 2012

available at:
http://www.w3.org/2012/02/16-webtv-minutes.html

also as text below.

Thanks a lot for taking these minutes, Dave!

Kazuyuki

---
    [1]W3C

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

                                - DRAFT -

                Media Pipeline Task Force Teleconference

16 Feb 2012

    [2]Agenda

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

    See also: [3]IRC log

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

Attendees

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

    Regrets
    Chair
           Clarke

    Scribe
           Dave_Mays, davidmays

Contents

      * [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

Agenda

    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

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

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

    … 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
    court

    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
    feedback

    … 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
    layers

    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
    requests

    … 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
    HTML

    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
    that

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

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

    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
    aligned.

    … just need to be clear about where the timelines need to be
    aligned.

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

    … 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

      [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
    better

    … 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
    fallbacks

    … 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
    proposal

    <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