> Well, since I'm using this function f=FCr VideoThumbnails, I will cry
> right away :)
I KNEW that this would happen :)
> However, what library would be the recommended one if I'd like to have
> scaling and color-conversion?
I personally use gavl (http://gmerlin.sf.net/gavl.html),
which was written by me. For me, it has the big advantage, that
I can add missing features myself :-)
Right now, it doesn't support all (quite exotic) colorspaces from
libquicktime (e.g. I support 32 bit RGBA but no 32 bit ARGB).
The advantages are however, the following:
- Different architecture, which doesn't just have one HUGE conversion
function (like libquicktime) but conversion contexts which must be
initialized in the beginning and cleaned up after. They do, however
simplify the sourcecode dramatically and improve conversion speed.
- Generic interface for selecting among different algorithms (e.g. for
scaling) and quality levels.
- Support for Video- AND Audio conversions.
- A little known fact is, that libquicktime doesn't have ALL possible
conversions (which are n*(n-1) for n different colorspaces minus the =
redundant ones like RGB->BGR and BGR->RGB). So it can happen, that using
some less standard colormodel will end up with a black picture, when no
function is available. Using gavl, it is garantueed, that all conversio=
Other colorspace conversion routines can be found in the sourcecodes for
MPlayer, ffmpeg or xine.
> BTW. I'm do not understand much of this colorspace conversion stuff, bu=
> does this mean that it'd no longer be possible to get RGB Frames out of
> I think that this would be a serious drawback, because it would mean a
> much bigger hurdle for programmers new to libquicktime. At least for me
> libquicktime was the best thing to get some videostuff done, and worry
> about the details later.
That's serious issue.
So my idea is the following: Some little API extensions should allow us
to get ALL information about the colorspace details (e.g. Chroma spacing,
field order), so we are ready for High end applications.
The function quicktime_decode_scaled() will stay there, but the
documentation will STRONLGY recommend not to use it (instead, I would
recommend gavl at least for GPL applications, gavl cannot be LGPL).
The current colorspace converter will, from my point of view, stay as it
is. If someone wants to improve it, he/she can do it.
Would that be a compromise?