[whatwg] Give guidance about RFC 4281 codecs parameter
singer at apple.com
Wed Apr 11 17:45:34 PDT 2007
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
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?
>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.
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...
I'm not sure how pertinent this is to whatwg, though...
More information about the whatwg