[Theora] Theora file extension

[Freun Laven]

<001601c453b9$c29ada40$1f649c3f at computername>
<40D0780B.7090405 at sympatico.ca>
<000d01c453c7$4f907100$1f649c3f at computername>
<40D08783.10605 at sympatico.ca>
Message-ID: <000f01c453d3$aa2fca00$ad389c3f at computername>

From: "Jon Doda" <jdoda at sympatico.ca>

If you reply, you need to be sure and add Theora at xiph.org to reply to the
list.  Otherwise it just gets sent only to the person.


> I think that's backwards.  The user can figure out whether a file is
> audio or video already without too much trouble, from looking at the
> name or size of the file, and from context.

In many cases they can, yes.  Especially if they are the ones who ripped the
cd into that format or converted it into that video format.

But don't forget, the vast majority of media programs today look solely at
the file extension to decide whether they even recognise the file.  That's
how they know to look at .mp3 and not even bother with .TXT files, etc.
They don't go to a file, open it, read the contents and then try to decide
if they should know about it.  (Well, Windows XP sort of does that with .AVI
files, and look at what happens to it when the file is damaged....  It
pretty well locks up until it finally decides it doesn't know how to handle
it.  Sometimes that can take several minutes.  All because it tries to be
'fancy' and 'helpful' and actually looks at the file contents.)

And every p2p program does that too.  They'll look exclusively at the file
extension to know whether the file gets put into the audio, video, text,
etc. categories.  Regardless of your opinion of p2p, or whether you only do
legal stuff or have a collection large enough to make the RIAA & MPA cackle
with glee, p2p programs are here to stay, and they only look at the
extension to determine what kind of file it is.

On the web, when you see a file, it might be named:  Jane Child - Don't
wanna fall in love.EXT

Is that the audio or the music video?  Maybe the context of the web page
will tell you, but most users will look at the extension.  If it's .mp3 it's
audio.  If it's .avi it's video.  If it's .WMA it's audio.  If it's .WMV
it's video.  If it's .ASF then they don't know because it could be either.
If it's .RAM they don't know because it could be either.   If it's .mp4 then
they don't because it could be either.  If it's .OGG they expect it to be
audio, even though it could be video.

At least with .AVI you know it's extremely likely there is video in there.
But you don't know it for sure.  The same is true for .mp4.... Is it audio
or video?  That was solved by just changing the file extension to .m4a for
audio.  Still the same file format though.  Still possible to have video in
there.  Same for the .WMA and .WMV format.  The same exact file type and
still possible to have audio and / or video in either extension.

The extension is there for the user's convenience.  With a container format,
the application has to know what to do if it contains something other than
what they thought.  That's just the way it is.  It's not unique to .OGG


> name or size of the file, and from context.  It's the file manager (and
> almost all file managers now work by mapping an extension to a
> mime-type) and applications that have to be able to tell the difference.

Not with the ogg format they don't.  It's a generic container.  They have to
be able to deal with both video and audio.  If they can't deal with video,
then it'll be up to the application what happens.  Probably they'll just
ignore the video part.  Not only do they have to deal with both audio and
video being possible in a .ogg, but they also have to face the fact that it
may not be vorbis but some other codec in the ogg container.  (Such as FLAC,
speex, mp3, Theora, Divx, XVid, etc.)

By adding an audio and/or video extension, it wont help applications in the
slightest because it will *still* be the exact same ogg container file.  It
would still be possible for the supposedly audio file to actually be a video
file.

The same is true for any container format, such as .mp4, WMA/WMV, AVI, etc.

The extension would be for the user's convenience.  Such as easily
recognising the differences, or making it easy to tell one program to handle
the audio extension and another program to handle the video extension.  Same
container, just for the user's convenience.

>   It's true there was a trend toward applications that handled both
> audio and video, but (due largely to the influence of iTunes) they're
> now starting to differentiate again.

It's not about media players being able to do both or just one.

They are going to have to do that anyway because the .ogg extension is
generic and the container can handle both audio & video.  They already
*have* to be able to know to ignore the video (or anything else) if they
can't handle it.

> I want my video oggs to open in Totem and my audio oggs to open in
> Rythmbox, but without separate mime-types and extensions that can't be
> done.  That's the problem that has to be solved.

It aint going to be solved the way you want.  That's pretty obvious.

But if you put your audio as .ogg and your video's as .ogv or such, then
it's *trivial* to do what you want.  The player just needs to be told of the
extension.  (ie: programmed into it with the next revision, or told manually
by you.)  It'll just be a plain alias to the already exsting .OGG format
that it knows how to handle.  No new MIME type required.

If the player hasn't been updated to know that different extensions are
being used, just go into the file manager and tell it to always use app XYZ
to handle a file with extension .ABC


Nobody here is suggesting or planning to create new file formats or
container formats.  You can forget about that.  It will always and forever
be possible for a .OGG, .OGA, .OGM, .OGV etc. file to hold audio only, video
with no audio, or both audio and video.  And with several different codecs
possible for both the audio and video parts..   So an application is going
to have to be able to deal with a generic ogg container with arbitrary
contents.  Just like they already should.  You aren't going to solve that
unless you create brand new audio only & A/V specific containers, and that
is not going to happen.


The only thing being discussed is a way to help the user (and some programs)
recognise the difference between an audio and video file for the user's
convenience.