Re: [rtcweb] New VP8 vs H.264 tests uploaded

Randell Jesup <randell-ietf@jesup.org> Fri, 05 April 2013 17:44 UTC

Return-Path: <randell-ietf@jesup.org>
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 4350021F9797 for <rtcweb@ietfa.amsl.com>; Fri, 5 Apr 2013 10:44:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.294
X-Spam-Level:
X-Spam-Status: No, score=-1.294 tagged_above=-999 required=5 tests=[AWL=-0.655, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96]
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 uzhYm4wXebiy for <rtcweb@ietfa.amsl.com>; Fri, 5 Apr 2013 10:44:51 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id D30EE21F8BE9 for <rtcweb@ietf.org>; Fri, 5 Apr 2013 10:44:51 -0700 (PDT)
Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:4642 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from <randell-ietf@jesup.org>) id 1UOAh1-000FjH-05 for rtcweb@ietf.org; Fri, 05 Apr 2013 12:44:51 -0500
Message-ID: <515F0D29.9030805@jesup.org>
Date: Fri, 05 Apr 2013 13:43:05 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CAPVCLWbajJNS-DbXS-AJjakwovBKhhpXAmBaR_LYKjCyk7UnYg@mail.gmail.com> <515D3FA1.6050305@gmail.com> <515D96A2.1000602@cisco.com> <CAGgHUiRLAmGz7H5iY_cpiiKPPN6JXo1jc2-U7TZLe6k-qETo9Q@mail.gmail.com> <3879D71E758A7E4AA99A35DD8D41D3D90F69B243@xmb-rcd-x14.cisco.com> <515E1734.90702@gmail.com> <3879D71E758A7E4AA99A35DD8D41D3D90F69B5D3@xmb-rcd-x14.cisco.com>
In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D90F69B5D3@xmb-rcd-x14.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
Subject: Re: [rtcweb] New VP8 vs H.264 tests uploaded
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: Fri, 05 Apr 2013 17:44:52 -0000

On 4/5/2013 12:24 PM, Mo Zanaty (mzanaty) wrote:
>
> Check your output x264 streams for fillers. If you see fillers (NAL 
> unit type 12), you are wasting bandwidth. In the example below, almost 
> half the bitrate was wasted on fillers and other stuff (SEI) that are 
> not real frames. Over RTP, you would waste even more than half the 
> link bandwidth since the small SEIs would incur the full overhead of 
> separate RTP packets. (40 bytes of RTP/UDP/IP overhead for 10 bytes of 
> SEI.)
>

Plus SRTP authentication tag (default is 10 bytes)

These are better tests than the ones presented at IETF86, though they 
aren't perfect either of course.

So I'll note that while there may be differences (in favor of either) or 
specific implementation weaknesses (solvable), I don't think there's a 
case for saying either H.264 or VP8 are technically insufficient to be 
an MTI, and either would do to avoid negotiation failure technically.  I 
do consider h.261 to be insufficient, as both the quality level/bitrate 
and the constrained resolutions would make it unacceptable to use even 
if it avoided negotiation failure. These opinions were echoed by 
multiple people in the room (and at previous IETFs).

I think the questions on MTI all come down to non-technical issues.

-- 
Randell Jesup
randell-ietf@jesup.org