Status of the Media TF in the HTML WG

Clarke: Call for consensus on the creation of the Media TF in HTML ended yesterday
... Not more insight on what will happen next

John: Not familiar with the process

markV: It will be on the agenda of the HTML TF today

Discuss status of open MPTF bugs and what (if anything) still needs to be done with them

Clarke: Bugs: a precision has been added on one of the bugs

<kaz> Dashboard wiki

Clarke: Did anybody notice new bugs relevant to this group ?

-> No answer

requirements document

<Clarke> ABR Requirements: http://dvcs.w3.org/hg/webtv/raw-file/35ffe94c6c64/mpreq/MPTF-ADB-Requirements.html

Clarke: Apologize for being a mercurial newbie
... Feel free to make changes and help me updating the document

<kaz> Latest draft

Clarke: Not everything seems to have been pushed to mercurial

<joesteele> I am muted ...

<ph> ty

Clarke: Opinions on the ABR reqs ? Terminology section ?

Aaron: Active ids is not required

<acolwell> http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html

Aaron: update the url to the meida source proposal already submitted to the W3C

Clarke: Source/Track buffers ? any comments
... Maybe these terms should be only explaine din the referenced proposals
... Missing Definitions have been posted to local repo: should be upstream soon
... Anything missing in paragraph 4

Joe: What was the resolution on the errors ?

Clarke: That's still open
... 4.1.2 media tag instead of audio & video ? did that to differentiate from the object tag
... in paragraph 4, one must be very careful with the language used to express the fact that everything should be open, both in terms of solutions and implementations

John: open is a loaded word
... whatever ABR techno is used is not important: enabling a techno is not specifying it

Clarke: little uncomfortable with language related to open source browsers

John: examples of where this req should apply ?

Clarke: I want to avoid to imply that if an ABR solution is not open source, it cannot be made available in an open source browser

Mark: some formats will _not_ be supported by all UAs

John: To that extent req 4.1.9 cannot fully apply

Aaron: It should be possible to create an ABR system that everybody supports ?
... I am not advocating for us choosing a format, but there may be an open source format option, that is a format that could be implemented by every UA

John: What is the definition ? RF ?

Joe: Is there a W3C definition of what _is_ open source ?

Philipp: By definition, a spec is not source code. The question is whether it can be implemented in an open source environment

<kaz> w3c glossary (just fyi)

Philipp: I don't have the answer: would need to check with open source experts

John: Do we need this req altogether ?
... The debate is not open source vesus closed source: it seems more related to being agnostic to ABR systems
... You don't need to specify anything specific to any ABR system, actually: only specify the spec allowing to use them

Clarke: Just want to make sure we don't prevent any implementation in open source browser

Mark: We are mixing spec and code (and confusing the scribe a lot !!!)
... The fact that a specification has to be published for free encourages the implementation of it by open source
... The issue in all W3C spec, especially with these two, is that there is nothing implying that the tech below the W3C specs need to be RF also

Clarke: I am willing to be convinced that req 4.1.9 is implicit: is that the consensus in the group^

<joesteele> +1 implicit

Aaron: I would say that the W3C spec for ABR or EC must be implementable RF

<glenn> are you saying that *all* ABR/ECs need to be implementable RF?

Juhani?: The API must work with open source browser, but we should not tak any position related to format or the Royalties associated to lower level APIs

<glenn> i agree that the API itself (that W3C defines) should be implementable RF, but it goes too far to say that the underlying semantics of a specific ABR (that is exposed by that API) must also be implementable RF

Clarke: We should to be more explicit in this req
... Still no consensus, will leave it in by default until we work on the wording

Joe: Something alogn the lines could be added "To the extent that the W3C already requires specs to be RF"

<Juhani> +1

Clarke: Would suggest wording

Bob: Could we be more explicit that audio abd video should support playback of content delivered using ABR

Clarke: Will take Bob's suggested wording offline
... About parameters, the clarification that i am trying to make is that we don't limit the number of parameters that can be used, but instead specify a minimum set
... A pretty good starting place here !
... Please take a look at this doc next week, and also on the EC doc (hope the changes will be pushed this time)
... AOB ? Not ?

Meeting adjourned

<Clarke> Thanks, David

<kaz> [ adjourned ]