mime types and video/audio files (was Re: Review of the thumbnailer spec)

[A. Walton]

On Tue, May 19, 2009 at 3:24 PM, Brian J. Tarricone <bjt23 at cornell.edu> wrote:
> Philip Van Hoof wrote:
>
>> In fact is it even worse for video thumbnailers, as the great guys of
>> the many multimedia frameworks and codecs decided to have types inside
>> of container MIME types. Making MIME mostly irrelevant for videos.
>  >
>> Thanks guys. For majorly messing things up once more in the world of
>> file formats. Making it all more difficult for all. Instead of simply
>> registering new MIME types that contain the codec in their MIME type
>> name (I still wonder why the heck not).
>
> I hope you're not seriously suggesting something like
> application/mkv-h264-mp3.  Because yes, you do need to specify all
> three.  It's very possible (and common) to have a codec supported in one
> container but not others, or to lack support for some container formats
> but not others.
>
> And what happens when you have a video file with more than one audio
> track?  Do you have yet another MIME type for it?  How do you order the
> audio tracks?
>
> MIME types just aren't suitable for describing video file contents and
> types, unless they can be extended to allow a single file to have
> multiple MIME types.  Then you might have a single file with types
> application/matroska, video/h264, audio/mp3, and audio/ac3 (or
> something).  But IIRC nothing like that is valid at present.
>
> If anything, MIME made *itself* irrelevant for videos by being too
> inflexible.  The a/v guys certainly aren't to blame.
>

Just as a note, this is precisely the rationale behind "Uniform Type
Identifiers", which support multiple inheritance and uses the
currently-in-vogue reverse DNS naming scheme (e.g. you can have types
like "com.my-media-encoder-company.complex-video-type" conform to
org.xiph.vorbis, com.bbc.dirac, org.xiph.ogg-kate,
org.xiph.ogg-container,  public.utf8-plain-text, public.movie,
public.video,  public.plain-text, public.audiovisual-content,
public.composite-content, public.content, and public.data in a tree
structure which should be rather deducible from the order they are
given here).

-A. Walton

>        -b
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg