[whatwg] Give guidance about RFC 4281 codecs parameter

[Silvia Pfeiffer]

On 4/11/07, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Apr 10, 2007, at 11:58 AM, Ralph Giles wrote:
>
> > On Tue, Apr 10, 2007 at 11:21:10AM -0700, Dave Singer wrote:
> >
> >>> # application/ogg; disposition=moving-image; codecs="theora, vorbis"
> >>> # application/ogg; disposition=sound; codecs="speex"
> >>
> >> what is the 'disposition' parameter?
> >
> > The idea of a 'disposition-type' is to mark content with
> > presentational
> > information. See the Content-Disposition Header for MIME described in
> > RFC 1806 for an early example.
>
> 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.

Ogg is more pragmatic in this respect:
application/ogg is for the bucket type
video/x-theora for the video codec stream (no audio)
audio/x-vorbis for the audio codec stream

Neither video/x-theora nor audio/x-vorbis actually tell you in what
container (bucket) your stream comes.



>
> > The specific proposal Silvia mentioned is to add the content-
> > disposition to the media-type to inform parsers of the general
> > nature of the content, even if they don't recognize the specific
> > codecs. The allowed values for the 'disposition' label come from
> > the Dublin Core set. This is not part of RFC 4281, and as far as
> > I know hasn't been formally documented with the IETF, but we do
> > think it's a good idea.
>
> It seems redundant with the "video/" and "audio/" base types, and
> adding such a feature just to make the point that the Ogg container
> is universal seems like a stretch.
>
> >
> > This arose out of the need to discover or record "audio" vs
> > "audiovisual" status for media files in the context of routing
> > to the proper playback application, which has been particularly
> > contentious with the Ogg container since we have insisted that
> > such distinctions be made via metadata or file inspection instead
> > of defining distinguishing filename extensions has has been done
> > with other containers. (MooV is perhaps another example.)
>
> File inspection is not really workable for content coming from the
> web that might be sent to an external app, so I think the Ogg
> community should reconsider this stance on distinguishing file types
> by primary use.


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.


> >
> > In terms of user presentation, "audio" vs "video" vs "text" vs
> > "still image" is the important distinction, while the 'codecs'
> > parameter answers the more technical question of what playback
> > capabilities are necessary.
>
> And indeed, MIME already has "audio/", "video/", "text/" and "image/"
> base types to make this very distinction. It seems unhelpful to
> invent a second way to say the same thing.

rfc4281 and many other digital media bucket formats show that this is
not an Ogg-only problem. Since multimedia comes in containers
(buckets) in order to serialise what is essentially time-parallel
data, there will always be a problem to describe both the container
and the containing type of data.

Since neither theora nor vorbis can stand on their own without a
container format (such as rtsp or ogg), video/x-theora or
audio/x-vorbis cannot indicate anything. They only make sense in
context. And the same applies, btw, to streaming text or images that
are part of a multimedia application. It's not as simple as dividing
the world into files of type application (sw), audio, video, text and
images. This simplistic world view has been overtaken by reality a
long time ago.

Best Regards,
Silvia.