[MEDIA_PIPELINE_TF] minutes - 12 January 2012

available at:

also as text below.

Thank you very much for taking these minutes, John!



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

                                - DRAFT -

                                MPTF call

12 Jan 2012



    See also: [3]IRC log

       [3] http://www.w3.org/2012/01/12-webtv-irc


           Russell_Berkoff, Clarke_Stevens, Bob_Lund, Glenn_Adams,
           Kaz_Ashimura, John_simmons, Mike_Smith, Duncan_Rowden,
           Franck_Denoual, Jan_Lindquist, Yamini_Nimmagadda,
           Jason_Lewis, Juhani_Huttunen, Mark_Vickers, Narm_Gadiraju,




      * [4]Topics
          1. [5]Discuss escalation of bugs to tracker issues
          2. [6]Adaptive streaming
      * [7]Summary of Action Items

Discuss escalation of bugs to tracker issues

    Clarke: deadline Jan 14TH need to be escalated in order not to be
    dropped... any clarification on that?

    <glenn> i don't believe it means they will be dropped if not
    escalated; rather, they (bugs) are subject to resolution by the

    <Clarke> JanL: add discussion on adaptive streaming emails

    Kaz: announcement from paul cotton yesterday - talk with Mike Smith
    - how to deal with comments

    Mike will explained details on this call

    Mike5: Paste in a URL


       [8] http://dev.w3.org/html5/decision-policy/decision-policy-v2.html



    Mike5: current decision policy in the working group
    ... two points - the flowchart - step raise bug, editors response,
    this is how it was envisioned
    ... after response - review response and then decide if you are
    satisfied or not - if satisfied, close the bug - if not, then
    ... right to take that issue to next level of appeal - in this case,
    you have different people who are responsible for resolution at diff
    points in the process

    bugs in Bugzilla, editor of the spec is responsible, --- if you
    disagree - chairs are the "court of appeals"

    Mike5: meant to kickin when you have reached a point of disagreement
    that is otherwise unresolvable


    Mike5: as part of the timeline that the chair announced, they said
    if editor had not resolved by 31st, you have an option of escalating
    them automatically regardless of whether you had received a
    ... it is an option, not a requirement. and another thing - no bug
    is ever dropped - will be resolved regardless
    ... remains in the same state that it is in now - waiting for
    further review by editor - or waiting for the editor to ask
    questions of bug commenter
    ... in my assessment, none have reached an point of impass with
    ... Hixie - can be three weeks before he can get around to
    commenting - in some things we have offloaded - but he is working on
    a lot of stuff
    ... do not think it is the case that he has ignored bugs -
    proceeding naturally or normally -
    ... risk of escalating bugs - if you take a bug and ask it into a
    working group issue, you are asking Hixie to stop working on those
    ... suggest that is not the best thing to happen at this particular
    point in time
    ... another thing to keep in mind, what we are trying to do is not
    necessarily get stuff into the spec, it is to get stuff implemented
    in browsers -
    ... get browser mfg working on the use cases and some indication
    that they are not completely opposed to implementing a particular
    proposed feature
    ... escalating means additional 2 months process - to getting
    ... numerous steps 2-3-4 weeks with time to review - and at a
    minimum that is 2 months of work from escalating to when you have a
    chance of getting a decision from the working group

    <glenn> escalating (making a bug a wg issue) is best done only after
    editor has resolved the bug in a manner not acceptable by the
    submitter; note that a closed bug may be reopened, so one may go
    through multiple rounds with the editor before choosing to escalate
    to issue;

    clarke: sonds like you are suggesting not escalating - but
    consequences - this has been characterized as a deadline

    Mike5: not suggesting what you do... you do still have - if you
    decide to - to escalate - if you think that will help resolve sooner
    rather than later

    BobLund: question - any bug there is still discussion with editor -
    bug is still considered open - it will stay and be worked on

    Mike5: absolutely
    ... using bugzilla as last call counter
    ... no comment every submitted in bug tracker ever gets dropped on
    the floor

    <glenn> Mike5: all registered bugs (in bugzilla) will eventually be

    Mike5: value proposition for escalation, working group - must fix
    during next last call round - cannot go to CR without these bugs
    being resolved

    Mark Vickers: good advise, personally pleased with feedback and
    handling, don't want to short circuit

    January 14th date - make sure we do the things we are supposed to do

    Clarke: objective of this group is to get the bugs addressed, and
    not escalating will perhaps get this done more efficiently
    ... we should look at each bug, but for those awaiting response from
    editor, we should let them follow their natural process and not
    ... hearing nothing, that is the recomendation - suggest you each
    look at the bugs and see if that is the case

    <Zakim> Mike, you wanted to say thanks for having me on and gotta
    drop off for another call and please contact me by e-mail if you
    have other specific questions

    <Mike5> mike@w3.org

    Mike5: contact me by email if you have additional questions

    Clarke: next agenda - updated charter statement

    Any comments or wait until next week when we have a statement to

Adaptive streaming



    JanL: post link on draft we are working on - touch on - see if there
    is a conclusion
    ... first to touch on, feedback from Jason (Disney), question
    usability from a - not talking - SD HD, not using the minimum
    bandwidth to control the profile

    Jason: maximum more important than minimum, quality tied to minimum

    JanL: go into the quality aspect, the use cases, CT1 sets a specific


    CT2, we are not talking about bandwidth, we are talking about

    JanL: higher lower quality should be addressing CT2

    Clarke: i think - you point Jan - in case of max bandwidth, obvious
    the appropriate response is to send less data
    ... in case of minimum, we need to be more specific in suggested
    ... what is the expected action?

    JanL: I am not clear - and touches on another area - diff
    application - maximum and minimum i expect my application to use -
    which is another issue

    BobLund: so in response, Clarke, it is adaptive bitrate, it is the
    user agent decision, so the answer is you exceed the maximum, signal
    to the user agent to only select from a lower bitrate
    ... Even if resources suggest higher
    ... if we specify a min, resource has no recourse except to treat as
    a network error - max makes sense to me, min not so much

    Mark_Watson: happy for minimum to be removed

    JanL: haven't identified who in the task force "i need it, and for
    this purpose" --- no one has pointed to a "i need it for this

    Clarke: give people a week, and if no one responses by then, we drop
    ... do this from the minutes

    JanL: CT1 requirement states overall bandwidth usage - what does
    that mean? adaptive only or whole browser?
    ... my impression we were speaking only of adaptive streaming, so
    suggest reword to clarify
    ... architecture for overall bandwidth management is much more

    Jason: i agree, and focus on version 1, a "hint" of what the maximum
    should be

    JanL: TCP/IP socket, clear means of managing the socket

    Jason: is intent to limit the bandwidth to that cap, or suggest
    which bandwidth it should be picking?
    ... does it need to be more explicit - to describe - to be clear it
    is either the set of bitrates or the bandwidth of the tcp

    Clarke: more the level, a hint to the user agent on the bandwidth -
    between you and Jan propose some language

    JanL: suggestion limit adaptive bitrate streaming bandwidth

    Jason: rephrase in the control parameters -

    JanL: you do this?

    Jason: okay

    JanL: one more
    ... puzzled with CT2 - want a means of selecting only HD level, but
    don't see control parameters for that use case
    ... remove CT2 or add controls - old discussion - but to have this
    use case, we need to specify the control parameter

    Clarke: touches on your first point
    ... 1) parameter that allows us to specify that and then the
    response wouldbe what bob suggested, if you can meet this, return
    error message "i can't maintain level you required"

    JanL: HD level, HLS, MPEG DASH, there is a reprsentation for HD, not
    bandwidth, it is a representation, convey to UA an HD level quality

    Clarke: do we believe in the requirements, CT2 - people support, and
    then how do we convey that requirement

    JanL: I vote leave it (CT2) and we address it

    Jason: HD Level is combination of bitrate and resolution -
    ... trying to capture HD as a bandwidth thing does not directly
    correlate - bitrate quality and resolution quality give you the "HD

    JanL: HD for me is a representation, not a matrix of bandwidth - i
    understand different resolution, different factors, but a means of
    conveying to the UA I want an HD representation
    ... we have reprsentation changes call back - we have errors with
    manifest not being able to parse - all i am missing is how the
    representation is being selected

    JanL: Mark_Watson, you are questioning CT2

    Mark_Watson: that kind of control to the web page, language
    independent of the manifest

    or if under the covers by the UA, giving the user control, something
    the UA should be responsible for - two approaches to handle CT2 in
    model 1

    JanL: what is the second model,

    Mark_Watson: language for constraint to be expressed independent of

    Mark_Watson (?): user agent that knows what is available, so should
    give the user what is available -

    janl: list from UA representations in their own language, and then i
    can set - maximum quality using this representation

    Mark_Watson: manifest independent language for quality levels
    ... UA exposes in a non-browser/adaptive streaming specific manner

    Mark: haven't investigating media queries - different choices in
    source elements

    <JanL> is this the media queries?

    <JanL> [11]http://www.w3.org/TR/css3-mediaqueries/

      [11] http://www.w3.org/TR/css3-mediaqueries/

    Bob_Lund: expressing preferences - not media queries - constraints
    to the UA - independent of each other - i think

    Clarke: we can continue this on the reflector and have it as an item
    for the agenda next week

    JanL: buffer size question - but defer to the next phone conference

    <Clarke> Thanks for scribing, John

Summary of Action Items

    [End of minutes]

     Minutes formatted by David Booth's [12]scribe.perl version 1.136
     ([13]CVS log)
     $Date: 2012/01/12 17:20:58 $

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

Received on Thursday, 12 January 2012 17:26:47 UTC