[ogg-dev] OggYUV

[illiminable]

> 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.