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

[Luca Barbato]

Michael Niedermayer wrote:
> 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.

As you can see from my todolist for this task I'd require first to 
figure out what does what and document it, then cleanup.

> 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 ...

The summer of code is for learning, not just doing. We come up with 
interesting tasks and as result we got students knowing something new 
and ffmpeg with some interesting piece of code none of us had the time 
or will to come up with.

> 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.

You know what I think about x86.

> Of course if your only goal is to be able to say "we have CELL optimizations"
> then thats different ...

Some is better than nothing, and just having the basic structure for 
heterogeneous cores in place would be good.

> Or short summary, IMHO ffmpeg GSOC is not for someone to learn how to do
> CELL optimizations.

hmm

> Cleaning up swscale is surely welcome and could be (part of) a GSOC project,
> Iam not against this at all ...

Good =)

> 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.

 From the wiki:

# Document the current code
# Refactor the code
     * Make the functions take less parameters (move some in proper data 
structures)
     * Make the optimized implementations build like dsputils (separate 
dir per arch)

> 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.

I trust in your wisdom ^^

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero