- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Fri, 27 Jan 2012 02:11:35 +0900
- To: public-web-and-tv@w3.org
available at:
http://www.w3.org/2012/01/26-webtv-minutes.html
also as text below.
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Media Pipeline TF call
26 Jan 2012
[2]Agenda
[2]
http://www.w3.org/2011/webtv/wiki/MPTF/Agenda_Telco_26th_January_2012
See also: [3]IRC log
[3] http://www.w3.org/2012/01/26-webtv-irc
Attendees
Present
Mark_Watoson, Clarke, Duncan, Russell, Paul, Kazuyuki, Jan,
Philipp, Franck
Regrets
Chair
Clarke
Scribe
kaz
Contents
* [4]Topics
1. [5]updated charter statement
2. [6]model 3 solution
* [7]Summary of Action Items
_________________________________________________________
updated charter statement
jan: not attended but question about lower/upper limit
ph: content protection?
clarke: there was netflix proposal, but not for this week
... Duncan was adding text
<duncanr>
[8]http://www.w3.org/2011/webtv/wiki/MPTF/Agenda_Telco_19th_January_
2012
[8]
http://www.w3.org/2011/webtv/wiki/MPTF/Agenda_Telco_19th_January_2012
duncan: agenda for last week
clarke: seems fine to me
... any comments?
jan: comment from David?
clarke: discussed last week, and ok
->
[9]http://lists.w3.org/Archives/Public/public-web-and-tv/2012Jan/005
2.html Duncan's message
[9]
http://lists.w3.org/Archives/Public/public-web-and-tv/2012Jan/0052.html
duncan: suggesting more generic text
jan: found it
... what is the change?
duncan: 1. of "4. deriverables"
jan: what is the actual change?
duncan: text for revised charter is included there
... that's written in "2. Updated charter statement and schedule"
jan: got it
clarke: next one is Jason's comment
... any comments to Jason's text?
... about CT1
jan: missed the discussion during the previous call
->
[10]http://www.w3.org/2011/webtv/wiki/MPTF/ADR_Minimal_Control_Model
_Proposal#Use_Cases ADR Minimal Control Model Proposal
[10]
http://www.w3.org/2011/webtv/wiki/MPTF/ADR_Minimal_Control_Model_Proposal#Use_Cases
jan: looks fine
clarke: and now we'd talk about CT2
... best quality might be not available
... use cases we'd require for CT2?
... Jan, do you have any comments?
... or can we just drop it?
jan: sent a comment
... relationship between CT2 and CT3
... CT3 specifies lower quality, and CT2 mentions upper quality
... issues for mobile phone, etc.?
clarke: general agreement on maximum bandwidth
jan: not talking about bandwidth but quality
clarke: how would you see it fits?
... what would you do?
jan: exception error on the response
markW: problem is we have no JavaScript for particular case
... maximum/minimum quality based on the bandwidth
jan: how do we discover what kind of level is present?
... is it enough to specify control parameter?
... based on upper or lower limit
markW: don't think we have architectural solution
... how adaptive streaming work
jan: I'd agree with you 90%
clarke: sounds like kind of agreement
... CT2 could be dropped
... Jan, do you think we could drop CT3 as well?
jan: both talking about same general area
clarke: CT1 captures bandwidth
... CT2/3 capture quality
... suggestion is CT2 and CT3 could be removed
jan: controlling buffer size
... might exceed with maximum bandwidth
clarke: we can remove 2 and 3, and add note necessary speed
... make sense?
... my proposal is:
... let's drop CT2 and CT3
... and then see what would be more effective
RESOLUTION: drop CT2 and CT3
<scribe> ACTION: Stevens to drop CT2 and CT3 [recorded in
[11]http://www.w3.org/2012/01/26-webtv-minutes.html#action01]
<trackbot> Created ACTION-91 - Drop CT2 and CT3 [on Clarke Stevens -
due 2012-02-02].
markW: fine with me to remove minimum bandwidth
clarke: anybody wants to keep minimum bandwidth?
(none)
clarke: ok with dropping minimum bandwidth as well
RESOLUTION: drop minimum bandwidth
clarke: the rest of the agenda is discussion on model 3
model 3 solution
clarke: outlining model 3 script
... the best place to start with is error code page
<Clarke> discussion:
[12]http://www.w3.org/2011/webtv/wiki/MPTF/ADR_Error_Codes
[12] http://www.w3.org/2011/webtv/wiki/MPTF/ADR_Error_Codes
clarke: control parameters
... maximum bandwidth there
... look below
... in feedback area
... model 2, 3 support
... might be useful to talk about how we anticipate model 3 working
... any volunteer?
->
[13]http://www.w3.org/2011/webtv/wiki/MPTF/ADR_Error_Codes#Feedback
Feedback
[13] http://www.w3.org/2011/webtv/wiki/MPTF/ADR_Error_Codes#Feedback
duncan: the problem is we don't know about all the capability
... handle those on your manifest file
... segment size, etc.
... it would require JavaScript developer to know how to handle
header, etc.
markW: can start with requirments
duncan: can provide explanation by email
... passing requirements for HTML.next?
clarke: once we sort out our requirements, we can consider it
ph: (couldn't hear)
clarke: that's one reason, another is providing developer to more
control
... your video presents more experience
Kilroy: JavaScript decoder is built-in
... there would be big valuable
ph: wanted answer about MPEG-DASH
Kilroy: another issue on appending is
... just appending whatever in the past decoded would over writes
buffer
markW: we shouldn't think of appending
... should require each chunk to be handled appropriately
Kilroy: two types
... segment audio/video those tracks could be independently handled
... video might be cut into chunks
... accurate point is needed
... common time base for audio/video is required
... what if two segments passed at same time
... very different API is needed
... independently works
clarke: could we have a ladder diagram, etc.?
... and see what is needed for which case?
... anybody would volunteer?
... if not, I'll generate a first draft
<scribe> ACTION: Stevens to create a diagram [recorded in
[14]http://www.w3.org/2012/01/26-webtv-minutes.html#action02]
<trackbot> Created ACTION-92 - Create a diagram [on Clarke Stevens -
due 2012-02-02].
clarke: any other questions from architectural perspective?
duncan: just thinking about passing large chunks
... through JavaScript
... especially coming through HTTP
... your client may have access other than HTTP
... how to handle chunks using JavaScript?
markW: (much noise)
Clarke: Mark mentioned you'd not necessarily put all the chunks
using JavaScript
<mark> I would suggest this is still modeled as a separate download
capability (XmlHttpRequest) passing data to a Media Element
clarke: different API might be needed
... download rate, representation ID, buffer rate
... feedback on those parameters?
... the ladder diagram should mention them
... I'll put together the diagram, and ask everybody for comments
... walkthrough next week
<mark_> (connection problems) My last point was that optimizing the
data flow is something we should return to after solving the other
problems
clarke: any comments on that approach?
... comments based on your implementations would be welcome
... topics for today are done
... any other comments, topics?
[adjourned]
<Clarke> Thanks, kaz
Summary of Action Items
[NEW] ACTION: Stevens to create a diagram [recorded in
[15]http://www.w3.org/2012/01/26-webtv-minutes.html#action02]
[NEW] ACTION: Stevens to drop CT2 and CT3 [recorded in
[16]http://www.w3.org/2012/01/26-webtv-minutes.html#action01]
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [17]scribe.perl version 1.136
([18]CVS log)
$Date: 2012/01/26 17:10:21 $
[17] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[18] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 26 January 2012 17:12:45 UTC