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

Ivo Emanuel Gonçalves justivo at gmail.com
Wed Jan 17 06:06:11 PST 2007


On 1/16/07, Aaron Colwell <acolwell at real.com> wrote:
> What happens when a new audio/video codec is added to the mix? A new extension?

Nope.  As stated in the original message, it's not possible to guess
all kinds of combinations that may go inside an Ogg container, nor
what kind of new formats Xiph may develop in the future (Holy Ghost
Batman!).

This proposal is aimed at the more important formats in the Ogg
family, those that need to be marketed aggressively, those that are to
be used by the average joe.

> What would be the extension for a chained file that contains audio-only
> and A/V segments? (My _favorite_ corner case in the ogg format. :| )

.ogg

It falls under the mixed bag category mentioned above.

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

All kinds of things are wrong there.  Those extensions use a three
letter namespace, they are hard to remember, easy to confuse, and
moreover they tell the user nothing much about what the file is
supposed to be about.

> Why do we need a new extension for FLAC?

Ian proposed a new extension for FLAC.  I, on the other hand, believe
FLAC players should accept .ogg as possible container for FLAC, as
right now they don't.  And the idea of Ogg FLAC has been around for
quite a while.

Although .music-perfect has a nice sound to it, it's possibly too
large for an extension.  Of course that applies to .video-perfect as
well, but those are so far only a suggestion asking for feedback.

Personally, I stand behind .video, .music and .voice.  It's simply perfect.

It's a shame that we are apparently going over yet another extension
flamewar, but things as they are, are not all right.  There wouldn't
be this kind of talk all the time if things were okay.  Let's hope a
consensus is achieved soon, because there's far more important things
to fix around here.

> Media applications are able to deeply inspect the file if they really need to
> determine which codec it contains.

If this were true in all (or most) cases, we wouldn't be having this discussion.

> Don't burden the masses with a ton of extensions just to appease
> a select few. Proliferation of a bunch of new extensions will only
> confuse users in my opinion.

Although I respect your opinion, I believe it's just the other way
around.  Moving away from legacy extensions, and in the process trying
to unite more the projects under Xiph will only benefit users.  Those
extensions are the kind easy enough to remember that if one day they
become mainstream, people will look with suspicion at things like
.wmv, .avi and .acc.  It just makes no sense.

Since players are (in theory) supposed to accept legacy extensions for
backwards-compatibility, the (few) people right now that care about
the Ogg family will not mind the change, as their old media will still
play well.

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.

On 1/16/07, Silvia Pfeiffer <silviapfeiffer1 at gmail.com> wrote:
> Also consider that the extensions and an associated mimetype will need
> to be ratified by the IETF to become "standard". They would never
> agree to these extensions since they are too broad.

This might be the only problem I've seen so far, and even then, I'm
not sure it's really a problem.  As far as I understand how the RFC
process works, extensions shouldn't mean much.  Regarding, MIME issues
though, I'll mention (again) Ralph's disposition-type proposal.  Since
to me it doesn't seem like it breaks any application that relies on
application/ogg, I doubt the IETF will oppose that.

Best wishes,
Ivo Emanuel Gonçalves


More information about the xiph-rtp mailing list