On Wed, Nov 09, 2005 at 01:14:08PM +0800, illiminable
wrote:>
> >I agree, which is why I wrote the OggPCM draft when we already have
FLAC.
> >These
> >formats are not difficult to design or implement, and I think the added
> >efficiency and simplicity will more than make up for it.
>
> Which i looked at... and i'm wondering why on earth it has a sync code
in
> the packet... that's the whole point of putting it in a container.
Um, data packets consist of a 32-bit header followed by PCM data. Where did you
get the idea that "sync" data was in the packet?
I think you need to read the specification part of these things more carefully.
> >Ah - I'm basking in the great feeling of liberation from the
constraints of
> >an proprietary OS and it's obsolete media framework ;-)
>
> Seems to me you are just trying to be antagonistic. But anyway, if the idea
> is make something to be deliberately different then fine, i'm willing
to
> try and find a compromise that works for everyone, when in reality it's
> much easier for me to just do it my own way.
I don't understand why a compromise is needed, as you already said that
you're
not going to use OggStream in your DirectShow filters, insisting on continuing
to re-invent the wheel. I don't care either way, since while I understand
it's
important to have support on Windows, I'll never develop on it, and it's
likely
to be your time spent to port codecs to that proprietary platform.
While you port them, you'll change their format from OggPCM and OggYUV to
whatever the equivelent FourCC formats are and you'll be happy with that.
Your
filters use the DirectShow framework directly, after all, and you should use
whatever native format your framework uses.
As I said in the last email on this subject, if at some point you (or some other
Windows developer) decides that a generic Ogg DirectShow filter is benefitial,
using OggStream and porting the codec plugins directly, it will be trivial for
your "Ogg DirectShow filter" to change whatever raw format is being
spit out
into an appropriate FourCC format, quite likely, similar to what you're
doing
now with Vorbis and Theora. A table is all you really need.
We're talking about something extremely simple, how to denote how the raw
data
is encoded. Identifying that data by FourCC would not only overkill, but puts a
huge burden on Ogg software developers who must then support it.
KISS - Keep It Simple, Stupid. This is a raw data format. It's value to
everyone is primarily how simple it is to implement.
--
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