[whatwg] Give guidance about RFC 4281 codecs parameter

On 4/12/07, Dave Singer <singer at apple.com> wrote:
> At 12:12  +1000 11/04/07, Silvia Pfeiffer wrote:
> >On 4/11/07, Maciej Stachowiak <mjs at apple.com> wrote:
> >>Wouldn't it be simpler to use "video/ogg" and "audio/ogg" as the base
> >>types here? That would already tell you the intended disposition.
> >
> >
> >Please note that rfc4281 also mentions the problem that video/* bucket
> >types could have audio only included in them:
> >
> >"With each "bucket" type, a receiving agent only knows that it has a
> >   container format.  It doesn't even know whether content labeled
> >   video/3gpp or video/3gpp2 contains video; it might be audio only,
> >   audio and video, or video only."
> >
> >Therefore, the video/* type does not clearly indicate which
> >application would be most suitable to be used with such a contant
> >type.
>
> But it does at least indicate that we have a time-based multimedia
> container on our hands, and that it might contain visual
> presentation.  "application/" suffers that it does not say even that,
> and it raises the concern that this might be arbitrary, possibly
> executable, data.  We discussed whether application/ was appropriate
> for MP4 and decided that it masked important characteristics of the
> format -- that it really is a time-based multimedia presentation --
> and raised unwarranted concerns.
>
> We had to settle on one type that was valid for all files, to deal
> with the (common) case where the server was not willing to do
> introspection to find the correct type.  We decided that "audio/"
> promises that there isn't video, whereas "video/" indicates that
> there may be.  It's not optimal, agreed.
>
> >Neither video/x-theora nor audio/x-vorbis actually tell you in what
> >container (bucket) your stream comes.
>
> These seem to be unregistered (x-) types that attempt to identify a
> codec in a container-independent way (a problem that the 'bucket' RFC
> struggled with), right?


Mime types for multimedia are a complicated field because of the
container formats. Will audio/vorbis imply a parsable containter
format as is required by UA applications, or will it just describe the
codec as is required by streaming applications? We are all in our own
way trying to solve these issues in the least ambiguous way. Xiph has
not registered any MIME types yet because the best way has not been
determined yet and the use of "x-" unregistered types is fully
functional.

What I reported on was our current state of discussion and I believe
it is relatively unambiguous.

A similar discussion can be had around file extensions. Both of which
I believe are rather off topic for WHAT WG.



> >I totally agree - file inspection is not workable in many cases and
> >therefore the MIME type has to indicate all of this information: the
> >bucket type, the contained codecs, and the suggested type of
> >application to use.
>
> Unfortunately, those parameters in the mime type relayed from the
> server are derived by ... file inspection.  Yes, types embedded in
> the page can be more accurate.

Deriving mime types for nearly all files can only be done through file
inspection if the file extension is ambiguous.


> I'm with my colleague here;  I think application/ is needlessly
> vague, raises unwarranted concerns, and avoids using acceptable, more
> specific types.  Maybe I should have said so on the IETF list when
> the I-D was becoming an RFC...

A container format that can have a multitude of tracks inside it
should have its own mime type. Unfortunately "application/" is the
closes match for describing container formats. This does not restrict
from using more specific mime types for files using this container
format that are specific. E.g. audio/x-vorbis+ogg has been used to
specify Ogg Vorbis files, and video/x-theora+ogg for Ogg Theora/Vorbis
files.
When creating Ogg files with e.g. 2 theora tracks, 4 vorbis tracks,
and 2 speex tracks, you still need a MIME type for this beast - and
since the beast can auto-identify itself through the skeleton and the
mime types inside itself, a media framework such as GStreamer or
QuickTime or DirectShow can still deal with it generically.

It is an issue of finding the balance between providing for the
generic and specific. The best way is to allow both, IMHO.

> I'm not sure how pertinent this is to whatwg, though...

Agree - even though a Web communication relies heavily on the use of
MIME types both at the server and the client side.

Regards,
Silvia.

Received on Thursday, 12 April 2007 04:14:56 UTC