[ogg-dev] OggYUV

[Arc]

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