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

Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> Fri, 05 April 2013 00:13 UTC

Return-Path: <sergio.garcia.murillo@gmail.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 B89C821F87D3 for <rtcweb@ietfa.amsl.com>; Thu, 4 Apr 2013 17:13:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.716
X-Spam-Level:
X-Spam-Status: No, score=-0.716 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.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 9nJw7pZALTxT for <rtcweb@ietfa.amsl.com>; Thu, 4 Apr 2013 17:13:42 -0700 (PDT)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id ABA4921F86DC for <rtcweb@ietf.org>; Thu, 4 Apr 2013 17:13:41 -0700 (PDT)
Received: by mail-wi0-f181.google.com with SMTP id hj8so88512wib.2 for <rtcweb@ietf.org>; Thu, 04 Apr 2013 17:13:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type; bh=TvX52Ctvj8kx6K+W8n0SEzvGifQIcKJ6ovlj2o0UkGY=; b=U25sUdziIPdjDWNTsJmfgcJwRG7PIAcvmf+yIj9a+LpWui52V28VDaUym9JjowENnT a1cQ5HegG7N0cweU5zlZboCwacdHNyvz7Rvxa7XBJD1byQeBza6pYtgiYrvdo3/a5Aky 8EYZoIGegQyL3jHl49Cvh2eBawD+XfLGTNhDHxJUR92fPDEQrtOOKMeWnpw9CRj5mN1Y PJDhT7HppP1BdL0niGh1ANXj04AeNDdFiWAgGJEzbe2hne4fRjU9/FAWhGBeQcus0OIt 7UngHMYbrCB6V+ZBb+K3QvHb1heuwCDz31b9iKnM/yQ+y4bgZKrKLTLpt+/186U7WO3Z ggBw==
X-Received: by 10.194.57.137 with SMTP id i9mr12438452wjq.18.1365120820188; Thu, 04 Apr 2013 17:13:40 -0700 (PDT)
Received: from [192.168.1.2] (215.pool80-103-132.dynamic.orange.es. [80.103.132.215]) by mx.google.com with ESMTPS id s2sm708788wib.4.2013.04.04.17.13.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Apr 2013 17:13:39 -0700 (PDT)
Message-ID: <515E1734.90702@gmail.com>
Date: Fri, 05 Apr 2013 02:13:40 +0200
From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
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>
In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D90F69B243@xmb-rcd-x14.cisco.com>
Content-Type: multipart/alternative; boundary="------------090403080701020205040709"
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 00:13:43 -0000

El 05/04/2013 1:28, Mo Zanaty (mzanaty) escribió:
>
> Realtime/low latency and constrained bitrate are obviously important 
> for the actual implementation used. Thomas was pointing out that these 
> factors have nothing to do with the codec technology itself, since 
> they are purely encoder implementation optimizations. There is nothing 
> in the VP8 or H.264 standard that uniquely provides realtime/low 
> latency or constrained bitrate. Those are attributes of encoder 
> implementations which are not part of the standard.
>
> So the question was whether we care about evaluating codec technology 
> or specific implementations. If the former, then tests should be 
> staged in the same way codec experts evaluate codec technology/tools. 
> If the latter, then tests should be staged using the target 
> implementations.
>
> I'm not aware of conferencing applications which use x264, because it 
> was designed and optimized for transcoding (dvd rips to blu-ray) not 
> conferencing. Most importantly, x264 cbr mode is inappropriate for 
> conferencing since it is for broadcast MPEG transport streams that 
> must be absolutely CBR to avoid M2TS-mux overflow or underflow, and it 
> will actually insert filler data instead of real frame data to hit the 
> CBR rate exactly. Looking at the results which show the worst H.264 
> bitrate (62% above VP8) in gipsrecstat_1280_720_50_1485kbps.mkv, there 
> is almost as much filler data as real frame data, meaning the true 
> bitrate of real frame data is almost half what is reported in the 
> results. (See attached if it makes it through.)
>

I have been using x264 with very good results in my mcu implementation, 
the parameters I use are:

     params.rc.i_rc_method           = X264_RC_ABR;
     params.rc.i_bitrate                   = bitrate;
     params.rc.i_vbv_max_bitrate = bitrate;
     params.rc.i_vbv_buffer_size   = bitrate/fps;
     params.rc.f_vbv_buffer_init    = 0;
     params.rc.f_rate_tolerance    = 0.1;
     params.b_intra_refresh           = 1;

I have a smooth and constant bitrate near the target bitrate, which is 
something I still have not been able to do with VP8 encoder yet (if 
someone nows the trick, it will be very welcome!).

Best regards
Sergio