Snow wavelet codec

[iwod]

What were the bitrate done on RMvb?

[Liisachan]

avarage bitrate is (about) the same for each codec tested. as you can see, the resulted files (http://www.faireal.org/tmp/codec_test/) have the same size.

[Yong]

@Liisachan:
snow encoding with obmc really (unbearable :D )slow,
but im not sure celtic_druid already include this patch http://students.washington.edu/lorenm/src/x264/snow_obme_sse2.tar.gz
this patch might be help encoding speed with amd64 or p4 machine.(?)
My build had this patch included, but it still slow :p ...

[celtic_druid]

Nope. Not included in my ffmpeg/mencoder builds.

[CREXbzh]

Nope. Not included in my ffmpeg/mencoder builds.
It will eventually be committed in several days or weeks. You can follow the discussion here: http://mplayerhq.hu/pipermail/ffmpeg-devel/2006-March/thread.html#8625

[Tommy Carrot]

I did quick tests with mplayer that celtic_druid compiled yesterday.
(1) OBMC (vme=8) may or may not help. If I'm not wrong, some resulted frames are pixel-identical even with or without OBMC. I need to do more testing.
The new iterative ME is definitely better, especially at low bitrates. I made 2 samples to show the difference, with the old (http://carrotland.uw.hu/snow_q10.avi) and the new (http://carrotland.uw.hu/snow_q10_obme.avi) ME algorithm. The improvement in motion accuracy is obvious.

In my experience the new ME works best with SATD cmp functions (xxxcmp=2), sometimes SSE method (xxxcmp=1) causes strange twirling effects and chroma artifacts. Also, v4mv is still harms the quality more than it helps, it's not a good idea to use it yet.

[bratao]

i geting better fast !!
5 months ago i do a encode at ~1fps and the output has a bad quality output, the xvid has far superior..

But today i do a encode at solid 4 fps (remember i have a slow processator, an 1.6 p4 with 133 sdram) and very good quality ! imho far better than xvid/divx and comparable with some fast x264 encodes..

And look at source , it easy to see that it at a very alpha stage , with a very unoptimized code..
It had a Very big potential !!
Keep on the good work !

[celtic_druid]

"Informer you no say daddy me Snow me I'll go blame
A licky boom boom down"

Cool name to.

[ods15]

And look at source , it easy to see that it at a very alpha stage , with a very unoptimized code..
It had a Very big potential !!


The encoder could still get some optimiaztions, though not many. The decoder is fully optimized in C code, and there are pending patches for mmx, which help up to 50% in best case scenario (for decoding), and that's about it. With a P4 2.4ghz I can play a high quality 944x544 smoothly, that's about the maximum. I'm working on adding slicing support to Snow, which could help in some cache restricted situations, but I'm generally pessimistic on Snow speed. It has only one big advantage of H.264 in regards to speed - if you have an HDTV res snow video, you can decode it at half res (or even forth), and reduce cpu usage by a 1/4th (or 1/16th), which makes it quite nice...

- ods15

[Liisachan]

@Tommy Carrot
thank you for posting them. I'd like to run my own tests too, but you are right. The improvement is easily noticeable in you clips (for example in the sky)

I don't care about encoding speed much, especially when it's still in alpha or beta. 1 fps is fast enough for me. VSFilter is often < 1fps when subbing complicated effects anyway, even tho the codec is fast.

[MfA]

Ods15, just curious (and lazy) do you have a breakdown on where a recent version of the decoder spents all its time?

[akupenguin]

The decoder is fully optimized in C code, and there are pending patches for mmx, which help up to 50% in best case scenario (for decoding), and that's about it.
That's not the limit or anything, that's just what the pending patch gives. While I don't believe dalias's claims of OBMC as fast as conventional MC, I do know how to make it algorithmically faster than it is now. And that applies to both encoder and decoder.

[pest]

@akupenguin

is an iterative obmc really worth the time?
why not use a simple obmc as in h263+ and
more variable blocksizes (8x8,8x16,16x8,16x16)?
why not write the rangecoder in asm, this would
give the most speed improvements.

[akupenguin]

It's not "iterative obmc". It's "iterative obme".
The decoder performs Overlapped Block Motion Compensation. This is not iterative, and only slightly more complex than h263's.
The encoder performs Overlapped Block Motion Estimation, which can be as slow/complex as you want. h263 would benefit from iterative obme too, if anyone bothered to write it.

Snow does not effectively use the block sizes it has, so we need to work out heuristics for that before we tackle even more.

What makes you think you (i.e. I) can write rangecoder asm better than gcc? Asm is needed because compilers can't effectively use SIMD operations. Scalar math and scheduling is much better studied.

[pest]

sorry about the difference,
i only wanted to say that BME and a OBMC as simple
as h263+ could fit the purpose. that's the same as you explained.


Snow does not effectively use the block sizes it has, so we need to work out heuristics for that before we tackle even more.


using more blocksizes could slow down the iterative me really.
that's why i asked if it makes any important improvements
over BME.


What makes you think you (i.e. I) can write rangecoder asm better than gcc? Asm is needed because compilers can't effectively use SIMD operations. Scalar math and scheduling is much better studied.

the speedup is not as huge as exploiting SIMD operations
but there is some. you could process the subband
data in blocks to further parallel the entropy encoder
until the rangecoder level.

[akupenguin]

The entropy encoder is a trivial fraction of the total encode time. There's no point in asming it.
And there's no parallelism possible in the entropy decoder.

[pest]

in my tests entropy-encoding/decoding takes the most time
but it just could be that :stupid: , we'll see ;)

[CREXbzh]

in my tests entropy-encoding/decoding takes the most time
but it just could be that :stupid: , we'll see ;)
It probably means that you should be careful when you interpret the results of your profiler. You may want to re-try with oprofile for example.

[pest]

the conclusions i draw are from my wavelet-codec
it's somehow different than snow. i thought the same
rules apply to snow but this is apparently not the case.

[CREXbzh]

Oded Shimon has further optimized snow decoding (an maybe encoding also). The patch is available here: http://tuxrip.free.fr/transperl/MPlayer/snow_mmx.patch

[Yong]

Oded Shimon has further optimized snow decoding (an maybe encoding also). The patch is available here: http://tuxrip.free.fr/transperl/MPlayer/snow_mmx.patch
Thanks for the link ;)
Just tested the normal version againts patched version, with 640x480 @ 30 fps, 650 frames,
patched version give 70 fps decoding in benchmark
unpatched is 37 fps
Wow :D

EDIT: unfortunatly the encoding speed(vme8) still same slow as unpatched version...

[DarkFoon]

I want to thank all of the developers/testers/etc. who work on the Snow codec. Though a bumpy road it's been, I believe that Snow has potential.
I want to use a high quality codec for all my TV captures that isn't patent encumbered, and I believe that Snow will be that codec. Xvid isn't high enough quality for me, H.264 is patented (I use x.264 currently, but I don't like the feeling that I'm supporting a big corp). And the Ogg wavelet codec, tarkin, is no longer developed.
So, thank's guys (and ladies, where applicable) and keep up the good work!

[akupenguin]

There are encoding optimizations pending too, but that will come after this patch is finalized. It's huge enough already.

[Liisachan]

snow.c Revision 1.91 (http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/ffmpeg/libavcodec/snow.c?rev=1.91&content-type=text/x-cvsweb-markup&cvsroot=FFMpeg&sortby=date) Mon Mar 13 01:27:13 2006 UTC
"seed iterative_me with mvs from conventional search.
+15% speed, +.1 dB"

by courtesy of celtic_druid:
http://ffdshow.faireal.net/mirror/mplayer/

[celtic_druid]

Guess I should update the ffmpeg build to.

[Liisachan]

the above sample, the same settings.
640x376@23.976fps [YV12] 2577f
P4 3.4GHz


2nd pass
+---------------------+-------------+------------+
| MEncoder dev-CVS- | vme=4 | vme=8 |
+---------------------+-------------+------------+
| 060306-21:51-4.0.2 | 12.76fps | 1.74fps |
+---------------------+-------------+------------+
| 060316-21:45-4.0.2 | 12.80fps | 2.02fps |
+---------------------+-------------+------------+

:D

[celtic_druid]

Should point out that the P4 build from the 6th has SSE/SSE2 enabled where as the one from the 16th doesn't.

[Liisachan]

MEncoder dev-CVS-060306-21:51-4.0.2 (C) 2000-2006 MPlayer Team
CPUflags: Type: 15 MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2

MEncoder dev-CVS-060316-21:45-4.0.2 (C) 2000-2006 MPlayer Team
CPUflags: Type: 15 MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 0 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2


0 means "not optimized for SSE/SSE2"? in short, this could be even faster?

[Yong]

A first part of speed-enhancing patches just summited to ffmpeg 84mins ago :)
http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/ffmpeg/libavcodec/?cvsroot=FFMpeg&sortby=date#dirlist

[CREXbzh]

A first part of speed-enhancing patches just summited to ffmpeg 84mins ago :)
http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/ffmpeg/libavcodec/?cvsroot=FFMpeg&sortby=date#dirlist
Note: this part doesn't yet feature any speed enhancement. It just prepares the ground for them.
The idea being to split the changes in small enough parts so that they can be reviewed and understood easily.

[Sirber]

0 means "not optimized for SSE/SSE2"? in short, this could be even faster?not optimized for 3DNow, SSE is fine

[akupenguin]

Should point out that the P4 build from the 6th has SSE/SSE2 enabled where as the one from the 16th doesn't.
The pending patches will add SSE2 stuff, but there isn't any yet so you didn't lose anything in that test.

[Liisachan]

Iterative Motion Estimation is obviously effective in a high-motion scene, or when the bitrate is not sufficient.

The same part of the same frame, 200%

Input
http://www.faireal.org/tmp/codec_test/204huff.png

vme=4
http://www.faireal.org/tmp/codec_test/204vme4.png

vme=8
http://www.faireal.org/tmp/codec_test/204vme8.png


mencoder "input.avs" -ovc lavc -passlogfile "pass.log" -lavcopts vcodec=snow:vstrict=-2:vpass=1:vqscale=3.0:lmin=1:pred=1:cmp=257:subcmp=257:mbcmp=257:qpel:v4mv -of avi -ffourcc SNOW -o 1st.avi

mencoder "input.avs" -ovc lavc -passlogfile "pass.log" -lavcopts vcodec=snow:vstrict=-2:vpass=2:vme=<4|8>:vbitrate=1150:lmin=1:pred=1:cmp=257:subcmp=257:mbcmp=257:qpel:v4mv -of avi -ffourcc SNOW -o <snow257.avi|snow257obme.avi>

snow257.avi (http://www.faireal.org/tmp/codec_test/snow257.avi) 5.4MB
snow257obme.avi (http://www.faireal.org/tmp/codec_test/snow257obme.avi) 5.4MB


vme=8 always works in various settings...
http://img101.imageshack.us/img101/6616/snowdemo5xj.th.png (http://img101.imageshack.us/my.php?image=snowdemo5xj.png)

[bratao]

Wonderful quality image in snow257obme.avi .
Perfect and liquid decoding until get in 8 seconds, at that point crash my ffdshow 2.2.2006.

I´m cant wait for this speed patches, to see the results.
Witout this pacthes, snow already only 7 times slower than xvid in this premature stage.

[Liisachan]

You might want to try mplayer (http://ffdshow.faireal.net/mirror/mplayer/)

(commandline) mplayer snow257obme.avi

maybe MPlayer is less cpu intensive. milan's ffdshow (http://ffdshow.faireal.net/mirror/Misc%20(not%20by%20celtic_druid)/milan/) 2005-11-15 works fine for me too.

[celtic_druid]

ffdshow works fine here... current cvs build.

[hellfred]

Hi folks
It is time for benchmaring snwo once more. The second patch of the mmx + sse2 acceleration of snow by Robert Edele has been committed to libavcoded cvs rep. This patch actually contains assembler code for speeding up encoding with snow.
See http://mplayerhq.hu/pipermail/ffmpeg-devel/2006-March/009245.html
Sorry for not being able to privide some numbers myself.

Hellfred

[CREXbzh]

This patch actually contains assembler code for speeding up encoding with snow.
See http://mplayerhq.hu/pipermail/ffmpeg-devel/2006-March/009245.html
Sorry for not being able to privide some numbers myself.

No it still doesn't contain any asm. It just changes a few things in the C code so that the next patch will be simpler.

No visual benchmark needed then, though it's possible that the speed of the current C code is affected by that patch, so it could be interesting to see if there aren't any regressions. I doubt that it's measurable in fps though if there's any regression. You'd need to use hardware counters to have a precise measure.

WJMP

[hellfred]

No it still doesn't contain any asm. It just changes a few things in the C code so that the next patch will be simpler.WJMP
Oh, you are right. I had hoped that all preparations for an easy inclusion of the asm code were done in the first patch already.:o
So my hope for improvement of the snow coded mislead me here. I beg your pardon.

Hellfred

The third part of the patch, including the asm code for the function ff_snow_vertical_compose(), was just placed on the ffmpeg mailing list. Let's see how long it will take to be reviewed and comitted.
See here (http://mplayerhq.hu/pipermail/ffmpeg-devel/2006-March/009297.html).

EDIT: Info about patch part 3

[CREXbzh]

The third part of the patch, including the asm code for the function ff_snow_vertical_compose(), was just placed on the ffmpeg mailing list. Let's see how long it will take to be reviewed and comitted.
See here (http://mplayerhq.hu/pipermail/ffmpeg-devel/2006-March/009297.html).

EDIT: Info about patch part 3

Done! ;-) Knock yourself out!

[Liisachan]

fps-wise only slightly, or maybe in the margin of erros:
0.98fps @ MPlayer dev-CVS-060316-21:45-4.0.2
1.00fps @ MPlayer dev-CVS-060321-16:16-4.0.2

the 2nd pass of vme=8:cmp=257:qpel:v4mv

[celtic_druid]

Well I just got:
1.61fps for the 21st
1.64fps for the 16th

[CREXbzh]

fps-wise only slightly, or maybe in the margin of erros:
0.98fps @ MPlayer dev-CVS-060316-21:45-4.0.2
1.00fps @ MPlayer dev-CVS-060321-16:16-4.0.2

the 2nd pass of vme=8:cmp=257:qpel:v4mv

That's to be expected: the patch is mainly to speed-up decoding routines.

[Liisachan]

Tested "mplayer snow.avi" a few times, and the difference was not clear on my Windows 2000. P4. Perhaps the avarage cpu load is less. The peak CPU load is always higher with the 21st build. Maybe because I'm always testing extreme options like vme 8 qpel and the speed-up is for more normal part?

[CREXbzh]

Tested "mplayer snow.avi" a few times, and the difference was not clear on my Windows 2000. P4. Perhaps the avarage cpu load is less. The peak CPU load is always higher with the 21st build. Maybe because I'm always testing extreme options like vme 8 qpel and the speed-up is for more normal part?

Don't know... You should run several times:

mplayer -vo null -nosound -benchmark snow.avi

That would give you smth like:

BENCHMARKs: VC: 24.293s VO: 0.005s A: 0.000s Sys: 0.126s = 24.423s
BENCHMARK%: VC: 99.4644% VO: 0.0213% A: 0.0000% Sys: 0.5143% = 100.0000%

Which tells you how much time was spent on the VideoCodec.
Experience shows that the optimizations give a larger speed-up on small resolutions, or that they work better one CPU with a large L1 cache (which is not the case of the P4).

[Liisachan]

2006-03-16
24.570s
24.440s
24.443s

2006-03-21
25.565s
25.547s
25.595s




MPlayer dev-CVS-060316-21:45-4.0.2
BENCHMARKs: VC: 24.570s VO: 0.002s A: 0.000s Sys: 0.217s = 24.789s
BENCHMARK%: VC: 99.1165% VO: 0.0081% A: 0.0000% Sys: 0.8754% = 100.0000%

BENCHMARKs: VC: 24.440s VO: 0.001s A: 0.000s Sys: 0.224s = 24.665s
BENCHMARK%: VC: 99.0878% VO: 0.0041% A: 0.0000% Sys: 0.9082% = 100.0000%

BENCHMARKs: VC: 24.443s VO: 0.001s A: 0.000s Sys: 0.207s = 24.651s
BENCHMARK%: VC: 99.1562% VO: 0.0041% A: 0.0000% Sys: 0.8397% = 100.0000%

MPlayer dev-CVS-060321-16:16-4.0.2
BENCHMARKs: VC: 25.565s VO: 0.005s A: 0.000s Sys: 0.190s = 25.760s
BENCHMARK%: VC: 99.2430% VO: 0.0194% A: 0.0000% Sys: 0.7376% = 100.0000%

BENCHMARKs: VC: 25.547s VO: 0.000s A: 0.000s Sys: 0.209s = 25.756s
BENCHMARK%: VC: 99.1885% VO: 0.0000% A: 0.0000% Sys: 0.8115% = 100.0000%

BENCHMARKs: VC: 25.595s VO: 0.001s A: 0.000s Sys: 0.186s = 25.782s
BENCHMARK%: VC: 99.2747% VO: 0.0039% A: 0.0000% Sys: 0.7214% = 100.0000%

[CREXbzh]

MPlayer dev-CVS-060316-21:45-4.0.2
BENCHMARKs: VC: 24.570s VO: 0.002s A: 0.000s Sys: 0.217s = 24.789s
BENCHMARK%: VC: 99.1165% VO: 0.0081% A: 0.0000% Sys: 0.8754% = 100.0000%

BENCHMARKs: VC: 24.440s VO: 0.001s A: 0.000s Sys: 0.224s = 24.665s
BENCHMARK%: VC: 99.0878% VO: 0.0041% A: 0.0000% Sys: 0.9082% = 100.0000%

BENCHMARKs: VC: 24.443s VO: 0.001s A: 0.000s Sys: 0.207s = 24.651s
BENCHMARK%: VC: 99.1562% VO: 0.0041% A: 0.0000% Sys: 0.8397% = 100.0000%

MPlayer dev-CVS-060321-16:16-4.0.2
BENCHMARKs: VC: 25.565s VO: 0.005s A: 0.000s Sys: 0.190s = 25.760s
BENCHMARK%: VC: 99.2430% VO: 0.0194% A: 0.0000% Sys: 0.7376% = 100.0000%

BENCHMARKs: VC: 25.547s VO: 0.000s A: 0.000s Sys: 0.209s = 25.756s
BENCHMARK%: VC: 99.1885% VO: 0.0000% A: 0.0000% Sys: 0.8115% = 100.0000%

BENCHMARKs: VC: 25.595s VO: 0.001s A: 0.000s Sys: 0.186s = 25.782s
BENCHMARK%: VC: 99.2747% VO: 0.0039% A: 0.0000% Sys: 0.7214% = 100.0000%


I can't help but suspect that there must be smth broken on the build you're using. You should either experience no speed-up (with huge resolution maybe) or a pretty sensible speed-up.

What resolution are you testing it with? Is it a multiple of 16?

Anyway, last patch got just applied...

[Liisachan]

yes 640x480, = 0 mod 16.
the binary (mplayer) I'm using is compiled by celtic_druid as usual.

I can't help but suspect that there must be smth broken on the build you're using. Maybe. It's an experimental build after all.

[Liisachan]

~4% faster now :D

2006-03-16
24.570s
24.440s
24.443s

2006-03-21
25.565s
25.547s
25.595s

2006-03-23
23.543s
23.504s
23.496s

MPlayer dev-CVS-060323-00:54-4.0.2

BENCHMARKs: VC: 23.543s VO: 0.002s A: 0.000s Sys: 0.211s = 23.756s
BENCHMARK%: VC: 99.1034% VO: 0.0084% A: 0.0000% Sys: 0.8882% = 100.0000%

BENCHMARKs: VC: 23.504s VO: 0.000s A: 0.000s Sys: 0.240s = 23.744s
BENCHMARK%: VC: 98.9892% VO: 0.0000% A: 0.0000% Sys: 1.0108% = 100.0000%

BENCHMARKs: VC: 23.496s VO: 0.001s A: 0.000s Sys: 0.247s = 23.744s
BENCHMARK%: VC: 98.9555% VO: 0.0042% A: 0.0000% Sys: 1.0403% = 100.0000%

[Yong]

Ive compare the current cvs build(snow mmx part 5) with the old pacthed (http://forum.doom9.org/showthread.php?p=797618#post797618) build,
the old patched build is still the fastest, 70fps,
comapare with the current build which only gives 57 fps,
and CREXbzh mentioned its the last patch...

Anyway, thanks ffmpeg/mplayer devs for their amazing works :)