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
- [rtcweb] New VP8 vs H.264 tests uploaded Adrian Grange
- Re: [rtcweb] New VP8 vs H.264 tests uploaded Sergio Garcia Murillo
- Re: [rtcweb] New VP8 vs H.264 tests uploaded Harald Alvestrand
- Re: [rtcweb] New VP8 vs H.264 tests uploaded Luca De Cicco
- Re: [rtcweb] New VP8 vs H.264 tests uploaded Harald Alvestrand
- Re: [rtcweb] New VP8 vs H.264 tests uploaded Luca De Cicco
- Re: [rtcweb] New VP8 vs H.264 tests uploaded Thomas Davies
- Re: [rtcweb] New VP8 vs H.264 tests uploaded Matthew Kaufman
- Re: [rtcweb] New VP8 vs H.264 tests uploaded Adam Roach
- [rtcweb] Fundamental asymmetry [was Re: New VP8 v… Marc Petit-Huguenin
- Re: [rtcweb] New VP8 vs H.264 tests uploaded Leon Geyser
- Re: [rtcweb] New VP8 vs H.264 tests uploaded (UNC… Roy, Radhika R CIV USARMY (US)
- Re: [rtcweb] New VP8 vs H.264 tests uploaded (UNC… Thomas Davies (thdavies)
- Re: [rtcweb] New VP8 vs H.264 tests uploaded (UNC… Harald Alvestrand
- Re: [rtcweb] New VP8 vs H.264 tests uploaded Harald Alvestrand
- Re: [rtcweb] New VP8 vs H.264 tests uploaded Mo Zanaty (mzanaty)
- Re: [rtcweb] New VP8 vs H.264 tests uploaded Mo Zanaty (mzanaty)
- Re: [rtcweb] New VP8 vs H.264 tests uploaded Sergio Garcia Murillo
- Re: [rtcweb] New VP8 vs H.264 tests uploaded Harald Alvestrand
- Re: [rtcweb] New VP8 vs H.264 tests uploaded (UNC… Roy, Radhika R CIV USARMY (US)
- Re: [rtcweb] New VP8 vs H.264 tests uploaded Kieran Kunhya
- Re: [rtcweb] New VP8 vs H.264 tests uploaded Mo Zanaty (mzanaty)
- Re: [rtcweb] New VP8 vs H.264 tests uploaded Kieran Kunhya
- Re: [rtcweb] New VP8 vs H.264 tests uploaded Randell Jesup
- Re: [rtcweb] New VP8 vs H.264 tests uploaded Leon Geyser