[whatwg] Give guidance about RFC 4281 codecs parameter

Dave Singer singer at apple.com
Mon Apr 9 10:15:53 PDT 2007


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...

* * * * *


Henry

these are all great questions.  Let me see how many I can answer.

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.

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.

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.


At 11:37  +0300 8/04/07, Henri Sivonen wrote:
>
>  * Theora video and Vorbis audio in Ogg container. (application/ogg; .ogg)
>  * Dirac video and Vorbis audio in Ogg container. (application/ogg; .ogg)
>  * Theora video and Vorbis audio in Matroska container. 
>(video/x-matroska; .mkv)
>  * Dirac video and Vorbis audio in Matroska container. 
>(video/x-matroska; .mkv)

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?

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:
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);
b) the decoder release needed is signalled somehow in the bitstream 
('need at least the April 2005 release or later to decode this file')
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.

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.

>  * H.264 Baseline profile video and Low-Complexity AAC audio in MP4 
>container. (video/mp4; .mp4)

The AAC is covered by the RFC;  the example is there - mp4a.40.2.

H.264 was recently covered by 3GPP.  See 26.244 V7.1.0 section A.2.2, 
available from www.3gpp.org.

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.

You don't give me a level number, so I put xx for those hex digits below.

Assuming we're simple baseline, and also main and extended compatible
avc1.42E0xx


>  * H.264 Extended profile video and Low-Complexity AAC audio in MP4 
>container. (video/mp4; .mp4

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

avc1.58A0xx


>  * H.264 Main profile video and Low-Complexity AAC audio in MP4 
>container. (video/mp4; .mp4)

Main profile is decimal 77, so something like
avc1.4D40xx

>  * H.264 High profile video and Low-Complexity AAC audio in MP4 
>container. (video/mp4; .mp4)

There are a number of high profiles, confusingly, though there is one 
called 'high', with value decimal 100.
avc1.6400xx

if it's not compatible with main, baseline, or extended profiles.

>  * MPEG-4 Simple Profile profile video and Low-Complexity AAC audio 
>in MP4 container. (video/mp4; .mp4)

Covered by the RFC:

For example, MPEG-4 Visual Simple Profile Level 0 has the value 9,
    so a complete string for MPEG-4 Visual Simple Profile Level 0 would
    be "mp4v.20.9".

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.

Simple Profile/Level 0	00001000
Reserved			00001001 - 00001111


>  * MPEG-4 Advanced Simple Profile profile video and Low-Complexity 
>AAC audio in MP4 container. (video/mp4; .mp4)

Advanced Simple  Profile/Level 0	11110000

so, mp4v.20.240

>  * MPEG-4 Simple Profile profile video and AMR audio in 3GPP 
>container. (video/3gpp; .3gp)

Video we've covered.  AMR is in 26.244,

samr


>  * WMV9 video and WMA 2 audio in ASF container. (video/x-ms-wmv; .wmv)
>  * WMV8 video and WMA 2 audio in ASF container. (video/x-ms-wmv; .wmv)

These would be up to Microsoft to define, I assume.  I am not aware 
of a definition.

>  * VC-1 video and WMA 10 Pro audio in ASF container. (video/x-ms-wmv; .wmv)

VC-1 is standardized by SMPTE, but again this container format is Microsoft's.

>  * Real Video 10 video and High-Efficiency AAC audio in Real Media 
>container. (application/vnd.rn-realmedia; rm)

We'd have to ask Real, but I don't think it is defined.

>  * XviD video and MP3 audio in AVI container. (video/x-msvideo; .avi)
>  * Motion-JPEG video and uncompressed PCM audio in AVI container. 
>(video/x-msvideo; .avi)

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.

>  * MPEG-1 video and MPEG-1 Audio Layer II audio in MPEG-1 program 
>stream (video/mpeg; .mpg)

MPEG has not defined the codecs parameter for these 'file' (stream) 
formats, as far as I know.

>
>(That's a lot of cases and, yet, none are contrived.)
>
>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. :-)

-- 
David Singer
Apple Computer/QuickTime
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20070409/527533cb/attachment.htm>


More information about the whatwg mailing list