W3C home > Mailing lists > Public > public-media-capture@w3.org > January 2013

First agenda proposal for f2f meeting

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Tue, 15 Jan 2013 11:48:44 +0100
Message-ID: <50F5340C.9020001@ericsson.com>
To: "public-media-capture@w3.org" <public-media-capture@w3.org>
Hi all,

below is a first proposal of agenda items, along with some info on what 
we thought should be covered, for the Boston face-to-face meeting. It 
includes Media Capture TF and WebRTC WG for completeness.

We would very much appreciate feedback on this proposal. Perhaps most 
importantly if there are things we should cover that are missing, but 
also if there are things we could skip in favor or longer discussions on 
other topics.

Stefan for the chairs

Media Cap:
==========
Day 1 - 4 hours
---------------
“Media Capture and Streams” document:

* device enumeration
	Decision:
* error handling
	Decision: Use the PeerConnection-callback model, or use the model used 
in IndexedDB, File API (return objects that represent operations, errors 
as events on the objects).
* “immediate stream” gUM
	Decision: No, backwards compatible gUM, new gUM call style.
* Identity aspects of MediaStreams
	Yes or no?
	Stream or track level binding?
	Implications?
* Resource reservation (exclusive access to devices)
	Specified in gUM or “implementor choice”?
	One stream from a source or multiple streams from a source?
	Exclusive, shared-in-tab, shared-in-browser, anything-goes?

Day 2 - 3 hours
---------------
* Settings/constraints (2h)
	Model (0.5 hours)
	What settings to have in v1 (1.5h)

* Decide next steps for doc (last call WG) (0.5h)

Recording document (0.5h):
	Approval for publication as FPWD (close call at the meeting)



WebRTC:
=======
Day 2 - 1 hour
--------------
* Call flow
	Walk through examples in spec
	Note disagreements on “what happens here”
	Note questions about “what happens here if....”
	Don’t make decisions - list questions

Day 3 - 4 hours
---------------
* MediaStream and MediaStreamTrack - SDP interface (1.5h)
	(Based on the conclusions from rtcweb/mmusic)
	What id’s/labels needs to be signaled
	How to handle rejection (support now? How?)
* Error handling (0.5h)
	Sticking to current principles
	Specific errors and additional error data
* Data channel (0.5h)
	Verify that we pass all info needed for SCTP setup, and vice versa
* Rollback (hope this is just API, and settled)
* Stats (1h)
	Stats needed, whether current are well defined
	Where should stats specs live? (IANA registry, IETF doc, W3C doc, all 
of the above?)

* Next steps, open issues list (0.5h)
Received on Tuesday, 15 January 2013 10:49:08 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:03 GMT