[xiph-rtp] Re: [Vorbis-dev] Proposal: An extension to rules all
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:
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:
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 when serving content (killing
performance), or add a requirement to store metadata separately on the FS for
performance (requiring rewriting servers).
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
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