[ogg-dev] OggPCM proposal feedback
arc at Xiph.org
Thu Nov 10 17:40:01 PST 2005
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
More information about the ogg-dev