[FFmpeg-devel] donation for snow
Fri Nov 7 12:35:34 CET 2008
On Fri, Nov 07, 2008 at 02:19:00AM -0800, Jason Garrett-Glaser wrote:
> On Fri, Nov 7, 2008 at 2:09 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Wed, Nov 05, 2008 at 09:02:13AM +0100, Luca Abeni wrote:
> >> Hi Michael,
> >> Michael Niedermayer wrote:
> >> [...]
> >> > code lives or dies depending on developers pushing things forward or not,
> >> > and iam surely sad that noone is working on snow. Especially as there are
> >> > many possibilities and ideas of what and how it could be improved both
> >> > quality and speed wise.
> >> >
> >> > 3 things that hurted snows development surely where
> >> > * loosing the snow SOC project
> >> > * having motion estimation and ratecontrol actively developed in x264 but
> >> > none of the improvments merged back.
> >> > * very few people working on it ...
> >> >
> >> >
> >> > Basically in the end its either, I finish snow alone or it dies ...
> >> [...]
> >> Maybe, it would be useful to have a list of things which have to be done
> >> (listed in order of increasing difficulty, so that even not-so-skilled
> >> developers can help...).
> > cleanup and simplify these 2 are the most important in no
> > particular order.
> > Currently snow.c is too messy for people to easily jump onto it and
> > try different things it seems ...
> This is a problem all over ffmpeg I think... h264.c for example. Or
> the DSP mmx file.
yes, there are some very messy parts, parts of mmx, motion_est, parts of
mpegvideo. But then other parts are rather clean like the ratecontrol code
or some simple codecs like asv1/2, also mpeg1/2 ...
> IMO ffmpeg would be easier to jump into in general if it was split up
> a bit more; snow.c is really just a symptom of the underlying problem.
yes, but its not just litterally spliting up code into several files, this
alone would IMHO not help all that much. Its also fully documenting the
interfaces between these files so one can really work on a small part without
having to deal/understand alot of other code.
And like always the problem is the same, few are cleaning code up,
fixing the bug that annoys one or the latest feature like the new lossless
mode in h264 is just more sexy than (the actually easier) spliting and
documenting of code.
besides, spliting would also speed up compilation ...
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel