ogg at illiminable.com
Tue Nov 8 20:28:07 PST 2005
> 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
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
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
> 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
> no reason to do otherwise, and many, many advantages in the long run. It
> 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
> 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
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.
More information about the ogg-dev