See also: IRC log
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?
-> 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 ]