[Gstreamer-bugs] [Bug 117897] New - New colorspace stuff

[<bug...@wi...>]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=117897

Changed by rb...@ro....

--- shadow/117897	Sun Jul 20 10:13:02 2003
+++ shadow/117897.tmp.21750	Sun Jul 20 10:13:02 2003
@@ -0,0 +1,37 @@
+Bug#: 117897
+Product: GStreamer
+Version: HEAD CVS
+OS: All
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: enhancement
+Priority: Normal
+Component: don't know
+AssignedTo: rb...@ro...                            
+ReportedBy: rb...@ro...               
+QAContact: gst...@bu...
+TargetMilestone: HEAD
+URL: 
+Summary: New colorspace stuff
+
+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!