RE: Media Capture TF Goals

>From: Harald Alvestrand [mailto:harald@alvestrand.no]
>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.

As a representative of a potential browser implementation, I like this goal. :)

>> 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>).

Indeed. Poor choice of words on my part. My intent was to say that the work
we do here should complement and enhance the WebRTC spec, not attempt to re-write
it.

>The WebRTC requirements are in
>draft-ietf-rtcweb-use-cases-and-requirements, a joint IETF/W3C deliverable.

Full URL http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/?include_text=1
Correct?

>> 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.

At least as far as previewing a local stream, I believe that feeding media
streams into <video> etc. are directly related to capture scenarios.

Received on Tuesday, 6 December 2011 20:18:42 UTC