- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Fri, 13 Jan 2012 02:20:56 +0900
- To: public-web-and-tv@w3.org
available at:
http://www.w3.org/2012/01/12-webtv-minutes.html
also as text below.
Thank you very much for taking these minutes, John!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
MPTF call
12 Jan 2012
[2]Agenda
[2]
http://www.w3.org/2011/webtv/wiki/MPTF/Agenda_Telco_12th_January_2012
See also: [3]IRC log
[3] http://www.w3.org/2012/01/12-webtv-irc
Attendees
Present
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,
Mark_Watson
Regrets
Chair
Clarke
Scribe
johnsim
Contents
* [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
editor
<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
<Mike5>
[8]http://dev.w3.org/html5/decision-policy/decision-policy-v2.html
[8] http://dev.w3.org/html5/decision-policy/decision-policy-v2.html
<Mike5>
[9]http://dev.w3.org/html5/decision-policy/decision-policy-v2.html#b
asic
[9]
http://dev.w3.org/html5/decision-policy/decision-policy-v2.html#basic
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
"escalate"
... 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
thanyou
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
resolution
... 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
... 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
bugs
... 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
resolved
... 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
resolved
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
escalate
... 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
discuss
Adaptive streaming
<JanL>
[10]http://www.w3.org/2011/webtv/wiki/MPTF/ADR_Minimal_Control_Model
_Proposal
[10]
http://www.w3.org/2011/webtv/wiki/MPTF/ADR_Minimal_Control_Model_Proposal
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
target
CT1
CT2, we are not talking about bandwidth, we are talking about
reprsentation
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
response
... 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
purpose"
Clarke: give people a week, and if no one responses by then, we drop
it
... 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
complex
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
connection?
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
Feel"
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
manifest
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