[ogg-dev] OggPCM proposal feedback

[Arc]

On Thu, Nov 10, 2005 at 02:02:45PM -0800, Ralph Giles wrote:
> > 
> > You're still working with the philosophy of FourCC-world, where based on 
> > wether a plugin or application supports a 32-bit identifier you know if 
> > it either has full support or no support.
> 
> It's not just the FourCC world; lots of unixland audio code works this 
> way too. I agree with de Castro Lopo. Making a general format and then
> saying people are free to only implement the subset they care about is
> contrary to Xiph's design philosophy and will lead directly to 
> interoperability issues. It's better to specify and require a useful
> subset here.

Let me give you a few examples, showing where software would only support 
certain formatting options:

XMMS (or any audio player) implementing Ogg Vorbis - Ogg Vorbis supports over 
200 channels (is it 255 or 256? the latter would seem more useful), but XMMS 
only supports 2.  What happens when it encounters more?  In the OggStream system 
of compatability, the media player wouldn't support it, and would toss it back 
into the OggStream pool to get it downmixed - something we'll have to look at 
soon, as the issue of surround sound handling has been looming.

Current Theora implementations don't support interlace video, or more than a 
small set of possible colorspaces, other chroma subsampling, etc.  It's in the 
format, but the current libtheora only does non-interlace 4:2:0 (IIRC???).  A 
future encoder, producing an interlaced 4:2:2 stream, would be unsupported - a 
situation where some component of the system sends packet0 to a web interface at 
(ie) codecs.xiph.org, and finds that there's a new Theora plugin available which 
supports the formatting of this stream.

Portable media player, supporting Ogg, tries to play an 64-bit OggPCM stream.  
Should the player be really expected to handle this, even though it supports 
16-bit and 24-bit OggPCM streams?


The alternative to this, to do things closer to the FourCC way, would be to 
limit the capabilities of Vorbis, Theora, etc.  Require all Vorbis to be 16-bit, 
call it Vorbis16, and have a set of extended Vorbis codecs released every year 
or two with better capabilities.  This might result in something like DTS's 
family of codecs:
 DTS-ES - basic 44100/16/5.1
 DTS96/24 - 96000/24/5.1
 DTS HD - 44100/16 OR 96000/24 w/ unlimited channels (aka DTS++)


My point is that the tradeoff of not developing uber-specialized codecs is that 
some software won't be able to use it directly, and it's perfectly OK if media 
player X can only support 2 channels, as long as a plugin can be written which 
does the downmixing for it everything still works.

It's better to have conversion utilities as codec plugins to the base framework
than to either 1) cripple our codecs to only supporting what is reasonable to 
expect every piece of software to support, or 2) expect every piece of software 
to support the huge variety of encoding parameters available with our codecs.

It's from this philosophy, which partially came from extended talks w/ Monty, 
that I designed OggStream the way I did.

-- 

The recognition of individual possibility,
 to allow each to be what she and he can be,
  rests inherently upon the availability of knowledge;
 The perpetuation of ignorance is the beginning of slavery.

from "Die Gedanken Sind Frei": Free Software and the Struggle for Free Thought
 by Eben Moglen, General council of the Free Software Foundation