<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">El 13/03/2013 18:02, Jason
Garrett-Glaser escribió:<br>
</div>
<blockquote
cite="mid:CABS55+CJs46VerjMS+s+KimBqmLNKJ2TSy2jeVSXU6tzVOrMOw@mail.gmail.com"
type="cite">
<pre wrap="">On Wed, Mar 13, 2013 at 3:39 AM, Sergio Garcia Murillo
<a class="moz-txt-link-rfc2396E" href="mailto:sergio.garcia.murillo@gmail.com"><sergio.garcia.murillo@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> --profile baseline
</pre>
</blockquote>
<pre wrap="">
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).
</pre>
</blockquote>
<br>
Obviously, I didn't expect it. That's why I posted it here ;)<br>
<br>
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:<br>
<br>
<a
href="http://tools.ietf.org/id/draft-burman-rtcweb-h264-proposal-01.html">http://tools.ietf.org/id/draft-burman-rtcweb-h264-proposal-01.html</a><br>
<p style="margin-left: 2em; margin-right: 2em; color: rgb(0, 0, 0);
font-family: verdana, helvetica, arial, sans-serif; font-size:
13.194443702697754px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height: normal;
orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px;"><a
href="http://tools.ietf.org/id/draft-burman-rtcweb-h264-proposal-01.html#H264"
style="text-decoration: none;">H.264/AVC</a><span
class="Apple-converted-space"> </span><cite title="NONE"
style="font-style: normal;">[H264]</cite><span
class="Apple-converted-space"> </span>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.</p>
<p id="rfc.section.7.p.2" style="margin-left: 2em; margin-right:
2em; color: rgb(0, 0, 0); font-family: verdana, helvetica, arial,
sans-serif; font-size: 13.194443702697754px; font-style: normal;
font-variant: normal; font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align: start;
text-indent: 0px; text-transform: none; white-space: normal;
widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px;">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<span class="Apple-converted-space"> </span><a
href="http://tools.ietf.org/id/draft-burman-rtcweb-h264-proposal-01.html#RFC6184"
style="text-decoration: none;">[RFC6184]</a>.</p>
<p id="rfc.section.7.p.3" style="margin-left: 2em; margin-right:
2em; color: rgb(0, 0, 0); font-family: verdana, helvetica, arial,
sans-serif; font-size: 13.194443702697754px; font-style: normal;
font-variant: normal; font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align: start;
text-indent: 0px; text-transform: none; white-space: normal;
widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px;">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 in<span class="Apple-converted-space"> </span><a
href="http://tools.ietf.org/id/draft-burman-rtcweb-h264-proposal-01.html#sec-implementations"
style="text-decoration: none;">hardware devices</a><span
class="Apple-converted-space"> </span><cite title="NONE"
style="font-style: normal;">[sec-implementations]</cite><span
class="Apple-converted-space"> </span>and should likely also not
cause performance problems for software-only implementations. All
Level definitions (Annex A of<span class="Apple-converted-space"> </span><a
href="http://tools.ietf.org/id/draft-burman-rtcweb-h264-proposal-01.html#H264"
style="text-decoration: none;">[H264]</a>) 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.</p>
<p id="rfc.section.7.p.4" style="margin-left: 2em; margin-right:
2em; color: rgb(0, 0, 0); font-family: verdana, helvetica, arial,
sans-serif; font-size: 13.194443702697754px; font-style: normal;
font-variant: normal; font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align: start;
text-indent: 0px; text-transform: none; white-space: normal;
widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px;">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.</p>
<p id="rfc.section.7.p.5" style="margin-left: 2em; margin-right:
2em; color: rgb(0, 0, 0); font-family: verdana, helvetica, arial,
sans-serif; font-size: 13.194443702697754px; font-style: normal;
font-variant: normal; font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align: start;
text-indent: 0px; text-transform: none; white-space: normal;
widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px;">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 of<span class="Apple-converted-space"> </span><a
href="http://tools.ietf.org/id/draft-burman-rtcweb-h264-proposal-01.html#sec-negotiation"
style="text-decoration: none;">extending a lower level in SDP</a><span
class="Apple-converted-space"> </span><cite title="NONE"
style="font-style: normal;">[sec-negotiation]</cite><span
class="Apple-converted-space"> </span>with a smaller set of
applicable parameters is fully in line with<span
class="Apple-converted-space"> </span><a
href="http://tools.ietf.org/id/draft-burman-rtcweb-h264-proposal-01.html#RFC6184"
style="text-decoration: none;">[RFC6184]</a>, and is already
used by some video conferencing vendors.</p>
<p id="rfc.section.7.p.6" style="margin-left: 2em; margin-right:
2em; color: rgb(0, 0, 0); font-family: verdana, helvetica, arial,
sans-serif; font-size: 13.194443702697754px; font-style: normal;
font-variant: normal; font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align: start;
text-indent: 0px; text-transform: none; white-space: normal;
widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px;">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.<br>
</p>
<br>
Best regards<br>
Sergio<br>
</body>
</html>