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

[Ian Malone]

Daniel Holth wrote:

(Warning: long.  In summary I think I support Silvia's suggestion
though if it was practical I think it would be useful to have
apps supporting .oga, .ogv MUST support decoding from muxed Ogg
streams, and MAY drop unrecognised logical streams?)

>>>
>>> I'll remind everyone that on the Monthly Meeting of October 2006,
>>> everyone there reached a consensus that we should avoid at all costs
>>> the use of extensions of three letters.
>>>
>>> -Ivo

> So far, this community has refused to believe that fetching three
> bytes at the end of every file in a directory (all at once) is better
> than fetching the first kilobyte of each file (across the network, one
> TCP connection at a time), then parsing it with codec-specific
> methods, just to determine whether it's audio or video so that we can
> know whether to copy it to a device that doesn't have a screen or
> transcode it into xvid or H.264 so we can view them on devices that do
> have screens.
> 
> Basically the message is "we want you to love freedom (and re-write
> all your file managers)".
> 

Given that modern file managers have a stab at providing previews
this is actually becoming more reasonable.  There is something to
be said for simplicity, though the argument for parsing has always
included the fact that the extension won't tell you what codecs
the file uses (the avi problem).  While this is all very interesting,
I find myself agreeing with your next point:

> 
> I suggest that the file extension is a very poor place to put
> innovative features. I would appreciate it if a leader would come up
> with the most boring, most conventional solution possible, while
> everyone else wrote codecs or something.
> 

To summarise the arguments for .3 so far (actually arguments
against .>3) then:

1. .>3 is still fairly non-conventional.  Xiph is having enough
    difficulty promoting its codecs as it is without also trying
    to push a new way of naming files.
2. .>3 may be unsupported by embedded environments and by some
    FS, this is coupled to:
3. .>3 on the FAT family (widely used for portable devices)
    requires MS patented LFN.  This is actually in direct conflict
    with the aim of providing patent free technologies (okay,
    it's very peripheral, but manufacturers of portable devices
    would potentially have to pay patent fees to use Ogg).

For:
1. Maybe quicker recognition from 'power users'.

Given the above, .>3 seems to be a distraction (or even more
of a distraction than the general extensions question).

The agreed points seem to be:
1. A only and A/V get separate extensions.

Suggested and not opposed:
1. .ogm should be avoided as it might increase confusion

The important questions are:
1. Move on from .>3?
2. What should .ogg be?  So far suggested:
  a. Legacy only.
  b. Retained for Vorbis I.
  c. Used for all A only.
  d. Retained for corner cases.
  e. Retained Vorbis I and miscellaneous.
3. What about corner cases?

Finally (as I try to avoid work), I've observed my iAudio
player recognises Vorbis by the .ogg file extension.  Files
ending .oga or .ogb wont play, they don't even show up.
Cowon has been pretty good about working on their Vorbis
support, but I suspect manufacturers of the cheap players
that have started to show up playing Vorbis won't care so
much.  What would be a bad idea is throwing away progress
made so far.

What does Xiph have control over?  The larger the existing
player base and number of existing files in the wild the
harder it is to change.  Published standards are also a
bit of an obstacle.  My own perception is (in order of
decreasing influence):
*(most) Codecs still in research or published but not in
  use yet, corner cases[1].  This is everything on
  <http://wiki.xiph.org/index.php/Work_In_Progress>.
  Maybe Vorbis + Skeleton belongs here.
*Speex, FLAC: popular, but Ogg encapsulation may be less
  widespread.
* Theora+Vorbis
* Vorbis I (standard and installed base)
* .ogm (non-Xiph)
*(least) RFC 3534 as Silvia points out.  AFAIK to anyone
   following RFC 3534 any Ogg bitstreams may be .ogg.

Which roughly agrees with Silvia's suggestions
<http://wiki.xiph.org/index.php/MIME_Types_and_File_Extensions>
.ogg is probably tied to generic Ogg AND to Vorbis I
  (inconvenient)
.ogv and .oga are fairly painless
Existing Speex, FLAC conventions don't conflict.

Specify that apps supporting .oga, .ogv must support
Skeleton and other muxed files, dropping unrecognised
logical streams?

Hate to introduce yet another dimension but maybe an
unofficial .ogx for streams containing experimental
codecs?  (Not as a recommendation but for putting
test files up on the web that aren't expected to be
generally playable.)

-- 
imalone