RE: MediaStream Recording : record() method

I think it depends on what you consider "lossless", or at least sufficiently high quality for RT speech recognition (which was the main use case for time-slicing on the record method).

For cellular connections at least, the design goal for the medium access layer is BER of 10^(-6) to be presented to TCP.  At least in the cellular networks in my experience, that design requirement has been more than sufficient to allow for acceptable speech recognition.

I don't think HD video was ever the justification for the requirement that the record() method return time-sliced data.

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Wednesday, August 28, 2013 1:22 PM
To: public-media-capture@w3.org
Subject: Re: MediaStream Recording : record() method

On 08/28/2013 08:08 PM, Mandyam, Giridhar wrote:
There is an outstanding bug for WebRTC to have a TCP fallback:  see https://www.w3.org/Bugs/Public/show_bug.cgi?id=20818.  It has not been closed yet, so I assume that a TCP-based PC is still on the table for WebRTC.  This should be sufficient for lossless real-time data streaming in my opinion, and satisfy the speech recognition use case.

Real-time transmission of HD video over a variable-bandwidth connection is going to be lossy no matter what the transmission medium is.
With TCP, the loss is going to be packets thrown away when the sender notices that the output buffers have grown unacceptably big.



The timeframe for when we'll see TCP-based PC implementations is an unknown (at least to me).

And it won't create lossless video.