[x264-devel] Google detailed test results for VP8 to H.264 comparisions

[Sergio Garcia Murillo]

El 13/03/2013 18:02, Jason Garrett-Glaser escribió:
> On Wed, Mar 13, 2013 at 3:39 AM, Sergio Garcia Murillo
> <sergio.garcia.murillo at gmail.com> wrote:
>>        --profile baseline
> Do you seriously expect Google to be honest here?  I'm only surprised
> that they made cheating so obvious (e.g. outright selecting
> non-default options that make x264 40-50% worse).
>

Obviously, I didn't expect it. That's why I posted it here ;)

I believe it would be good to fine tune the x264 parameters and provide 
the real results for x264. On the other hand, to be also fair with 
google, the comparation has been raised on the context of WebRTC, and 
the supporters of h264 as mandatory codec set the minimum profile to to 
baseline:

http://tools.ietf.org/id/draft-burman-rtcweb-h264-proposal-01.html

H.264/AVC 
<http://tools.ietf.org/id/draft-burman-rtcweb-h264-proposal-01.html#H264>[H264]has 
a large number of encoding tools, grouped in functionally reasonable 
toolsets by codec profiles, and a wide range of possible implementation 
capability and complexity, specified by codec levels. It is typically 
not reasonable for H.264 encoders and decoders to implement maximum 
complexity capability for all of the available tools. Thus, any H.264 
decoder implementation is typically not able to receive all possible 
H.264 streams. Which streams can be received is described by what 
profile and level the decoder conforms to. Any video stream produced by 
an H.264 encoder must keep within the limits defined by the intended 
receiving decoder's profile and level to ensure that the video stream 
can be correctly decoded.

Profiles can be "ranked" in terms of the amount of tools included, such 
that some profiles with few tools are "lower" than profiles with more 
tools. However, profiles are typically not strictly supersets or subsets 
of each other in terms of which tools are used, so a strict ranking 
cannot be defined. It is also in some cases possible to express 
compliance to the common subset of tools between two different profiles. 
This is fairly well described in[RFC6184] 
<http://tools.ietf.org/id/draft-burman-rtcweb-h264-proposal-01.html#RFC6184>.

When choosing a Mandatory To Implement codec, it is desirable to use a 
profile and level that is as widely supported as possible. Therefore, 
H.264 Constrained Baseline Profile Level 1.2 MUST be supported as 
Mandatory To Implement video codec. This is possible to support with 
significant margin inhardware devices 
<http://tools.ietf.org/id/draft-burman-rtcweb-h264-proposal-01.html#sec-implementations>[sec-implementations]and 
should likely also not cause performance problems for software-only 
implementations. All Level definitions (Annex A of[H264] 
<http://tools.ietf.org/id/draft-burman-rtcweb-h264-proposal-01.html#H264>) 
include a maximum framesize in macroblocks (16*16 pixels) as well as a 
maximum processing requirement in macroblocks per second. That number of 
macroblocks per second can be almost freely distributed between 
framesize and framerate. The maximum framesize for Level 1.2 corresponds 
to 352*288 pixels (CIF). Examples of allowed framesize and framerate 
combinations for Level 1.2 are CIF (352*288 pixels) at 15 Hz, QVGA 
(320*240 pixels) at 20 Hz, and QCIF (176*144 pixels) at 60 Hz.

Recognizing that while the above profile and level will likely be 
possible to implement in any device, it is also likely not sufficient 
for applications that require higher quality. Therefore, it is 
RECOMMENDED that devices and implementations that can meet the 
additional requirements also implement at least H.264 Constrained High 
Profile Level 1.3, extended to support 720p resolution at 30 Hz 
framerate, but the extension MAY alternatively be made from any Level 
higher than 1.3.

Note that the lowest non-extended Level that support 720p30 is Level 
3.1, but fully supporting Level 3.1 also requires fairly high bitrate, 
large buffers, and other encoding parameters included in that Level 
definition that are likely not reasonable for the targeted communication 
scenario. This method ofextending a lower level in SDP 
<http://tools.ietf.org/id/draft-burman-rtcweb-h264-proposal-01.html#sec-negotiation>[sec-negotiation]with 
a smaller set of applicable parameters is fully in line with[RFC6184] 
<http://tools.ietf.org/id/draft-burman-rtcweb-h264-proposal-01.html#RFC6184>, 
and is already used by some video conferencing vendors.

When considering the main WebRTC use case, real-time communication, the 
lack of need to support interlaced image format in that context, the 
limited use of and added delay from bi-directionally predicted (B) 
pictures, and the added implementation and computation complexity that 
comes with interlace and B-picture handling suggests that Constrained 
High Profile should be preferred over High Profile as optional codec. 
Note also that while Constrained High Profile is currently less 
supported in devices than High Profile, any High Profile decoder will be 
capable of decoding a Constrained High Profile bitstream since it is a 
subset of High Profile. To make a High Profile encoder support 
Constrained High Profile encoding, it will have to turn off interlace 
encoding and turn off the use of bi-directional prediction.


Best regards
Sergio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20130313/6696b71e/attachment-0001.html>