In the effort of reducing list traffic, I've consolidated two replies into
one:
On Tue, Nov 08, 2005 at 08:24:33PM -0800, Ralph Giles
wrote:>
> BTW, there are already a number of general "raw" video formats in
> professional use; it's not just AVI we have as prior art. :)
> I'd like to see some discussion of the merits of adopting one of those
> if we want something more sophisticated than yuv4mpeg.
I've made attempts to contact the author of HuffYUV over the past week.
He's
not easy to track down, but his (windows) implementation is GPL'ed, and it
shouldn't be difficult to rewrite his codec into a GNU/Linux library, and
such a
rewrite could be placed under a Xiph license (I doubt there's much code
reuseability, anyways, though contacting him first would always be best).
I'm sure there are others, too.
> So in theory we already have an uncompressed format too.
> Unfortunately one often has to bit-shift the input to do this, so it's
> not ideal, and of course the primary advantage of an uncompressed format
> is the simplicity of implementation.
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.
On Wed, Nov 09, 2005 at 12:28:07PM +0800, illiminable
wrote:>
> Well it won't use OggStream, because it already has it's own
method, which
> has already reduced the workload. And anyway, it's a component system,
with
> controlled memory passing, you can't just chuck a few callbacks at it.
OggStream doesn't use callbacks. Go back a few days on the list and read
what I
wrote about what I'm doing with the liboggstream vs liboggfile split,
OggStream
is basically an Ogg codec plugin handler, processing data on the packet level
only, leaving muxing, seeking, etc to higher level code. It's designed to
be
used by existing frameworks and is no more complicated than the rest of libogg2.
However, if Windows isn't one of the players planning to use this, we
shouldn't
even worry about it further. If it does, one day, have OggStream support to
ease codec porting and unify the plugin database, it'd be fairly trivial for
the
DirectShow filter to have a table of which formats it supports, which FourCC
codecs they translate to, and to use OggStream plugins to convert as needed.
> So you are just increasing the burden now, for an unknown payoff.
Generalizing the format doesn't increase the burden. That's what
I've been
trying to clarify, since no application needs to support all the capabilities,
nor would any piece of software be expected to, there's nothing extra that
needs
to be supported. They only need to support what they directly use.
Now, if you're on Windows, and you want FourCC data, sure you'll have to
run it
through a table. But that's better than forcing FourCC on GNU/Linux, making
us
look up arbitrary 32-bit sequences to see what parameters they call for.
I know you're frustrated by Ogg's lack of a FourCC field standard in
Page0, but
we do have a standard developing, and given the power of even embedded CPUs,
ours makes much more sense.
Think of all of Page0 as your "fourcc", supporting with a single codec
a hundred
different FourCC codecs, no more squeezing codec versions into the 4 letter
space and still have it unique, no more restricted upgrade revision path, no
more table of a hundred raw formats which only differ in small trivial ways.
> Like i said, it makes little sense for my implementation. All i see are
> fourcc's, why would i want to write code for something that won't
be used.
But you already stated that you won't be using OggStream with DirectShow.
So your Xiph/Ogg codec plugins will not export to OggPCM, OggYUV, or OggRGB, but
rather to FourCC within DirectShow itself. None of these are expected for
distribution, people will surely compress them (even losslessly) to save
bandwidth and/or disk space so it's unlikely, should an implementation for
these
not be available to your filters, that your filters would ever be expected to
use them by a user.
Ah - I'm basking in the great feeling of liberation from the constraints of
an proprietary OS and it's obsolete media framework ;-)
--
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