[whatwg] Give guidance about RFC 4281 codecs parameter

[Silvia Pfeiffer]

Hi Charles, Dave,

On 4/10/07, Charles Iliya Krempeaux <supercanadian at gmail.com> wrote:
> Hello,
>
> On 4/9/07, Dave Singer <singer at apple.com> 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?
>
> No.  The containers are independent of the codecs put inside.
>
> However, whether software, that supports Ogg or Matroska containers will
> actually be able to "play" other codecs is another issue altogether.

Yes, the codecs are independent of the containers.

Xiph is using multiple MIME types to deal with this situation.

* application/ogg (http://www.rfc-archive.org/getrfc.php?rfc=3534)
provides for the container format, basically with any codecs included:
this could e.g. be Theora/Vorbis inside Ogg or Dirac/Vorbis inside
Ogg, but is not restricted to this.

 Xiph has defined a Skeleton track for Ogg files through which the
MIME type of the contained codecs is specified at a known location in
the header of the Ogg file. Thus, a Ogg Theora/Vorbis File with a
skeleton track will have a MIME type of application/ogg and contain
two tracks with video/x-theora and audio/x-vorbis as the MIME types.
Xiph encourages everyone to use the Skeleton track in all future
created Ogg files. Skeleton is built into a standard Ogg container
format (as defined in RFC 3533
http://www.rfc-archive.org/getrfc.php?rfc=3533) and thus Ogg files
with Skeleton are compatible with Ogg files without Skeleton.

* audio/x-vorbis is used to specify the vorbis codec. This is of
particular importance in rtp/rtsp streaming applications.

* video/x-theora is particularly used to specify the theora codec.


The community has also been seen to use these specifications:
# audio/x-vorbis+ogg  for Ogg Vorbis files
# video/x-theora+ogg for Ogg Theora/Vorbis files
though Xiph is not supportive of these.


Recent discussion at Xiph around http://www.ietf.org/rfc/rfc4281
suggests the use of the following parameters:

# application/ogg; codecs="theora, vorbis"   for Ogg Theora/Vorbis files
# application/ogg; codecs="theora, speex"   for Ogg Theora/Speex files
# application/ogg; codecs="vorbis"                 for Ogg Vorbis files

and also use the disposition parameter:

# application/ogg; disposition=moving-image; codecs="theora, vorbis"
# application/ogg; disposition=sound; codecs="speex"

Skeleton and the use of these MIME parameters should make things clear
for the application developers.



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

In reply to this: Xiph has very carefully created and frozen (1st June
2004) a definition of the theora codec bitstream format, which should
be persistent for a while to come. So, while it is possible that there
may be new features added, it is not currently a consideration. There
are still multiple rounds of software optimisation possible to theora
encoders before they will require a change to the bitstream format.

For the case of a bitstream format change, there is version
information in the header of a theora bitstream. Major and minor
version numbers are being used similarly to the way that *nix library
version numbers work - anything with a minor change is backwards
compatible, but a major change may not be. So, if a major version
number change was to occur with theora, a new MIME type would probably
be required, e.g. video/x-theora2.

I hope this answers the question?

Best Regards,
Silvia.