[gst-devel] colorspace conversion

[Ronald Bultje]

Hi Thomas,

On Tue, 17 Feb 2004, Thomas Vander Stichele wrote:
> I agree with all your points.  You are still, however, missing one -
> ffmpeg cannot be distributed by either GNOME (in source form) or by any
> distribution (in binary form).  We need our player to work, however few
> the formats it handles, from a distribution.

Hm... OK, you've got a point. I'd say that the same goes for
other parts of GStreamer or even GStreamer as whole, btw (mpeg2dec, divx,
some more), but anyway.

Source is fine. Read MPEG LA's license. Read patent licenses. It's really
a lame excuse; but source-only is a nice clause that we and GNOME can
abuse to distribute ffmpeg and more stuff in source form.

(In case your lawyer or anyone from the US government asks: I didn't say
that.)

That leaves distributions that want binaries. I'd say they can strip
ffmpeg just as they strip GStreamer (hey, ffmpeg even has compile-time
options for that!) and be fine with it. I'm sure RedHat or Sun lawyers
will disagree, but that's not our problem. What I've said above is
accurate and right, I'll just never defend it in front of a court, but
that's merely because (here it goes ;) ) I'm not a lawyer.

> > If you really want to, I wrote a bunch of CSP conv. routines which are in
> > a libcolorspace-related bug in GStreamer/GNOME bugzilla. You could use
> > that as a starting point. It includes patches for our LCS plugin to work
> > with it, too. You need those two patches, latest LCS CVS (from codecs.org)
> > and some more.
> >
> > Bad things:
> > * it's slow
> > * I think RGB on LE is inverted because I misinterpreted masks by then. I
> > never bothered to fix this.
> > * no optimizations whatsoever, and it'll probably require some slight
> > changes to use liboil or so to do this (Dave?)
> >
> > Good things:
> > * it handles very many formats already (any RGB format, plus +/- 5 YUV
> > formats) ecause it's very generic
> > * it's easily extendable
>
> Any chance we could get you to finish your work on that ? :)

Hm... I remember Dave saying he'd never seen anything this slow. I pobably
can, but need to learn to have "more efficient" code. If I can do that, I
might. I still think it's not necessarily a good thing, though. ffmpeg is
so much faster and I'll always use ffmpeg anyway. So the end question for
me is: why would I?

Question for Dave: could you apply the patch to codecs.org CVS (yes it
sucks, don't tell me, but just do it), integrate liboil into it, notify
me so I can try to optimize the C code slightly (I've got some ideas here,
don't worry) etc.? Are you interested in this? Optimization ideas:

* pre-calc RGB masks instead of re-calculating them per cycle
* the RGB-to-YUV pixel conv. stuff can probably be improved (it sucks)
* I worked on some YUV-format-specific conversion routines but quitted
that halfway. I'm very sure they can be improved and extended.

End thing is that I've got support for theoretically any YUV and RGB
though fallback functions and want format-specific functions for speed.
We can probably use some ideas from ffmpeg here if you want. I'm not
saying I'll spend time on this, but I might...

And again Thomas: given that source-distribution is fine: what's in it for
us? This question is important for me. ;).

Ronald