Bug review

clarke: any update 13359?

bob: no update
... although the bug change the state

-> https://www.w3.org/Bugs/Public/show_bug.cgi?id=13359 bug 13359

clarke: what about any other bugs?
... changes?

Adaptive Bitrate Requirements

-> http://dvcs.w3.org/hg/webtv/raw-file/tip/mpreq/MPTF-ADB-Requirements.html ABR Requirements

clarke: there was bad link and got fixed
... in Terminology section
... Adaptive Bit Rate , Adaptive Bit Rate Method, and Adaptive Bit Rate System
... definition updated
... make sense?

kevin: seems reasonable

clarke: definition of "Open Source"?

<glenn> thinks we should avoid defining

<glenn> suggests simply putting it in quotes

<glenn> yes

<glenn> quote Open Source, as in "Open Source"

kaz: we can refer to W3C Glossary but maybe we don't have to define it

Glenn: can quote Open Source, as in "Open Source"

clarke: objections?

(no objections)

clarke: section 4.1.7, last sentence
... "Support for different ABR systems should not require any proprietary modification of the user agent"

acolwell: not sure about "any proprietary modification"

clarke: secret information

markV: must be implemented by JavaScript?

clarke: in another words, no secret information is required by ABR vendors/systems

kaz: the period at the bottom of the line is missing :)

clarke: ok
... next 4.1.8
... "The ability for a browser vendor to implement playback of ABR media in accordance with the requirements in this document must be supported."
... any ideas?

markV: sounds fine

clarke: 4.1.9
... was not clear
... now "While specific implementations may include vendor-specific parameters for special features, the parameters required for basic playback should be publicly specified."

acolwell: good

clarke: 4.1.10
... "While specific implementations may include vendor-specific error codes, the error codes required for basic operation and diagnosis should be publicly specified. However, the particular ABR systems to be supported is an implementation decision."

acolwell: vendor specific error codes?
... not sure
... does that mean you need stop playing?

kevin: what if we have set of errors?

clarke: error class for various errors?

acolwell: it depends on how you define error codes
... how to identify if we can go ahead if the error is minor

clarke: error codes might be vendor-specific

acolwell: currently we don't have any vendor-specific error codes

clarke: what about you, Kevin?

kevin: typically we're just mapping to existing error codes

clarke: do we have enough flexibility?
... return text message, etc.?

kevin: error object handles error codes asis

clarke: we could add a statement saying if vendor would like to add additional mechanism...

kevin: more specific status information, e.g., just return code but don't panic

clarke: you should suggest concrete text here

<KevinStreeter> "a mechanism for supporting implementation specific status should be supported"

clarke: next "Byte Range, Events, ..."
... and "6. Security"
... use cases on content protection

(no specific comments)

clarke: section "7. Identified Gaps"
... buffer management, capability detection, and append URL
... buffer management is implementation specific
... anything to say about that?

duncan: other content provider might want advertise into buffers
... re-buffer the one previously buffered

clarke: would we support that?

kevin: +1

acolwell: requirement should be inserting other contents?

duncan: yes

clarke: what about "Capability Detection"?
... capability must be identified
... I was hoped this section was empty
... if we identify gaps, we add use cases and update the "Identified Gaps" section

acolwell: what kind of use cases should be included?

clarke: will send a message to the ML and ask for opinion about Capability Detection
... what about "Append URL"?

acolwell: appending URL should be allowed given JavaScript
... but mixing the requirements of adaptive streaming and media handling

clarke: suggesting you can avoid payload of JavaScript?
... if your implementation have payload for JavaScript, it should be avoided?

kevin: do we want to make it a requirement?
... or is that sort of option?

duncan: throw through JavaScript layer for embedded device

kevin: we have a mechanism for embedded device

clarke: not pass through?

bob: if we want it available it should be added

acolwell: BLOB URL might be appended

clarke: don't want to restrict implementations
... requirement is implementation should not restrict implementation either load the payload through JavaScript or not
... minimizing copy
... "9. Proposals" and "A. Acknowldegements"
... will update the document

kaz: minor question: A and B are appendices. right?

clarke: yes
... will do the same review for Content Protection as well

[ adjourned ]