Vorbis dev - Jan 2003 - Re: Ogg Internet Drafts - create application/ogg-vorbis, application/ogg-tarkin, etc.

On Thu, 2003-01-02 at 10:48, David Wheeler wrote:
> 
> > Unfortunately, an Ogg file can (and will) contain different codecs in
> > the same file. Imagine a file that contains two chained groups of
> > multiplexed bitstreams. The first group contains vorbis, vp3, speex,
and
> > subtitle streams. The second group contains FLAC, MNG, and MIDI
streams.
> > [The fact that it's hard to envision a use for this monster
doesn't
> > negate the fact that such a monster is still a perfectly valid Ogg
> > file.]
> > 
> > What would its MIME type be?
> 
> 
> 
> I think there should be a "generic" Ogg MIME type, e.g.,
application/ogg
> or whatever.  But nearly all Ogg files will only have a very small
> subset of codecs, and it's _extremely_ helpful if the MIME type is
> more specific.  Let's face it, although your "monster" is
legal Ogg,
> I doubt it would be the majority use :-).
> 
> 
> >>>For example, many people have _separate_ applications for
audio-only
> >>>instead of audio+video.  It would be better if they could start
the
> >>>"right" application using just the MIME type
information (instead of
> >>>awkward two-stage start-ups that are different than anything
else).
> >>>At the least, I suspect there is a need to have different MIME
types
> >>>for audio-only vs. video.
> >>>
> > 
> > So, which one is the right handler for the above monster? I think it
> > would be an application that can identify the codecs inside an Ogg
file
> > and route each stream to its appropriate decoder.
> 
> 
> No, that is excessively complex for 99.99% of normal uses.
I guess my initial description was not clear enough. The way I imagine
it, there's no added complexity for the user at all. I imagine a very
thin application that the user won't even have to see. That application
would peek into the Ogg file, and determine which application to launch
to handle the file. It could even have a reasonable default
configuration, like launch the default audio player for Vorbis and the
default video player for Theora, so the user won't have to do anything
beyond installing it.
> There's ALREADY a multiplexor in the operating system and browser of
> all of today's systems.  They use MIME types.  If you have a
sub-multiplexor
> to figure out Ogg types, that's a great reason to ignore Ogg - it's
> "just too complicated."  Let users use their _existing_ setup
where they can.
> There's no reason to create a dual-level multiplexor just to hear
> an audio clip in the most common Ogg audio or video format.
As you say below, MIME types have an inherent limitation, so the
OS/browser multiplexor is clearly insufficient.
> > For special cases, there are special considerations. E.g. an Ogg
Vorbis
> > file (by definition an Ogg file that contains Vorbis streams that are
> > not multiplexed, only chained at the most) is allowed to have
> > audio/x-vorbis as its MIME type. [But it would still be allowed to be
of
> > type application/ogg or application/x-ogg, since it is an Ogg file,
> > after all.]
> 
> 
> Here we completely agree!   But I'd say that the weird Ogg file is the
> special case, at least in terms of number of times it's used.
> The "normal" cases would be an Ogg Vorbis only file, or an
> Ogg Tarkin + Ogg Vorbis file, or an Ogg Speex file.
> 
> This is actually a general problem for MIME.  Many files are XML, or
> gzipped XML, but MIME wants a more specific type.  I can't fix MIME.
> But few users want the "generic" tool - they want an application
to handle
> the file, so having the specific information is much more useful in
> most cases.
As I explained above, the user won't see the generic tool. It is a thin,
transparent layer that directs the file to the appropriate (specific)
application.
> >>>Also, not all applications can handle all codecs, even if they
handle
> >>>that kind of media; that would be ESPECIALLY true if Ogg
supports multiple
> >>>codecs... which it does.
> >>>
> > 
> > Which is why it's especially important to have one application
that
> > handles the Ogg and routes each bitstream to the appropriate decoder.
> 
> 
> 
> I don't see that happening.  There are applications tailored to playing
music,
> others for playing video, others for conversing on the phone.  They
> tend to be separate and invoke Ogg - not the other way around.
> They're all specialized for the way the applications are USED.
> 
> If the Ogg codecs were the only ones that existed, I could see that.
> But I think it's improbable that the application vendors will suddenly
> merge because Ogg is now available.
It should be clear from the above that the application vendors don't
have to merge or cooperate at all for a generic '.ogg' extension to
work.
 
> >>>Thus, I believe the MIME type should identify both Ogg &
the codec.
> >>>Perhaps an application/ogg-vorbis, application/ogg-tarkin, etc.
> >>>You could also register application/ogg (to be used when a more
specific
> >>>MIME type isn't available).  Ideally the standard filename
extensions
> >>>should be different too; Ogg Vorbis could be ".ogg"
since that's become
> >>>so common, Ogg Tarkin could be ".ogt", etc.
> >>>
> > 
> > Ideally? You seem to be stuck in a world of operating systems that
need
> > a specific filename extension to identify a file type.
> 
> 
> 
> Sounds like you're a Mac user.  This _is_ an expectation of
Windows/MS-DOS,
> Unix, and Linux.  If ogg is going to be successful, it _must_ support the
> conventions of these operating systems, and easily work _within_ them.
Actually, I am a Linux user. The Linux OS doesn't impose anything on
anything, as determining a file type is not a task for the OS, despite
anything that Microsoft want you to believe. It's up to higher level
tools to do this, and there are tools that look into a file's contents
to determine its type. If a file manager determines the type of a file
by its extension, that means the file manager needs to be made smarter.

[In case you want to know what filemanager is already that smart, I
don't know. My filemanager is the command line ;)]

Besides, we don't have to rely on either the OS or the filemanager to
determine the exact set of codecs inside an Ogg file. All it needs to do
is to determine that it's an Ogg file, and hand it over to the Ogg
multiplexor, which will hand the file over to the appropriate
application.

Best regards,

Carsten Haese.

<p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'theora-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

I remain convinced that there need to be both generic Ogg MIME types
and specific MIME types for common codecs placed in Ogg.
Having _only_ a generic MIME type will be serious problem over time.

Details below.

Carsten Haese wrote:
> On Thu, 2003-01-02 at 10:48, David Wheeler wrote:
> 
>
> 
> I guess my initial description was not clear enough. The way I imagine
> it, there's no added complexity for the user at all. I imagine a very
> thin application that the user won't even have to see. That application
> would peek into the Ogg file, and determine which application to launch
> to handle the file. It could even have a reasonable default
> configuration, like launch the default audio player for Vorbis and the
> default video player for Theora, so the user won't have to do anything
> beyond installing it.
<p>I believe that extra level of indirection is a serious problem
if that is the ONLY way people can get Ogg files.
Basically, this approach would impose a nonstandard method for accessing
Ogg files, reducing the likelihood of Ogg use.  In a standard, you want
to "play nice" and work well with other existing standards.

The whole point of the MIME standards is so that recipients will
know what application to kick off when they receive binary data;
by giving them more information, you make it easier for them to
accomplish that.

Imagine that you're a developer of a sound-playing application.
The operating system environment already has lots of tools to
automatically deal invoking a MIME type, e.g., "audio/ogg-vorbis".
If I register that specific type, I can depend on pre-existing
environment tools to register, unregister, set preferences, etc.
I have an entire library all set... and users & administrators who
know how to manipulate it.  Windows, GNOME, KDE, all have such tools
and conventions.

Now let's imagine that there is _only_ "application/ogg".
That means for every environment, I have to build yet another
multiplexor that figures out what app to run.
If you install a program, it needs to install the multiplexor
if it isn't installed yet (since it's not part of the OS),
I have to register with the multiplexor -- but wait, that means I
need to create a standard interface with the multiplexor for
installing & deinstalling.  I need GUIs for the
multiplexor so that users can control how things get invoked,
on all platforms.  And I need all vendors to agree on these
interfaces.  Basically, you have to re-build a part of the
environment, AGAIN, just so you can multiplex.

Users _HATE IT_ when you recreate a part of the environment for
no apparant reason.

Now, if you really need all that infrastructure to handle the
weird file, okay.  But nearly all Ogg files are going to be
simple streams of just one audio codec, or just one
video codec + a standard audio codec.

Please, let the "common case" be simple for USERS.  Give the
applications enough data so that it's duck-simple for
programs to install themselves and get invoked when needed.

<p>> As you say below, MIME types have an inherent limitation, so
the
> OS/browser multiplexor is clearly insufficient.
<p>It's quite fine for normal use.  Define a generic MIME type to
handle weird cases, and define specific MIME types to handle normal use.
That way, you can do all things... and the normal cases are
handled simply.

By the way, doing this also greatly simplifies the multiplexor too.
If you only get "audio/ogg", then a good default is to send it
to whoever handles "audio/ogg-vorbis" unless configured otherwise.
So.... even if you really think that EVERYONE needs a multiplexor,
you STILL want very specific information on codecs in the MIME type.

<p><p>> As I explained above, the user won't see the generic
tool. It is a thin,
> transparent layer that directs the file to the appropriate (specific)
> application.
<p>But programmers now have to deal with two levels: the multiplexor
and the OS environment, as described above.
And occasionally users have to manipulate their MIME type processing -
in Windows, this is actually quite visible as a right-click operation
(though they often don't realize that's what is happening).

In short, PLEASE set things up so they work the "standard" way.
A standard that interferes with other standards may sound more clever,
but users hate them.

<p>> It should be clear from the above that the application vendors
don't
> have to merge or cooperate at all for a generic '.ogg' extension to
> work.
<p>Yes they do.  They must coordinate on the new non-standard
Ogg multiplexor interface.  Whereas, if you give specific MIME types,
they can just use the predefined standard intefaces for registering
MIME types in the OS environment.

<p>>>Sounds like you're a Mac user.  This _is_ an expectation of
Windows/MS-DOS,
>>Unix, and Linux.  If ogg is going to be successful, it _must_ support
the
>>conventions of these operating systems, and easily work _within_ them.
>>
> 
> Actually, I am a Linux user. The Linux OS doesn't impose anything on
> anything, as determining a file type is not a task for the OS, despite
> anything that Microsoft want you to believe. It's up to higher level
> tools to do this, and there are tools that look into a file's contents
> to determine its type. If a file manager determines the type of a file
> by its extension, that means the file manager needs to be made smarter.
> 
> [In case you want to know what filemanager is already that smart, I
> don't know. My filemanager is the command line ;)]
<p>I use Linux, Solaris, and Windows.  If you only use the command line,
then MIME types are less used.  Frankly, if you only use the command
line, why do you care?  Just invoke the program you want on the command
line, and you can be your own multiplexor :-).

It's not a Microsoft issue.  All the graphical user environments for
Linux and Unix (e.g., GNOME, KDE, CDE) primarily depend on filename
extensions to determine the MIME type.  You can do more, but it's
more painful and less portable.

Anyway, I would suggest the following for "normal" use:
  audio/ogg-vorbis
  audio/ogg-speex
  video/ogg-tarkin  {may have embedded ogg-vorbis in it}

And also define these for "generic" use.  Here's where your
multiplexor
can come in, but note that by giving files more specific types,
most users won't need or use the multiplexor.  By default, the multiplexor
could simply call on the default application for audio/ogg-vorbis and
video/ogg-tarkin respectively:
  audio/ogg
  video/ogg {may also embed audio}

<p>Thanks for listening!

<p>--- David A. Wheeler

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'theora-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

On Thu, Jan 02, 2003 at 01:48:59PM -0500, David Wheeler
wrote:
> > If a file manager determines the type of a file by its extension,
> > that means the file manager needs to be made smarter.
> >
> > [In case you want to know what filemanager is already that smart,
> > I don't know. My filemanager is the command line ;)]
> 
> It's not a Microsoft issue.  All the graphical user environments
> for Linux and Unix (e.g., GNOME, KDE, CDE) primarily depend on
> filename extensions to determine the MIME type.  You can do more,
> but it's more painful and less portable.
And more importantly, you suffer from *extreme* performance loss
if you try to open every file on a populated directory, especially
in terribly implemented OSes like Windows 9x. Ignoring Microsoft's
cruft, try using a file manager which opens each file of a cdrom
directory or an nfs share. If the file is slow or blocked, the window
manager may even block too, and crash, if not properly designed.

Finally, imagine future kernels like GNU/HURD, where you can have
a translator for a directory mapping to an ftp, and try to traverse
it with such a "smart" file manager, using a slow link.

Of course, don't let that discourage you. Somebody can implement
such beast, but the lack of it in practical environments suggests
that it's not the best option, because it's only usable in very
specific contexts, where file access is fast. And now remember that
KDE/Gnome users alreay consider their desktops slow...
--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

On Thu, Jan 02, 2003 at 11:53:45AM -0500, Carsten Haese
wrote:
> The way I imagine
> it, there's no added complexity for the user at all. I imagine a very
> thin application that the user won't even have to see. That application
> would peek into the Ogg file, and determine which application to launch
> to handle the file. It could even have a reasonable default
> configuration, like launch the default audio player for Vorbis and the
> default video player for Theora, so the user won't have to do anything
> beyond installing it.
What happens when I write my super-duper-vorbis player application?  How
do I get my app registered as a handler for Vorbis files with your
"peeker" program?  Or as a user, I download someone else's
awesome-tarkin program and I want to use it instead of anything else.
Every shim-type program that I've ever used are frustratingly limited in
what you can make them do with applications they weren't designed with.
> As I explained above, the user won't see the generic tool. It is a
thin,
> transparent layer that directs the file to the appropriate (specific)
> application.
I think such an application is also a pipe dream - many others have
tried and failed.  The multiple mime types approach is much more
sure-fire.


-- 
Ross Vandegrift
ross@willow.seitz.com

A Pope has a Water Cannon.                               It is a Water Cannon.
He fires Holy-Water from it.                        It is a Holy-Water Cannon.
He Blesses it.                                 It is a Holy Holy-Water Cannon.
He Blesses the Hell out of it.          It is a Wholly Holy Holy-Water Cannon.
He has it pierced.                It is a Holey Wholly Holy Holy-Water Cannon.
He makes it official.       It is a Canon Holey Wholly Holy Holy-Water Cannon.
Batman and Robin arrive.                                       He shoots them.
--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'theora-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.