[FFmpeg-devel] Cleanup libswscale and reimplement GPL code under LGPL

[Michael Niedermayer]

On Mon, Apr 07, 2008 at 09:27:06PM +0200, Luca Barbato wrote:
> Michael Niedermayer wrote:
> > yes, but IMHO that is a little weak for a whole summer ...
> 
> Originally it was about having a CELL scaler in, then I found out that 
> there was already an unmentored task about reshaping swscale and I took 
> it in the hope of having both going this summer (reshape swscale -> 
> implement SPU routines for it).
> 
> I have pretty much an idea on how much time will take getting both tasks 
> done depending on the starting knowledge. The swscale reshaping one is 
> mostly an exercise of patience while trying to make sense out of that 
> mess, 

No, its rather understanding what the code does and how it could be better
structured without loosing features or performance. Patience is a factor but
having some brain is as well. Its not as if the "mess" was trivial to
restructure into a cleaner system. Also its not just reshaping but there are
a few TODOs in sws which should be implemented as well.

Of course people love calling code they dont understand at all "mess" and
starting big rewrites. When they are done they tend to realize that they
lost half of the features, half of the speed and ended up with twice as
messy code. Of course there are exceptions who dont realize these things.
A good sign of above is that people cant explain how the original code
works, cant point at concrete problems or concrete solutions.


> programming cell requires some knowledge that you usually don't 
> have already and some good ideas on how to do (and probably some 
> try-benchmark-tryagain loops), so both could be quite time consuming.

I think someone who has never written code for XYZ or a similar architecture
is not a good choice to optimize code for XYZ. CELL or not ...
I wouldnt want someone who never wrote X86 asm do X86 optimizations either.
The result would be hard work for the student and a heap of trash for
us which someone would have to rewrite later.
Of course if your only goal is to be able to say "we have CELL optimizations"
then thats different ...
Or short summary, IMHO ffmpeg GSOC is not for someone to learn how to do
CELL optimizations.


> 
> If you don't care about reimplementing the gpl bits probably they could 
> be merged back but then I'm not sure who will be up for this task.

I doubt anyone of the students has the X86 optims knowledge to reimplement
the SIMD code in the swscaler especially not within the summer. If we had
some x86 guru amongth the students sure he could but i think we dont and
if we had one there are much more interresting targets than rewriting code
due to its license.
Also amongth the "mess" is a X86 code generator generating optimal
instruction sequences for the horizontal rescaling depending on src/dst
width.


Cleaning up swscale is surely welcome and could be (part of) a GSOC project,
Iam not against this at all ...
if we have some concrete ideas/list of what should be cleaned up and how.
Simply sidestepping and saying "make sense out of the mess and reshape it"
is not enough IMHO.
Some examples would be:
* Fix the RGB->YUV code so it considers the exact YUV type
* Ensure that every convertion is available in a high quality variant
  which doesnt subsample chroma beyond the worse of src/dst

Also this is about very well split patches doing small cleanups step by
step, NOT a "rewrite the core and put the optims back in place". Because
even if you dont belive it the core is not at all trivial to rewrite.
And the result of such a rewrite would be likely worse than what we have
now.

Writig CELL optims can as well be (part of) a gsoc project if we have some
student with experience in
CELL/SPU or similar architecture optimizations. But i think we do not.
And i dont want to have someones first excercise at CELL optims at the
end of the summer.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080408/05cec140/attachment.pgp>