New Codecs
SNOW vs x264 vs VP7

6 September 2005

Inspired by MeGUI, I tested SNOW 2-pass by encoding the same anime OP (opening clip) with about 20 different settings. I also asked a few people using different CPUs to try to play the resulted file on Windows 2000 or XP. One of the interesting results was, it doesn't play smoothly with ffdshow+Athlon 64 3200+, but it plays fine using CPU-optimized mplayer.

(1) Encoding

The following are what I found in my tests. Some of them may be just accidental, limited to this sample, and/or only valid for anime.

In the pre-tests, I felt SSD (cmp=1) is better than cmp=11/12, and slightly better than SAD (cmp=0), so I decided to use SSD this time.

The bitrate is 2200kbps, which is normal for anime OP: when the average bitrate for the whole episode is like 900kbps or so, OP often gets 2000-3000 because it's usually extremely high-motion compared to the body of the episode.

I also encoded the same clip with XviD and x264 for reference.

I'd say, if (hypothetically) XviD scored 100 points and x264 scored 130 points, SNOW and VP7 would get 120 ~ 125 points. Maybe it's a bit unfair to compare x264 and SNOW now: I read that one of the essential parts of SNOW, Overlapped Block Motion Compensation (OBMC), has not yet been implemented. This OBMC thing seems to be great. Besides, deblocking in x264, which is often problematic, works exceptionally well for anime. SNOW was, however, obviously better than XviD quality-wise in this test. Of course XviD is much better about the encoding speed, the CPU load in decoding, and stability. As rough indicators (not necessarily reflecting the perceived quality), lumi-wise error-free pixels for XviD/SNOW/VP7/x264 were 42%, 58%, 64%, 69.5% respectively, chroma-wise error-free pixels were 66%, 73%, 78%, 79%.

Settings and results

pred=0 (9/7 wavelet) might be better, but:
- I couldn't use qpel with pred=0 because with that combination:

• if v4mv is disabled, the encoding failed and stopped in the middle (with or without chroma ME)
• if v4mv is enabled, the encoder worked but I got a lot of "dotted horizontal line" artifacts.

- pred=0 without qpel worked decently, but I got an artifact ('echoed' line) along this high-contrast horizontal edge.



Those artifacts are gone with SSD and pred=1 (5/3 wavelet). So I focused on SSD+pred=1. (pred=2 (13/7 wavelet) was not usable, generating messed-up images.)

• qpel without chroma ME didn't help much. The result could even become worse.
• chroma ME without qpel helped chroma-wise (which may be obvious) but the result became slightly worse lumi-wise: With chroma ME, chroma errors (difference against the source) significantly decreased. In all the pixels (640x480) in 2217 frames, chroma-wise error-free pixels (Diff_U and Diff_V checked separately and averaged) are 70.9% without chroma ME, and 73.8% with chroma ME. However lumi noise slightly increased.
• With both qpel and chroma ME, the result was the best both chroma-wise and lumi-wise.
• The result was even better without v4mv but only numerically. Without v4mv, I got a lot of tiny artifacts, and the subjective quality was much better with v4mv.

Then I tested last_pred for qpel+chroma ME:

• For last_pred=0 without v4mv, the encoding failed.
• For last_pred=0 with v4mv, the result was worse than last_pred=3.

So, tentatively, this is the best settings I found for this sample so far:
mencoder "input.avs" -ovc lavc -passlogfile "pass.log" -lavcopts vcodec=snow:vstrict=-2:vpass=1:pred=1:cmp=257:subcmp=257:mbcmp=257:last_pred=3:qpel:v4mv:vqscale=2.0 -of avi -ffourcc SNOW -o "snowq2.avi"

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

(2) Decoding

Overlay Mixer and VMR-9 Renderless were tested:

• AMD, 1808MHz: The sample file doesn't play smoothly.
• Celeron 2 GHz: The sample file (video-only) plays decently, but the tester had a synch problem for the same video muxed with Vorbis audio.
• Athlon 64 3200+: The file doesn't play with ffdshow smoothly, but it plays fine with CPU-optimized mplayer, i.e. celtic_druid's mplayer2005.08.13.Athlon-64.7z. It plays fine even when muxed with Vorbis.
• Pentium 4, 3390MHz: The file plays flawlessly if the output colorspace is YUY2. The CPU load is around 50%. Fullscreen works fine too. RGB32 (ffdshow-side conversion to RGB) is possible but very CPU-intensive.
• Pentium 4, 3.20 GHz +HT: The file plays flawlessly even if the output colorspace is RGB32. The CPU load is around 50%. Even the 'sourest' settings (fullsceen, MPC's internal softsub, max texture=desktop, buffering=0) are possible.

1 September 2005

Src

XviD

SNOW

x264

VP7

Src: Huffyuv RGB
XviD: 1.1.0 beta2, 2200.4 kbps: 2-pass: MPEG, VHQ4 (also for bvop), qpel, Chroma, Trellis, No Turbo, No Cartoon mode
SNOW: dev-CVS-050813-01:18-3.4.4, 2199.9 kbps: 2-pass: cmp=SSD+Chroma, pred=5/3 wavelet, last_pred=3, qpel, v4mv
x264: revision291: 2198 kbps: 2-pass: me 6, umh 64, bframes 6, pyramid, ref 15, analyse all+8x8dct, temporal, weightb
VP7: VP 7.0.8.7, 2202.4kbps, 2-pass, Best Quality, default

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

x264 x264 --pass 2 --keyint 240 --min-keyint 6 --bframes 6 --b-pyramid --ref 5 --filter 0:3 --bitrate 2200 --qpstep 12 --vbv-maxrate 10000 --stats "stats.log" --analyse all --direct temporal --weightb --me umh --merange 64 --subme 6 --8x8dct --cqm flat --fps 23.976 --progress -o "output.mp4" "input.avs"

Src vs XviD vs SNOW vs x264 vs VP7

Src vs XviD vs SNOW vs x264 vs VP7

• snow-tmm2200v2.zip SNOW+Vorbis, 25.4MB, in MKV
• x264-tmm2200v2.zip x264, Video Only, 24.2MB, in MP4, x264 settings are identical to v1 except for --filter 0:3 (NOTE: MKV with AVC in native MPEG-4 mode; not VfW mode; use MPC or Haali's splitter)
• vp7-tmm2200.zip VP7, Video Only, 24.3MB, in AVI (On2 VP7 Codec (VfW))

If you have any questions (FAQ), comments,
or if you’re interested in joining us fansubbing together,
feel free to visit us or email us at the following address. Thank you!

(PGP Public Key)
[Fingerprint: 821C DADD 2C25 C86C 1754  6412 DD33 0238 68B5 8C64]
Also, you can leave comments on [AniDB], [Nyaa], or [BakaBT]
though we may not notice them immediately.

 Our website is Tor-friendly & JavaScript-free.