See also: IRC log
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> 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
-> http://lists.w3.org/Archives/Public/public-web-and-tv/2012Jan/0052.html Duncan's message
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
-> http://www.w3.org/2011/webtv/wiki/MPTF/ADR_Minimal_Control_Model_Proposal#Use_Cases ADR Minimal Control Model Proposal
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 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
clarke: outlining model 3
script
... the best place to start with is error code page
<Clarke> discussion: 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?
-> http://www.w3.org/2011/webtv/wiki/MPTF/ADR_Error_Codes#Feedback 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 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