ogg dev - Nov 2005 - OggYUV

This also includes, other non raw formats...
http://www.fourcc.org/codecs.php

"fourcc" 's of rgb types
http://www.fourcc.org/rgb.php

raw yuv formats only
http://www.fourcc.org/yuv.php

Registered fourcc codecs
http://www.microsoft.com/whdc/archive/fourcc.mspx

Enumeration of actual types that are used in directshow (bottom of page)
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcedshow/html/_wcesdk_directshow_media_types.asp

Descriptions of the common yuv types used in windows
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwmt/html/YUVFormats.asp
>
> Just because the codec supports it, doesn't mean that every application
> which
> uses the codec must support all the possibilities.  By making the data
> definition generic we allow more re-used code (ie, for colorspace 
> converters)
> and prevent the "raw codec" sprawl you above described with
FourCC codecs.
Well thats the thing about raw codecs, if you use the types that are 
supported by hardware and/or other codecs, you don't have to do anything 
except copy the memory.  When you start using things that no hardware 
generates, or can display directly, that's when you have to write code to 
convert.

All i'm saying, is there are certain types that are defined, hardware can 
display them, hardware like cameras generate them.

Zen.

On Wed, Nov 09, 2005 at 10:52:53AM +0800, illiminable
wrote:
>
> "fourcc" 's of rgb types
> http://www.fourcc.org/rgb.php
I'm prowd to say that http://wiki.xiph.org/OggRGB supports all of these 
losslessly as well as PNG for non-indexed bitmaps.  These are video formats, 
correct?  Not just single frames?

> raw yuv formats only
> http://www.fourcc.org/yuv.php
Wow, ok, this is interesting.  I don't know what to even call, ie,
"YVU9".

> Enumeration of actual types that are used in directshow (bottom of page)
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcedshow/html/_wcesdk_directshow_media_types.asp
> 
> Descriptions of the common yuv types used in windows
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwmt/html/YUVFormats.asp
These, assuming they're a subset of the above URLs, I'm not really
interested
in.  If DirectShow can't use a format exported by a video codec plugin,
that's
perfectly OK, it can either use another plugin within OggStream to convert it to
something it /can/ use or it can simply not support that codec..

This is of course assuming Windows will even end up using OggStream.  It'd 
certainly reduce the workload of the DirectShow filter writters, and maintain a 
more consistant compatability across platforms, but my focus is GNU/Linux.

 
> >Just because the codec supports it, doesn't mean that every
application which
> >uses the codec must support all the possibilities.  By making the data
> >definition generic we allow more re-used code (ie, for colorspace
converters)
> >and prevent the "raw codec" sprawl you above described with
FourCC codecs.
> 
>
> Well thats the thing about raw codecs, if you use the types that are 
> supported by hardware and/or other codecs, you don't have to do
anything
> except copy the memory.  When you start using things that no hardware 
> generates, or can display directly, that's when you have to write code
to
> convert.
Um, last I knew, video cards don't take YUV data as-is.  It's converted
on some
level, and it's not just an issue of decoding from the codec plugin and
throwing
it to the video hardware.

Furthermore, we aren't going to put artificial limitations on future video 
codecs based on current hardware or the limitations of obsolete software.  If a 
codec finds it useful to encode, say, super high definition interlaced video 
which encodes one chroma for every luma on every other line, such that one 
interlaced scan includes chroma and the next doesn't, then it should be able
to
decode to the same raw YUV spec as everyone else..

.. and if another codec supports that YUV layout, or hardware, etc then it 
should be able to, directly.  If it doesn't, the maker of that codec is
likely
to also write a deinterlacer plugin which also does the chroma resampling to 
4:4:4 (ie, copying the chroma to 2 scans), and everyone can use that.

This is roughly the same if the codec plugin couldn't export it's custom
format
by itself, but was forced to deinterlace and convert to 4:4:4 on decode, except 
that if the application DOES support it, it can use it directly.

I'm definetly leaning toward a nearly universal YUV format, myself.  I'm
seeing
no reason to do otherwise, and many, many advantages in the long run.  It hurts 
nothing if only a handful of configurations are actually used, after all.

> All i'm saying, is there are certain types that are defined, hardware
can
> display them, hardware like cameras generate them.
But that's the difference between Microsoft and Xiph.  They write things and
expect to write something new in 12-18 months to replace it, we write things 
with the intention that they be used more than 10 years in the future.

They write things with fixed values and artificial limitations, simply because 
it seems easier or it's easier for them to debug, where we write things 
open-ended and flexible such that we can continue to improve them over time.

They would do something as assinine as designing a special codec for every 
individual different format for raw data, with very little flexibility in each 
one, where we write one codec to cover all of them and much, much more.

If we wrote things like Microsoft does, we would be on Vorbis IX by now, not 
just beginning to talk about Vorbis II, and people would either have difficulty 
finding Vorbis I/II/III codec plugins or they'd be supplied in the Vorbis IX
codec plugin which would be several times the size it really needed to be.

:-)  

Thinking about this has certainly clarified my position on the different things 
we've talked about, and yea, I'm backtracking to the universal format,
because
it's what feels right for Xiph to do.  It doesn't matter if 95%+ of the 
different combinations never end up getting used, they are there if they're 
needed, and code for converter plugins can be more efficiently reused.

-- 

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

> This is of course assuming Windows will even end up using OggStream. 
It'd
> certainly reduce the workload of the DirectShow filter writters, and 
> maintain a
> more consistant compatability across platforms, but my focus is GNU/Linux.
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. And 
just like your focus is linux, mine is windows, and doing what makes sense 
for this implementation, and the people using it. And windows uses fourcc's,
whether that's a good or bad thing is relatively immaterial. That's what
it
uses, and i'm of the opinion that there's no reason to make things more 
difficult than they need to be just because of some philosophical 
difference. By all means do what's right for the platforms you care about, 
but just like you don't care about directshow, i don't particularly care
about linux.

I could write a fourcc based filter in about 45 minutes, and barely have to 
do anything, and it will work with all the formats it will encounter in 
directshow... and since they are directshow filters, that's all that really 
matters.

The other thing is, most applications will already know what to do with a 
specified fourcc. The code will already exist to deal with it. Far from 
saving code, you will actually be duplicating it.
> Furthermore, we aren't going to put artificial limitations on future
video
> codecs based on current hardware or the limitations of obsolete software. 
> If a
> codec finds it useful to encode, say, super high definition interlaced 
> video
> which encodes one chroma for every luma on every other line, such that one
> interlaced scan includes chroma and the next doesn't, then it should be
> able to
> decode to the same raw YUV spec as everyone else..
Just as being too narrow can be a problem, trying to be too broad is just as 
much a problem. At the end of the day, should such a format become used, and 
windows supports it, then directshow will support it, or directshow will be 
replaced... in which case the point is moot anyway. By exactly the same 
token, you have no idea what changes will happen in 10 years, so you really 
can't be sure you have future proofed anyway. So you are just increasing the
burden now, for an unknown payoff.
> I'm definetly leaning toward a nearly universal YUV format, myself. 
I'm
> seeing
> no reason to do otherwise, and many, many advantages in the long run.  It 
> hurts
> nothing if only a handful of configurations are actually used, after all.
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.
> They write things with fixed values and artificial limitations, simply 
> because
> it seems easier or it's easier for them to debug, where we write things
> open-ended and flexible such that we can continue to improve them over 
> time.
>
Those crazy people who actually place a value on their time. If it can be 
done easily... do it easily, no need to be a martyr and make life more 
difficult than it needs to be.

Zen.