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

Re: revised recording proposal

From: Harald Alvestrand <harald@alvestrand.no>
Date: Fri, 30 Nov 2012 20:16:51 +0100
Message-ID: <50B90623.2000308@alvestrand.no>
To: public-media-capture@w3.org
On 11/29/2012 10:05 PM, Mandyam, Giridhar wrote:
> Please point out the requirements in http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html that state that media processing be built into the recording function.
RM13.
>
> -----Original Message-----
> From: Timothy B. Terriberry [mailto:tterriberry@mozilla.com]
> Sent: Thursday, November 29, 2012 1:03 PM
> To: public-media-capture@w3.org
> Subject: Re: revised recording proposal
>
> Mandyam, Giridhar wrote:
>> I am sorry - I don't believe a recording API should be used to enable
>   > real-time processing.  I certainly do not think it should be used for any
>
> Well, this is the use case that Jim, Milan, and probably others are actually interested in (myself included), so I believe you may be in the minority in your belief. The current proposal suggests that both this use case and the file-at-once use case have a lot in common, and we'd be foolish not to take advantage of that.
>
>   > audio stream processing for ASR.  This is what WebAudio is for, and we should  > work with the Audio WG if their current specification is unsuitable for what  > you believe is required for speech recognition.  But we have a call next week  > - maybe we can discuss this further during that time.
>
> Encoding/decoding of audio belongs at the end-points of any processing graph, i.e., in MediaStreams, which are the domain of _this_ Task Force.
> To say nothing of the fact that a solution that only works for audio is pretty poor. But you can go venue shopping if you want. Let us know how that works out for you.
>
>
Received on Friday, 30 November 2012 19:17:21 UTC

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