[FFmpeg-devel] donation for snow

Michael Niedermayer michaelni
Tue Nov 4 20:24:38 CET 2008


On Tue, Nov 04, 2008 at 06:59:42PM +0100, Lars T?uber wrote:
> Hi there!
> 
> I was one of the FFmpeg supporters who wanted to donate some money for the completion of the snow codec.
> Since the additional info was put on the web site no one was interested. At least on the devel list and on my private mail account no one had evinced any interest in doing it.
> 
> I'm thinking of withdrawing my donation.
> If there is someone interested in doing it and contacting the list or me privately and promises the completion in a foreseeable future I would think about raising the fund once more. Otherwise I will withdraw my donation in December.
> 
> I'll be sorry to do this but it seems snow will die before beeing born.

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 ...
In that respect the question is what does "finishing it" mean actually?
Is the goal to have a codec that is better than x264? Or should we follow
xiph and pretend that our codec is patent free even though we dont really
know.
Ive no doubt that snow could beat x264 given a few determined and smart
developers, thats especially as x264 is limited by the h264 spec while snow
is not, i also have no doubt i could write a h264 encoder that beats
x264 quality/bitrate. Though especially in the later case trying that would
make me a NIH-infected idiot, the amount of time spend on (re)writing a FOSS
H264 encoder beating x264 would be much larger than contributing the
improvments to x264 (that is had i the motivation and time to work on h264
encoding).

Now theres not just snow, but theres are other attempts to write free video
codecs. What is missing is some effort to work together ...
Thats especially noticeable when one looks at H264 designed by the JVT which
is made of ITU VCEG and ISO MPEG, its funny but they definitly managed to
unify their forces much better than the FOSS people who ended up with tarkin
theora, dirac, snow, ...

I think that doing what the JVT had done would be the most likely successfull
path. In addition to what they did (and that is the reason why theres any
sense to "duplicate" the effort) it should be required to avoid anything that
is known to be patented unless the patent owners license their patent for free
to every user of the codec. And the codec should be kept as simple as
possible, not having 2 seperate entropy coders (CAVLC/CABAC) supporting 2
variants for interlacing, 3 variants of coding a few bits in the header, and
a dozen different timestamps/frame numbers/ picture order counts.

Also similar to the JVT each change to the codec would have to be carefully
tested in terms of quality/bitrate/speed. In this respect we would need some
guidline that says what percentage of slowdown is ok for what amount of PSNR
gain. The actual decissions of what to accept would inevitable be done by
voting or consensus.

Of course such a effort also like finishing snow depends on people actually
contributing/working/"doing viewing tests".
Is there any interrest in doing something like that?

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- 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/20081104/a1b9d416/attachment.pgp>



More information about the ffmpeg-devel mailing list