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
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
... 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
... 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
... what would you do?
jan: exception error on the response
markW: problem is we have no
... 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
... how adaptive streaming work
jan: I'd agree with you 90%
clarke: sounds like kind of
... CT2 could be dropped
... Jan, do you think we could drop CT3 as well?
jan: both talking about same general area
clarke: CT1 captures
... CT2/3 capture quality
... suggestion is CT2 and CT3 could be removed
jan: controlling buffer
... 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?
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
... 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?
duncan: the problem is we don't
know about all the capability
... handle those on your manifest file
... segment size, etc.
markW: can start with requirments
duncan: can provide explanation
... 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
... there would be big valuable
ph: wanted answer about MPEG-DASH
Kilroy: another issue on
... just appending whatever in the past decoded would over writes buffer
markW: we shouldn't think of
... 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
... 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
... especially coming through HTTP
... your client may have access other than HTTP
markW: (much noise)
<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
... 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
... comments based on your implementations would be welcome
... topics for today are done
... any other comments, topics?
<Clarke> Thanks, kaz