Re: Media Capture TF Goals

Travis, thanks for the input!

Some comments below..... my own goals for this TF start off with

"Make sure WEBRTC is able to deliver a spec that is useful to users, 
matches browser implementations, and is ready on the timescale that the 
browsers need it".

This means that if there turns out to be items that require (or cause) 
long drawn out discussion, and are not essential for the first round of 
WEBRTC specifications, my tendency will certainly be towards removing 
those items from the workplan of the group. At the speed this moves, it 
is better to have a workable specification at the right time than to 
have a slightly more generic specification a lot later.

Some comments below...

On 11/30/2011 07:18 PM, Travis Leithead wrote:
> Hi Harald and Stefan!
>
> Thanks for jump-starting this task force.
>
> Before we start nit-picking the recently-submitted first draft, I think it's important to set up some goals for this task force. Goals will help us all align on a common direction, and provide the measurement by which we will know when we are "done".
>
> I would like to suggest some of the goals that I have for this TF. Perhaps other members can submit theirs and we can build consensus on the goals.
>
> 1. Build a set of shared requirements derived from both the WebRTC scenarios as well as local media capture scenarios. My current perspective is slanted in the direction of local media capture scenarios (as I don't have much RTC in-depth knowledge). Both myself (Microsoft) and Rich (Opera) have action items to provide a set of scenarios to this TF.
and you are going to edit this document, so that will be MOST welcome!
> 2. Clearly split out the "media capture" scenarios from the current WebRTC spec in a way that doesn't de-stabilize the WebRTC spec's dependencies on MediaStreams. Capture these requirements in a separate spec-the final deliverable of the task force. The task force should take the best of both local capture scenarios and WebRTC streaming scenarios and build a capture API that can equally serve both.
I'm unsure of the language here - the way I make those words hang 
together, a scenario is good if you can derive a concrete requirement 
from it, which you can then hold up against a proposed API and say "this 
is satisfied" or "this is not satisfied".
We may find some requirements impossible to satisfy, and may find that 
some requirements are best satisfied by other groups' output (for 
instance, it seems that requirements for image rotation are best 
satisfied by pointing at <canvas>).

The WebRTC requirements are in 
draft-ietf-rtcweb-use-cases-and-requirements, a joint IETF/W3C deliverable.
> 3. Explore and possibly integrate and align the TF deliverable with other current W3C technologies, notably Microsoft's recent Streams API proposal [1], and the HTMLMediaElement (video tag) from HTML5 (which has a lot of similarities to WebRTC's MediaStream).
I would hesitate to promise too much alignment, or to align them in this 
task force. WEBRTC has a definite requirement for feeding media streams 
into <video>, but that doesn't seem to touch the media capture aspect at 
all. This, too, needs to be driven by requirements.
> 4. Discuss and possibly incorporate some of the feedback previously provide via the DAP working group related to media capture [2].
Once we have documented the requirements, I think this will be more easy 
to comprehend; the text at [2] didn't give me much of a sense of clear 
feedback.
> 5. Provide a clear scope of the work so that essential requirements can be met, and other future requirements can be integrated into a V2 spec in a way that doesn't require re-working the V1 API.
This seems about right.
> [1] http://dvcs.w3.org/hg/webapps/raw-file/tip/StreamAPI/Overview.htm
> [2] http://lists.w3.org/Archives/Public/public-device-apis/2011Nov/att-0177/minutes-2011-11-03.html#item05
>
>
>
>

Received on Monday, 5 December 2011 19:59:33 UTC