Re: [rtcweb] Tim Panton's choices

Maik Merten <maikmerten@googlemail.com> Sat, 28 December 2013 17:20 UTC

Return-Path: <maikmerten@googlemail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3EF1AFE26 for <rtcweb@ietfa.amsl.com>; Sat, 28 Dec 2013 09:20:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8oebrHhaTU1 for <rtcweb@ietfa.amsl.com>; Sat, 28 Dec 2013 09:20:08 -0800 (PST)
Received: from mail-ee0-x22b.google.com (mail-ee0-x22b.google.com [IPv6:2a00:1450:4013:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id F3B6E1AFE28 for <rtcweb@ietf.org>; Sat, 28 Dec 2013 09:20:07 -0800 (PST)
Received: by mail-ee0-f43.google.com with SMTP id c13so4420192eek.16 for <rtcweb@ietf.org>; Sat, 28 Dec 2013 09:20:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=plJJEDAIbM9dyhJFGTwhi+eRJ1EcMYoO8VyGS1wy5kA=; b=davc7DKcmTB3hovM4/4oHRW4FMRii9lzQ35FGa3ijEelXTxsq7qrJc0B/Q7x+zj6t3 Cem7i9thUG2yaB523VEz1R8N1yOgQjaElUKTRzQkeMbMP/MMj17Albl1djrMNAKFLUCH TmSjM120lKjPNrcZsCWpXPgDthMjmpCiAA96Dd6c5Bjov9dob5tH0DBRFlJyZ4ljt1GM km0d7Mh0OA4b52Ckcs2AeN+laNdHKRKDO6pKwl8O8APfmejPaKP0/BHxBGK028GJdf32 bqKGSiz+5rRICH8Ub0tL3lRnrCPyrcBC1conSnU0IlOgiwzWYVSPcl39hI3iExbPUdEC Xd7Q==
X-Received: by 10.14.172.130 with SMTP id t2mr3145399eel.68.1388251200306; Sat, 28 Dec 2013 09:20:00 -0800 (PST)
Received: from [192.168.2.109] (port-92-201-32-146.dynamic.qsc.de. [92.201.32.146]) by mx.google.com with ESMTPSA id h48sm92283209eev.3.2013.12.28.09.19.58 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 28 Dec 2013 09:19:59 -0800 (PST)
Message-ID: <52BF083C.7050308@googlemail.com>
Date: Sat, 28 Dec 2013 18:19:56 +0100
From: Maik Merten <maikmerten@googlemail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CA+9kkMBSpDLJBBbPxgyMUi+bi3aw3D8zpSXcAvQ4koi115QqBg@mail.gmail.com> <67AD498F-4E6D-48FD-9067-B4491BE3FC16@phonefromhere.com>
In-Reply-To: <67AD498F-4E6D-48FD-9067-B4491BE3FC16@phonefromhere.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Tim Panton's choices
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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, 28 Dec 2013 17:20:11 -0000

Am 28.12.2013 17:08, schrieb Tim Panton:
>  6.
>     All entities MUST support H.261
>      1.
>         Are you in favor of this option [Yes/No/Acceptable]:No
>      2.
>         Do you have any objections to this option, if so please
>         summarize them:
>         The codec will be unacceptable for a large number of (mobile)
>         use cases requiring dynamic bandwidth adjustment.
>

Can you elaborate on that argument, which you also apply to H.263 and 
Theora?

H.261/H.263/Theora have no fixed increments regarding bitrate and any 
encoder can scale bandwidth basically at will. IMO bandwidth management 
is completely within the encoder realm, and implementations can choose 
to accept new bitrate targets at runtime.

Is there a specific technology you have in mind regarding the term 
"dynmaic bandwidth adjustment"?


> 10.
>     All entities MUST implement at least two of {VP8, H.264, H.261}
>      1.
>         Are you in favor of this option [Yes/No/Acceptable]:No
>      2.
>         Do you have any objections to this option, if so please
>         summarize them:
>         Along with the objections to 5) and 6) This also brings added
>         complexity in implementation,
>         api, user interface and signalling - for a minimal (or zero)
>         benefit.

Apart from the complexity of having to implement two codecs, what 
additional overhead regarding api, user interface (?) and signalling do 
you refer to, given that codec negotiation will be part of establishing 
a WebRTC call anyway?

(The benefit is having no negotiation failure by ensuring non-empty 
codec intersections)

Best regards,

Maik