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> 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

model 3 solution

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