Re: MediaStream Recording : record() method

On 08/28/2013 10:28 PM, Mandyam, Giridhar wrote:
>
> 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.
>

This was also one of the most stupid design decisions ever made in the 
design of cellular networks; it is the cause of 10-second packet delays 
when you walk behind a tree.

Buffering in the MAC layer is a VERY bad design.
But we live with what we have.

> 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.
>