[rtcweb] VP8 and parameters (Re: Signalling, SDP, and the way we think about interconnecting RTCWEB applications)

Harald Alvestrand <harald@alvestrand.no> Sat, 15 October 2011 20:15 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 093A121F8520 for <rtcweb@ietfa.amsl.com>; Sat, 15 Oct 2011 13:15:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id SBtFbGziDVBa for <rtcweb@ietfa.amsl.com>; Sat, 15 Oct 2011 13:15:20 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no []) by ietfa.amsl.com (Postfix) with ESMTP id EC28421F848A for <rtcweb@ietf.org>; Sat, 15 Oct 2011 13:15:19 -0700 (PDT)
Received: from localhost (localhost []) by eikenes.alvestrand.no (Postfix) with ESMTP id 2233439E0CD; Sat, 15 Oct 2011 22:15:18 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([]) by localhost (eikenes.alvestrand.no []) (amavisd-new, port 10024) with ESMTP id wEhdOIJd6t8A; Sat, 15 Oct 2011 22:15:17 +0200 (CEST)
Received: from [] (c213-89-141-213.bredband.comhem.se []) by eikenes.alvestrand.no (Postfix) with ESMTPS id 3756F39E0BF; Sat, 15 Oct 2011 22:15:17 +0200 (CEST)
Message-ID: <4E99E9D4.5020400@alvestrand.no>
Date: Sat, 15 Oct 2011 22:15:16 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110922 Thunderbird/3.1.15
MIME-Version: 1.0
To: Stephan Wenger <stewe@stewe.org>
References: <CABF2090.323F1%stewe@stewe.org>
In-Reply-To: <CABF2090.323F1%stewe@stewe.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org
Subject: [rtcweb] VP8 and parameters (Re: Signalling, SDP, and the way we think about interconnecting RTCWEB applications)
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: Sat, 15 Oct 2011 20:15:21 -0000

On 10/15/2011 05:42 PM, Stephan Wenger wrote:
> Hi Harald,
> On 10.15.2011 07:29 , "Harald Alvestrand"<harald@alvestrand.no>  wrote:
>> Given the last point - the app *cannot* "implicitly" what codec will be
>> used. And given that it doesn't know the codec, it can't know the
>> parameters either.
>> (that said... I'm all in favour of fewer parameters. The RTP format for
>> VP8 that we're in the process of finishing has zero parameters. I hope
>> it will remain that way.)
> I would be surprised if that were the case.  As the very minimum, I would
> suspect that you need some form of upper bound for computational decoder
> complexity (measured in pixel numbers per second, framerate/picture size
> combination, or whatever).  It doest make sense that two systems agree on
> VP8, and the receiver cannot rdecode the sender's bitstream because the
> receiver is a cheap cellphone and the sender is a desktop PC which likes
> to send 1080p.  Let me also note that the VP8 payload spec (at least the
> current public version) has a number of "optional" mechanisms, which you
> would want to negotiate, no?
(changing the subject again)
This is a discussion more relevant for the payload wg....

As far as I understand the current spec, the features are optional in 
the sense that the sender can choose to use them or not; the recipient 
has to be able to decode the stream, no matter what features are used.

We've got generic features in SDP to negotiate bitrate, resolution and 
some other parameters in a codec-independent fashion, and the RTP/AVPF 
profile has things like TMMBR to tamp down the sending rate even more; 
we'll see if those prove adequate to protect low-powered recipients from 
high-powered senders.

If not, I guess the specs will have to grow.