Re: [rtcweb] compressed codec-free webrtc?

Matt Fredrickson <creslin@digium.com> Wed, 30 October 2013 15:09 UTC

Return-Path: <creslin@digium.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 287B811E832C for <rtcweb@ietfa.amsl.com>; Wed, 30 Oct 2013 08:09:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.676
X-Spam-Level:
X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltLGjCPaV4WV for <rtcweb@ietfa.amsl.com>; Wed, 30 Oct 2013 08:09:20 -0700 (PDT)
Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) by ietfa.amsl.com (Postfix) with ESMTP id 49F9611E8335 for <rtcweb@ietf.org>; Wed, 30 Oct 2013 08:08:52 -0700 (PDT)
Received: by mail-la0-f52.google.com with SMTP id eh20so1170097lab.25 for <rtcweb@ietf.org>; Wed, 30 Oct 2013 08:08:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uP8Fgt5+WNrxvosMzwt1/jXVUKONhJkc4qRjFcrAvMw=; b=mN69b6oTGAOHUK6sOdpT/yi4PjlXSVKNGMowvoujk0OY+iiOQzi0L0Y6yPSen1f3yu 6kxSelbZw/7Pi6/cNXBJ/KkCqOPKz14eYA8TheZlMAC4+9Vlneed+lXioYTtL6UdeG8L xjMlV8FCkyCoY7WGPeL/3o1EGSvFASHbxhxXt8WZw8ZQgJ0U7dViDU0HNbyT5CMw8LDZ E9Ve/fMf3kD5w425qKvBtqsMlre9paFUWialzzMlg4y70vYpg3Kd3FR6genEYz62SmxY kTR1euUL5he7+/DsuGuskAQFrenTmpx85hz+HcztGqMm4JooxZAy/ihU9BvewSR0XzFA kmnQ==
X-Gm-Message-State: ALoCoQmX2WvKMbjbKoyykSqV/teslsGtGAOoN841bnkTFF0L7TZQ35V/M/ndzToGMmwFhyRpzIOh
MIME-Version: 1.0
X-Received: by 10.152.45.42 with SMTP id j10mr3566302lam.15.1383145728510; Wed, 30 Oct 2013 08:08:48 -0700 (PDT)
Received: by 10.112.132.102 with HTTP; Wed, 30 Oct 2013 08:08:48 -0700 (PDT)
In-Reply-To: <CAA93jw5LxJbbt6y8W_aFHt7Sumd=taLfx21q960JvDQxvHZDpg@mail.gmail.com>
References: <CAA93jw72QwmwQ1+wqG9soa8joiuLGRiaKuYnTvkHqkQ20FQ+gg@mail.gmail.com> <52700D33.30102@nostrum.com> <CAA93jw5LxJbbt6y8W_aFHt7Sumd=taLfx21q960JvDQxvHZDpg@mail.gmail.com>
Date: Wed, 30 Oct 2013 10:08:48 -0500
Message-ID: <CAHZ_z=xOsnpp46suzg1J_T33hnoNOoZ=4ZF8N72a2W9GCsaTew@mail.gmail.com>
From: Matt Fredrickson <creslin@digium.com>
To: Dave Taht <dave.taht@gmail.com>
Content-Type: multipart/alternative; boundary="001a11c29f56d21d3904e9f6b589"
Cc: "rmcat@ietf.org" <rmcat@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] compressed codec-free webrtc?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Oct 2013 15:09:24 -0000

On Tue, Oct 29, 2013 at 3:00 PM, Dave Taht <dave.taht@gmail.com> wrote:

> On Tue, Oct 29, 2013 at 12:32 PM, Adam Roach <adam@nostrum.com> wrote:
> > On 10/29/13 13:33, Dave Taht wrote:
> >
> > In having my eyes glaze over at the codec debate I found myself
> > wondering to what extent anyone was pursuing truly low latency video
> > and audio, along the lines of what the lola project has been doing for
> > collaborative concerts.
> >
> > See:
> >
> > http://www.conts.it/artistica/lola-project
> >
> > They ship raw audio and raw video, they actually use cameras where
> > they can get at scanlines and ship that (saving 16ms)
> >
> > So I'm ignorant of what webrtc can do is there a codec selection (yuv?
> > 48 bit audio? for the rawest video and audio possible?)
> >
> >
> > In theory, what you're looking for is this:
> > http://tools.ietf.org/html/rfc4175
>
> Thank you!
>
> > However, the caveats in that document are pretty huge:
> >
> >    It is important to note that uncompressed video can have immense
> >    bandwidth requirements (up to 270 Mbps for standard-definition video,
> >    and approximately 1 Gbps for high-definition video).  This is
> >    sufficient to cause potential for denial-of-service if transmitted
> >    onto most currently available Internet paths.
> >
> >
> > Given the risk of Destroying The Internet Forever[tm] if any major
> browser
> > vendor implemented this, I don't expect you'll see much deployment any
> time
> > soon.
>
> I don't see people doing videoconferences in the same qty as we do,
> say, torrents (famous last words!). Certainly the panopticon might
> take over the internet (but in that case delays from encoding should
> be acceptable to our new robotic panoptic overloads, it's just the
> pesky humans that have trouble with latency)
>
> So, maybe running at rates like this would trouble the "Internet" a
> bit now, but on internal networks, not so much.
>
> 270Mbits is a trivial amount of bandwidth for a modern switched
> network. Homes and businesses that are wired are probably close to
> universally switched GigE, so internal conversations could possibly
> run at max speed and minimal latency.
>
> Internet-wise, Gfiber delivers GigE, upcoming docsis standards go well
> above 200Mbit, 802.11ac goes past a gig, 802.11ad goes to 7gig.
>
> Removing a serious delay-inducing-encoding step makes things like echo
> cancellation unneeded, and live lola-like-collaboration possible.
>

Echo cancellation will probably still be needed.  Audio as exposed to
userspace in the operating system is usually not low enough latency to
remove the need to do echo cancellation.  Packetization also induces delays
in the audio/video stack the necessitate echo cancellation.

Matthew Fredrickson