mime types and video/audio files (was Re: Review of the thumbnailer spec)
awalton at gnome.org
Tue May 19 13:44:26 PDT 2009
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
> xdg mailing list
> xdg at lists.freedesktop.org
More information about the xdg