[FFmpeg-devel] GSoC 2008 Students Announced
Tue Apr 22 00:08:57 CEST 2008
On Mon, Apr 21, 2008 at 08:23:24PM +0000, Arpi wrote:
> " LGPL reimplementation of GPL sws_scale parts "
> heh? why dont Michael simply puts his code under LGPL?
> it's just wasting of programmer resources to reimplement it...
The C code which i wrote is under LGPL, the asm i wrote wont be rewritten.
What this is about is rewriting walkens code. Someone already tried it
but walken claimed copyright on the result so he got scared ...
The rule now is the student MUST NOT look at the code but just its
output and how its used from my code.
Also the task has a few more goals, heres the text from the wiki:
LGPL reimplementation of GPL sws_scale parts
*Clear separation of architecture specific code (asm) into separate
*Rewriting the GPL yuv table init code (without looking at the code
but just the code using the tables and the actually generated tables)
*All obvious simplifications & cleanups
*Ensure that the swscaler can be (optionally) run in a bitexact mode for
*Ensure that every conversion is (optionally) supported in a way which
does not subsample chroma more than the worse of input and output.
*Make the rgb->yuv and yuv->yuv code support the different yuv types
which are set via sws_setColorspaceDetails()
*Make sure all RGB input formats are (optionally) supported without being
converted to a intermediate 8bit per component YUV, that is they should
either be scaled in RGB space or scaled in >8bit per component YUV. (later
is easier in the current architecture)
*Make architecture specific code bitexact where this is possible without
speedloss and easy.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Opposition brings concord. Out of discord comes the fairest harmony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel