[xiph-rtp] Re: [Vorbis-dev] Proposal: An extension to rules all others

Michael Sparks Michael.Sparks at bbc.co.uk
Wed Jan 17 13:11:23 PST 2007

[ Replying to the digest of xiph-rtp-bounces at xiph.org where I saw this, if the 
  quoting/reply list looks odd, I've trimmed down the "I'm mailing everyone"
  address list. ]

I've been lurking watching this discussion, and when I originally saw it, I 
was baffled - ogg does already have an extension to rule all others - .ogg
for better or worse, it matches all ogg format files. 

Given the argument was to better hint at the file contents, I thought this 
argument has the best going for it:

> > What is wrong with the MP4/Matroska/Windows Media/RealVideo model?
> > .oga (Vorbis, Speex)
> > .ogv (Theora, Theora + Vorbis, Theora + Speex, Tarkin, etc)

The biggest argument against this that I saw is that this is aesthetically
bad, and had no place in an open standard. However, if that's the case, why 
would the OASIS - the group leading the Open Document Format which 
OpenOffice.org uses, standardise on the following endings:

   * .odg - open document format, graphical
   * .odp - open document format, presentation
   * .odt - open document format, text
   * .ods - open document format, spreadsheet.

The reason is simple it has a basic stem which is clear, and can be used, in
a limited fashion to differentiate based on a .odX stem. Whilst I've not seen
it, I wouldn't be too surprised if MXF (another open standard) was used in
conjunction with ODF to define an ODF format for audio and video. If that
was the case, then I'd expect those to look like:
   * .oda
   * .odv

Why is 8.3 *still* important decades after it shouldn't be? Because a number 
of common file systems which are widely deployed still have 8.3 as their 
basic underlying file system. Remember, without using certain extensions 
(though widely used, they are extensions) CDROMs would be limited to 8.3. 
Certain personal cdrom players that play vorbis, amongst others, are well 
within their rights to only accept such CDs. Also, like many other things 
they'd look at the file extension 

It's got *nothing* to do with pandering to proprietary whims, which I suspect 
is being reacted against, but everything to do with *practicality*.

Regarding the arguments in favour of:
   * .music
   * .voice
   * .video
   * .music-perfect
   * .video-perfect
   * .voice-perfect

You have to remember that this is hideously painful if you're running a 
webserver and causes problems on the client side. Many webservers detect the 
mime type of an object based on filename extension. In order to send the 
header (for example) text/html for a random HTML file, many webservers look 
at the extension, and look it up in a table, and send out the file.

Now, if NO ONE had ever chosen to create files of these kinds before, then
maybe. However the reality is there are many container formats, many codecs,
and which player you launch really depends on the file format. (In some 
respects, this is something Microsoft did that was quite sneaky with their 
extension for DOCument formats. However, that was _relatively_ early on, 
rather than this late in the game)

Sending the correct MIME type enables the client browser (or OS if delegated 
to the OS) to choose the correct application to launch.

So what this actually means is that a server, based on looking at the filename 
alone, could not guarantee the file format or codec type. In practical terms 
this means either the client gets a generic MIME type (as you do at present 
with .ogg, which *is* less than ideal, but that's life :), or you have to 
start looking at file magic numbers[1] when serving content (killing 
performance), or add a requirement to store metadata separately on the FS for 
performance (requiring rewriting servers).

  [1] http://en.wikipedia.org/wiki/File_format#Magic_number

I understand the basic desire here, but it comes across as naive. Also, not 
all audio is music OR voice. Much is a mixture, some is neither. If you 
*really* wanted these you'd have to do .audio or .audio-perfect.

(BTW, the content disposition idea here is irrelevent when it comes to the 
idea of identifying *as quickly as possible* the correct/most useful MIME 

**My personal view is either don't change it** .ogg isn't really that bad, 
(even if it could be better). 

Or if you much change it, change it such that .ogg for video is deprecated, 
recommend .ogv for ogg format files with video inside (preferably *with* 
audio), and recommend .oga for audio only files. (The only minor foible here 
would be for legacy audio players that would only see .ogg and assume those 
are contain vorbis)

Also, put it this way, you say this:

> Finally, I also believe that this change means also a change of
> attitude from Xiph.  Many in the industry, or even in the
> mailing-lists here, have quite a few times pointed out that we are not
> promoting our projects well, or even at all.  This, I hope, is a step
> in the right direction.

By promoting .music/.music-perfect/etc you would instantly turn off a
large number of people you seem to want to promote to. It's hard enough to
get acceptance of these formats without changing from one extreme ("ogg?
huh? what's that? A caveman come up with the name?") to another
(".music? .video? Who came up with that ?" - I doubt it'd be that
polite however...).

After all, remember you're not just hinting to a person, you're hinting to a 
machine. The more information you can encode cleanly whilst taking legacy 
into account, the better. (hence my view above about .ogg (with video) 
-> .ogv and .ogg -> (.ogg & .oga) ).

I must admit I'd also like to see:
   * .ogr - Ogg Rich - which would be multiple audio & video streams in
     the same file for things like audio description and multi-language
     subtitles, and alternate audio tracks. (I'm not convinced ogg is
     actually the right sort of format for that sort of thing anyway

But that's a pipedream anyway...

Also, finally regarding .ogr/oga.ogv/etc. Bear in mind that the average user 
actually uses a GUI to interact with their content, and often one that gives 
them a pretty picture to indicate content type. Far more informative to the 
many people round the world for whom ".music" is just as unintelligible as 
".ogm" might be.

Anyway, that's my tuppenceworth,

Michael Sparks, Senior Research Engineer, BBC Research, Technology Group
michael.sparks at rd.bbc.co.uk, Kamaelia Project Lead, http://kamaelia.sf.net/
New Broadcasting House, BBC Manchester, M60 1SJ, +44 (0) 161 24 44323

More information about the xiph-rtp mailing list