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

Ralph Giles giles at xiph.org
Wed Apr 18 10:07:24 PDT 2007


On Wed, Apr 18, 2007 at 05:03:26PM +0100, Ian Malone wrote:

> On 11/02/07, Ian Malone <ibmalone at gmail.com> wrote:
> <baulks slightly on remembering how many lists this goes to
> and a decent number I'm not subscribed to...>

Likewise. I've removed flac, xiph-rtp, and speex from the distribution 
as less relevent.

> >(What list should this be on?  I realise some of these lists are
> >to get attention from slightly peripheral groups, but should it
> >be moved to ogg-dev/advocacy?)

Probably, since codec developers don't care. :)

> A recent thread on fedora-list[1] got into the extensions discussion and
> reminded me that this hadn't reached a definite conclusion here.
> The points I remember that came out were:
> 
> (Comments apply to Ogg physical streams stored in files)
> * The main desire is to differentiate the extensions for streams
>  containing A/V and A only.
> * Extensions depending on the codec type aren't a great idea.
> * A simple scheme is preferred.

We agree so far.

Valent asked about this on IRC yesterday, and I thought it was worth 
summarizing the resulting discussion. Gregory Maxwell insightfully 
characterized this as a bike shed issue[2], which explains a lot.

Most of the core developers don't care what people name their files,
so to be clear, we are arguing over whether xiph as an organization
should endorse, implement and promote something besides .ogg as a
recommended extension for Ogg container files.

> .oga / .ogv  (new extensions, with .ogg remaining for legacy and corner
>  case uses)

.oga isn't strictly necessary, since the installed base assumes .ogg => 
application/ogg => vorbis-in-ogg audio file, if it assumes anything.

Note that speex-in-ogg sometimes uses the .spx extension.

> .ogg / .ogm (legacy extensions, possible drawback in not leaving
>  room for corner cases and requiring existing files to be renamed.
>  I got the impression the existing .ogm was something of a hack)

.ogm has the advantage of being already in use. However, the vast 
majority of tools that recognize .ogm expect xvid+vorbis and do not
handle theora+vorbis, so this would also cause user confusion.

Thus from my point of view, .ogv is the best candidate.

To restate the arguments against:

* The vast majority of users don't see extensions by default, and play 
everything back in Windows Media Player, so the audio/video distinction 
is not an obvious failing of the standard, it's a power user feature.

* We should have an ambition to do better than the DOS/Windows scheme 
for file type identification. Users should be able to name their files 
whatever they like and software should still function properly.

The arguments for:

* Worse is better: it might actually be less work to push out new 
extensions endorsed by Xiph than to keep arguing about this.

* Offering distinct A/V and A extensions would help adoption among
power users. [We didn't find this pursuasive; there might be people
dying to create great free format authoring tools if only it weren't
for the silly file extension, but see bike shedding above.]

On a related note, one of the Apple developers recently suggested[3]
we register video/ogg and audio/ogg to mark this distinction, as was
done for the mpeg-4 formats, instead of the Disposition Hinting
proposal[4] we have been favouring. This is almost orthogonal to the
extension issue, but I'd find multiple extensions more natural if we
did this.

FWTW,
 -r

> [1] "Why is Fedora a multimedia disaster? - Here is why."
>  <https://www.redhat.com/archives/fedora-list/2007-April/msg01825.html>

[2] "Color of the bikeshed" 
 <http://en.wikipedia.org/wiki/Color_of_the_bikeshed>
[3] "Give guidance about RFC 4281 codecs parameter"
 <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-April/010828.html>
[4] "RSS Disposition Hinting Proposal"
 <http://www.advogato.org/article/852.html#6>


More information about the Advocacy mailing list