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

RE: approaches to recording

From: Jim Barnett <Jim.Barnett@genesyslab.com>
Date: Fri, 12 Oct 2012 08:39:41 -0700
Message-ID: <E17CAD772E76C742B645BD4DC602CD8106CE0498@NAHALD.us.int.genesyslab.com>
To: "Harald Alvestrand" <harald@alvestrand.no>, <public-media-capture@w3.org>

The lack of real-time delivery is not normally an issue for speech
recognition systems, because they run many times faster than real time,
and can catch up quickly once the data is available.  So if the delays
are short enough, the user will not perceive them.  And if the delays
are longer, well... then speech recognition will take a long time.
People are used to stuff being slow on the internet, aren't they?


-          Jim


From: Harald Alvestrand [mailto:harald@alvestrand.no] 
Sent: Friday, October 12, 2012 11:35 AM
To: public-media-capture@w3.org
Subject: Re: approaches to recording


On 10/11/2012 12:50 AM, Jim Barnett wrote:

	I just want to observe that lossless streaming is what we (= the
contact center and speech industry) want for  talking to a speech
recognition system.  It would be ideal if PeerConnection supported it.
Failing that, it would be nice if the Recorder supported it,  but in a
pinch we figure that we can use the track-level API to deliver buffers
of speech data and let the JS code set up the TCP/IP connection.  


Of course lossless streaming (truly guaranteed delivery) implies
non-real-time streaming (or, more formally, having to deal with the
possibility that delivery will be delayed beyond real-time), given that
the Internet is a lossy medium.

To another thread: Yes, having the constructor for the recorder take a
MIME type parameter would imply that you set the codec to be used. I
think we all agree that the data coming out of a recording interface is

Received on Friday, 12 October 2012 15:40:50 UTC

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