W3C home > Mailing lists > Public > public-media-capture@w3.org > August 2012

RE: A sketch of a V1 of the media capture API specifciation

From: Travis Leithead <travis.leithead@microsoft.com>
Date: Tue, 21 Aug 2012 16:25:53 +0000
To: Harald Alvestrand <harald@alvestrand.no>, "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <9768D477C67135458BF978A45BCF9B383842267E@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com>
> From: Harald Alvestrand [mailto:harald@alvestrand.no]
> 
> Based on what we have so far in the spec, our current implementers'
> choices, arguments on the list, and the needs we percieve as minimal, here's
> a sketch of a proposal for the question of "what's in V1 of the spec" - the
> stuff that we aim towards with our current milestones.
> 
> This implies a V2, which means that we need to define milestones for when
> we want that done.

This could be problematic. Many of the V2 features noted in the "out" section below, could have designs that necessitate changes to V1. I would suggest that we at least have a good sketch of what the V2 features will look like so that we can have confidence in locking down the definition of some of the V1 concepts.

I raise this point because I'm not sure we're really locked on V1 of the MediaStream definition, and I'd hate to freeze that as-is, and then need to adjust it in V2... :-)


> Out:
> 
>   * Recorder
>   * Direct assignment to media element
>   * Image capture API

It seems to me that being able to either record or take an image still should be in V1. Otherwise the only stable feature set is: "look, I can view my webcam!" (but can't record it). Of course, if WebRTC also stabilizes, than you could add "videoconferencing" to the feature set, which would be cool. However, I think it would be wise for us to attempt to include a recorder/image capture API for our own spec and scenario completeness.
Received on Tuesday, 21 August 2012 16:26:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:11 UTC