GNOME Bugzilla – Bug 117897
New colorspace stuff
Last modified: 2004-12-22 21:47:04 UTC
This actually belongs to LCS @ codecs.org, but since I'd rather keep it centralized (here), I'll put it here. I've got a new colorspace system, any-to-any, based on a generic set of methods. Code is attached, please give some comments (Dave? Wim? Erik?). Problem is that I don't know how to add it to the generic system in LCS. Also, because of this, I haven't been able to test it, so there's likely some huge, humiliating, sad, horrible etc. bugs in it. I'd like to test these against the two- or three-step LCS functions (e.g. RGB xx to YUY2, YUY2 to any YUV type or so) to see which is faster. I'm guessing mine is faster (and it also takes less memory since you're omitting one step), but I want to be sure before we start using this. The general idea is that this is the fallback system and that - for the normal functions (RGB32/24-to-YUY2, any YUV422packed to each other, any YUV420planar to each other, etc.), we write optimized ones that replace the fallback one. I.o.w., comments please!
Created attachment 18454 [details] any-to-any colorspace methods
Now that I'm doing this anyway, here's some C-optimized YUV420planar functions and some C-optimized YUV422packed functions. They basically convert within either YUY2/UYVY/YVYU (using a DWORD approach) or within I420/YV12 (using memcpy-per-line). LCS doesn't have this yet.
Created attachment 18459 [details] yuv420planar
Created attachment 18460 [details] yuv422packed
Created attachment 18522 [details] [review] Patch which adds the above files to the build and registers the types
Created attachment 18856 [details] LCS tarball after my changes
Created attachment 18857 [details] [review] GStreamer LCS plugin patch for my changes to LCS
The above are a new LCS tarball and a patch to the GStreamer LCS plugin to behave like I want them to. There's nothing new in there, except a terribly slow fallback thing, that can barely do 25fps on my P-II 400. I'm assuming it can be further optimized, but it's good enough as a fallback. Most people have something better than a P-II 400 anyway (still good to use this, makes you write fast code). Interested people, please test. Oh, for Wim: the kernels haven't been backported in here, since the format names are duplicated. This is probably a minor issue, but I'm waiting for some general comments before putting the kernels back. And the code in lcs/{yuv,rgb}2{yuv,rgb}/* is now being used, too.
Oh, I forgot, there's one issue with RGB: the bytes aren't written in the right order in my fallback thing. However, I'm fairly sure that my byte-write code is correct. Anyone with some knowledge for endianness/RGB, please have a look and correct my stupidness.
Notes about the lcs code (imcomplete, made abuot a week ago) lcsarch.h: - defines should be in parens lcsfallback.c: - unsigned long long sucks as a type, use uint64_t - lcs_fallback_rgb_pixel_resample_component(): should multiply by 0x1001 (or whatever) instead of dividing. - this is the slowest code I've ever seen :) general: - IMO, clipping to [16,235]x[16,240]x[16,240] should be done 3-dimensionally. - magic constants for CCIR 601 -> RGB conversion should be defines - make it possible to subclass LCSConverter, so that the individual converters can cache information (or have a ->priv member)
Applied to both gstreamer CVS and codecs.org CVS. Seems to somewhat work.