<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [whatwg] Give guidance about RFC 4281 codecs
parameter</title></head><body>
<div>WARNING: I have CC'd the co-authors of the RFC, as I think
they might like to see the discussion, comment on my answers, and
possibly correct me. I also have a question whether there is a
typo in the RFC...</div>
<div><br></div>
<div>* * * * *</div>
<div><br></div>
<div><br></div>
<div>Henry</div>
<div><br></div>
<div>these are all great questions. Let me see how many I can
answer.</div>
<div><br></div>
<div>Overall, the RFC was struggling with the issue that there is no
'uniform' naming of codecs; the namespace for codecs is
dependent on the container format, so products that do container
conversion have to have tables of code matches. ugh.
That's why the RFC is as it is.</div>
<div><br></div>
<div>The RFC suggests that updated information would be done with
RFCs, which is a little heavy. The RFC as written formally
applies to 3GPP files and 3GPP2 files, but the definitions are
applicable for all ISO-family files. </div>
<div><br></div>
<div>As you'll see below, 3GPP has also defined it for avc1 in
MP4-family containers, but no spec. or registration authority provides
a pointer. We might want to ask IANA whether we could add
something to the MIME registry.</div>
<div><br></div>
<div><br></div>
<div>At 11:37 +0300 8/04/07, Henri Sivonen wrote:</div>
<blockquote type="cite" cite><br>
* Theora video and Vorbis audio in Ogg container.
(application/ogg; .ogg)<br>
* Dirac video and Vorbis audio in Ogg container.
(application/ogg; .ogg)<br>
* Theora video and Vorbis audio in Matroska container.
(video/x-matroska; .mkv)<br>
* Dirac video and Vorbis audio in Matroska container.
(video/x-matroska; .mkv)</blockquote>
<div><br></div>
<div>My understanding is that the Ogg container is 'specific' to these
codecs, and therefore the codecs parameter is not needed. But I
am not an Ogg or Matroska expert; perhaps they could chime
in?</div>
<div><br></div>
<div>We did have the discussion over profiles of these codecs; I
understand profiles are not used, but I am still unclear as to which
of the following is true:</div>
<div>a) features are never added to the bitstreams, so any release of
the decoder will decode bitstreams made by any release of the encoder
(modulo bugs);</div>
<div>b) the decoder release needed is signalled somehow in the
bitstream ('need at least the April 2005 release or later to decode
this file')</div>
<div>c) neither of the above are true, it's left to the users to stay
up to date, and if they don't, then, well, that's their problem.</div>
<div><br></div>
<div>If there are profiles, release versions etc. signalled, then a
parameter might be appropriate, and if the container formats are
general, a codecs parameter might be appropriate.</div>
<div><br></div>
<blockquote type="cite" cite> * H.264 Baseline profile video and
Low-Complexity AAC audio in MP4 container. (video/mp4;
.mp4)</blockquote>
<div><br></div>
<div>The AAC is covered by the RFC; the example is there -
mp4a.40.2.</div>
<div><br></div>
<div>H.264 was recently covered by 3GPP. See 26.244 V7.1.0
section A.2.2, available from www.3gpp.org.</div>
<div><br></div>
<div><font face="Times New Roman" size="+1" color="#000000">When the
first element of a value is 'avc1', indicating H.264 (AVC) video [29],
the second element is the hexadecimal representation of the following
three bytes in the sequence parameter set NAL unit specified in [29]:
1) profile_idc, 2) a byte composed of the values of
constraint_set0_flag, constraint_set1_flag, constraint_set2_flag,
constraint_set3_flag, and reserved_zero_4bits in bit-significance
order, starting from the most significant bit, and 3) level_idc. Note
that reserved_zero_4bits is required to be equal to 0 in [29], but
other values for it may be specified in the future by ITU-T or
ISO/IEC.</font></div>
<div><br></div>
<div>You don't give me a level number, so I put xx for those hex
digits below.</div>
<div><br></div>
<div>Assuming we're simple baseline, and also main and extended
compatible</div>
<div>avc1.42E0xx</div>
<div><br></div>
<div><br></div>
<blockquote type="cite" cite> * H.264 Extended profile video and
Low-Complexity AAC audio in MP4 container. (video/mp4;
.mp4</blockquote>
<div><br>
Extended profile has the value (decimal) 88, and typically Extended
profile streams would be marked as Baseline compatible, at
least. Here is an example for this AVC</div>
<div><br></div>
<div>avc1.58A0xx</div>
<div><br>
<br>
</div>
<blockquote type="cite" cite> * H.264 Main profile video and
Low-Complexity AAC audio in MP4 container. (video/mp4;
.mp4)</blockquote>
<div><br>
Main profile is decimal 77, so something like</div>
<div>avc1.4D40xx<br>
</div>
<blockquote type="cite" cite> * H.264 High profile video and
Low-Complexity AAC audio in MP4 container. (video/mp4;
.mp4)</blockquote>
<div><br></div>
<div>There are a number of high profiles, confusingly, though there is
one called 'high', with value decimal 100.</div>
<div>avc1.6400xx</div>
<div><br></div>
<div>if it's not compatible with main, baseline, or extended
profiles.</div>
<div><br></div>
<blockquote type="cite" cite> * MPEG-4 Simple Profile profile
video and Low-Complexity AAC audio in MP4 container. (video/mp4;
.mp4)</blockquote>
<div><br></div>
<div>Covered by the RFC:</div>
<div><br></div>
<div>For example, MPEG-4 Visual Simple Profile Level 0 has the value
9,<br>
so a complete string for MPEG-4 Visual Simple Profile
Level 0 would<br>
be "mp4v.20.9".</div>
<div><br></div>
<div>Though when checking the next answer, I read in the spec. that we
may have a typo here, it might be 8. Ooops, if so.</div>
<div><br></div>
<div><font face="Helvetica" size="+1" color="#000000">Simple
Profile/Level 0<x-tab> </x-tab>00001000<br>
Reserved<x-tab>
</x-tab><x-tab>
</x-tab><x-tab>
</x-tab>00001001 - 00001111</font><br>
<font face="Helvetica" size="+1" color="#000000"></font></div>
<div><br></div>
<blockquote type="cite" cite> * MPEG-4 Advanced Simple Profile
profile video and Low-Complexity AAC audio in MP4 container.
(video/mp4; .mp4)</blockquote>
<div><br>
<font face="Helvetica" size="+1" color="#000000">Advanced Simple
Profile/Level 0<x-tab>
</x-tab>11110000</font></div>
<div><br></div>
<div>so, mp4v.20.240<br>
</div>
<blockquote type="cite" cite> * MPEG-4 Simple Profile profile
video and AMR audio in 3GPP container. (video/3gpp; .3gp)</blockquote>
<div><br></div>
<div>Video we've covered. AMR is in 26.244,</div>
<div><br></div>
<div>samr</div>
<div><br></div>
<div><br></div>
<blockquote type="cite" cite> * WMV9 video and WMA 2 audio in ASF
container. (video/x-ms-wmv; .wmv)<br>
* WMV8 video and WMA 2 audio in ASF container. (video/x-ms-wmv;
.wmv)</blockquote>
<div><br></div>
<div>These would be up to Microsoft to define, I assume. I am
not aware of a definition.</div>
<div><br></div>
<blockquote type="cite" cite> * VC-1 video and WMA 10 Pro audio
in ASF container. (video/x-ms-wmv; .wmv)</blockquote>
<div><br></div>
<div>VC-1 is standardized by SMPTE, but again this container format is
Microsoft's.</div>
<div><br></div>
<blockquote type="cite" cite> * Real Video 10 video and
High-Efficiency AAC audio in Real Media container.
(application/vnd.rn-realmedia; rm)</blockquote>
<div><br>
We'd have to ask Real, but I don't think it is defined.<br>
</div>
<blockquote type="cite" cite> * XviD video and MP3 audio in AVI
container. (video/x-msvideo; .avi)<br>
* Motion-JPEG video and uncompressed PCM audio in AVI container.
(video/x-msvideo; .avi)</blockquote>
<div><br></div>
<div>AVI I *think* is owned by Microsoft, and I *think* they deprecate
it; it's up to the owner to define. Again, I am not aware
of a definition, but the 4CC style from MP4 might be
appropriate.</div>
<div><br></div>
<blockquote type="cite" cite> * MPEG-1 video and MPEG-1 Audio
Layer II audio in MPEG-1 program stream (video/mpeg;
.mpg)</blockquote>
<div><br></div>
<div>MPEG has not defined the codecs parameter for these 'file'
(stream) formats, as far as I know.</div>
<div><br></div>
<blockquote type="cite" cite><br>
(That's a lot of cases and, yet, none are contrived.)<br>
</blockquote>
<blockquote type="cite" cite>I tried to figure this out on my own with
RFC 4281 and concluded that this is not something that authors or even
browser implementors are likely to get right without an expert-created
lookup table. I see that at least of the RFC authors reads this
mailing list. :-)</blockquote>
<div><br></div>
<x-sigsep><pre>--
</pre></x-sigsep>
<div>David Singer<br>
Apple Computer/QuickTime</div>
</body>
</html>