- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Fri, 30 Nov 2012 20:16:51 +0100
- 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