[FFmpeg-devel] donation for snow

[Michael Niedermayer]

On Tue, Nov 04, 2008 at 11:38:34AM -0800, Jason Garrett-Glaser wrote:
> On Tue, Nov 4, 2008 at 11:24 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > * having motion estimation and ratecontrol actively developed in x264 but
> >  none of the improvments merged back.
> Motion estimation in Snow is still more advanced than x264 in some
> respect; Snow has iterative ME, x264 doesn't.

yes but iterative ME is slow and some say, being too slow ...


> > 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.
> >From the little I know about snow, I'm pretty sure it violates patents
> left and right (median MV pred, same tapfilter coeffs as H.264, etc)

the tapfilter coeffs are stored in the file thus if that violates a patent
then that would implicate any filter does which i highly doubt due to prior
art.
Also the reason for using the same coeffs by default is that they are the
best, ive tested all of similar magnitude IIRC.
and the median is trivial to replace by something else ...
that said iam not disputing that it might violate patents left and right,
ive not tried to check the code against patents ...


> > Ive no doubt that snow could beat x264 given a few determined and smart
> > developers
> I highly, highly doubt this, assuming you stick to the basic current
> idea of Snow.  I don't doubt that you or I could make a better format
> than H.264 if I tried--there are dozens of places one could make
> improvements--but what I do doubt is the ability to make a better
> format *using overlapped wavelet*, since thousands of people have
> tried that for something on the order of two decades and failed
> miserably.  

I had no intent to stick to wavelets once someting else had been implemented
that work better, actually i was aware that existing wavelets with existing
ntropy coders perform poorly on inter frames before even writing the wavelet
code.


> And if its not overlapped-block wavelet, it really just
> isn't Snow.

This really isnt true, ive planed to try different transforms from the early
begin, i just didnt do it yet ...



> > 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?
> Well, making a new format requires a lot of work.  It'd be far easier
> to just base the format off of H.264.  Remove sub-8x8 partitions,
> remove interlacing, remove CAVLC, add a few thousands more contexts,
> replace the DCT with an 8x8 hierarchical lapped transform, allow a
> delta-quant syntax element per transform, etc, etc...

And thats what i just suggested in my follow up mail, seems we are actually
thinking of the same, at least partially ...


> 
> If you actually want something patent-free that doesn't suck, give up
> now, its a fruitless pursuit.

Nah, this is exagerating and mising my point a little.
I am not trying to suggest that some "guranteed to be patent free" format
is created, that surely is futile. But rather a "free from known patents"
that doesnt totally suck like what exists now.
And h264 may be not such a bad base for that considering the existing code.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates
-------------- 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/a057387c/attachment.pgp>