x264 vs rv10 vs vp7 vs ateme @ 400kbps

[Sirber]

http://www.detritus.qc.ca/files/comp400/index.htm (Mirror (http://ikaruga.co.uk/~snacky/dts/))

Nothing scientific, only screenshots.

IMHO x264 gives the best results (screens and in motion).

[iwod]

I think first shot, ateme better than all others.
2nd shot ateme did very poor.

The rest are about the same.

[bond]

strange that you mux x264 to .mkv but leave ateme in .mp4...
whats the sense of doing that?

edit: are vp7 and rv10 still not able to hit the target filesize accurately?

[Sirber]

x264 has been encoded via RealAnime, which currently convert to MKV in the encoding process.

rv10 "streaming rate control" always had difficulties to hit target filesize. I didn't use "Curve rate control" coz it produce worst results bellow 600kbps.

vp70 is less worst in that than last time. Last time I tryed I hit 9MB :(

ateme first shot is surely iframe.

[Doom9]

edit: are vp7 and rv10 still not able to hit the target filesize accurately?That would be in line with the findings of my last codec comparison..

[Sirber]

rv10 with the curve would hit #1.

[foxyshadis]

Too bad you didn't throw in an xvid encode, just to show off what a huge difference there is, that low. xD

rv10 did really nicely on the first and second; I wonder why it fails so badly at the others.

[Revgen]

I think first shot, ateme better than all others...

I wouldn't say that. There are "white streaks" in the tanned area in the right-hand corner that are not in the source image. The only codec that doesn't display these streaks is VP70. Although Ateme does have less "blocky" artifacts then VP70, and it's "white streaks" aren't as bad as the others, so I'd say it's a tie between these two codecs.

[Rash]

Wow, they certainly looked awful at this bitrate. ;)

Now... seriously, I think I liked VP7 more. Just a (very) dumb question, what is this Atheme encoder? Is it the same as NeroDigital?

[ChronoCross]

Wow, they certainly looked awful at this bitrate. ;)

Now... seriously, I think I liked VP7 more. Just a (very) dumb question, what is this Atheme encoder? Is it the same as NeroDigital?

The Ateme encoder is the beta currently in progress for the next nero digital update for AVC high profile.

[Sirber]

Wow, they certainly looked awful at this bitrate. ;)

Now... seriously, I think I liked VP7 more. Just a (very) dumb question, what is this Atheme encoder? Is it the same as NeroDigital?
Please download the VP7 clip. It doesn't look that good as in the screens :(

[Revgen]

IMHO x264 gives the best results (screens and in motion).

I think so too, but just barely better than Ateme. I had to check both clips about 3 times to see differences.

[iwod]

Wow, they certainly looked awful at this bitrate. ;)

that was what i wantedto say.... but didn't have the gut to shout it out....

[Sirber]

I'm recompressing rv10 and VP70 to get same filesize.
Also ateme with -psy 3

[snacky]

I have a few things to say about this comparison:

1. I mirrored the files you put up so far here: http://ikaruga.co.uk/~snacky/dts/
2. the x264 clip uses multiple slices per frame; the ateme clip doesn't. For best comparison, you should probably not use multiple slices with x264
3. the ateme clip uses some bframes; bframes are disabled in the x264 clip
4. the deblocking offsets are different in the ateme (+3) vs x264 (+2) clips

It's probably also a good idea to make sure both codecs are using the same qcomp, to make the comparison more useful. ISTR ateme's is higher (0.75 maybe?) but I'm not sure.

[Sirber]

1) Thanks! :D
2) What are slices?
3) You are right about x264. RealAnime bug :)
4) Both were set to +3

[snacky]

2) What are slices?
Something you probably enabled by default in your gui...
4) Both were set to +3
Nevertheless, the offset is +2 in the ateme clip.

[Sirber]

My GUI uses 4 threads by default. Maybe it's what you call slice.

ateme cmdline: -qual extra -rcmode 2pass -br 400000 -psy 1 -deblock 3 -adaptdbk -setef ipred,ppred,bpred,wpred,cabac,deblock,part,hpel,qpel,xf8x8 -maxb 3 -enhchrp -ref 8 -bref 8 -priority idle

[bill_baroud]

4 threads by default ?? wow, i didn't know that quadri-processors computers were a standard now....

[bond]

4 threads by default ?? wow, i didn't know that quadri-processors computers were a standard now....lol, indeed

the number of threads define the number of slices in x264

slices help encoding speed but harm quality slightly, so you should disable threads in both encoders

[Selur]

slices help encoding speed but harm quality slightly, so you should disable threads in both encoders
Are there any statistics and further information about this anywhere,...
I mean, is the reduction through multithread support that high, that it would show as a visible 'downgrade' ?

Cu Selur

Ps.: 4 threads should also be fine if he uses a Dual P4 with HT ;)

[bond]

Are there any statistics and further information about this anywhere,...
I mean, is the reduction through multithread support that high, that it would show as a visible 'downgrade' ?dunno any statistics, but i would guess the quality loss isnt big

[Sirber]

4 threads by default ?? wow, i didn't know that quadri-processors computers were a standard now....
DualCore with HT :). Now RealAnime count the number of CPU to set the bumber of slices.

[IgorC]

Source causes a oversize problem . Source is Xvid >3Mbit, very high motion. I tried to encode it to Xvid on 400 kbit/s. But even at quantizer 31, the size was too big.

[Sirber]

By error I encoded the clip with x264 at 300kbps, only pframes (RealAnime setting bug). Was ugly but hit correct filesize.

VP70 and RV10 cap minimum quality also.

[Sirber]

about bframes, my settings are:
http://www.detritus.qc.ca/files/x264_setting.png

I think "adaptive bframes" prevent them in my clip.

[bill_baroud]

DualCore with HT :). Now RealAnime count the number of CPU to set the bumber of slices.

imho, Hyperthreading is irrevelent in that case, from what i know about it and how a codec works, that why i said "quadri-processor" and not dualcore/processor with HT (which is exactly the same in Intel case, just packed differently)



hyperthreading use the fact that there is many executions units in a processor and that they aren't all used by one program or even not well used (because of dependancies etc...). So HT allow the processor to execute some other code in other execution units while waiting for the first code to finish. That's the ultra-simplified theory (correct me if i'm wrong). In the case of x264 (or any other program, especially optimized ones), you're going to try to execute the same (optimized) flow of instructions in parallel, without enough execution unit for it (if the mmx unit is busy with one thread, it's busy for the other thread too and he has to wait ;), nullifying the interesting part of HT.

But perhaps that doesn't matter and my thoughts are wrong, there is enough "holes" in the execution flow and the speed gain from HT is fairly interesting (can't remember the numbers) against the quality loss of multi-slice.

[Sirber]

about bframes, my settings are:
http://www.detritus.qc.ca/files/x264_setting.png

I think "adaptive bframes" prevent them in my clip.
Or it's fast first pass.

[bond]

I think "adaptive bframes" prevent them in my clip.prevent what?

[Sirber]

the use of bframes and other stuff:

http://forum.doom9.org/showthread.php?p=685447#post685447

[Rash]

Iwod, that's alright. That's what Sirber intended with this test. Who degrades less. :D

Anyway, I said VP7 was "better" but I forgot the filesize was bigger as well. Not fair. :)

[bobololo]

By error I encoded the clip with x264 at 300kbps, only pframes (RealAnime setting bug). Was ugly but hit correct filesize.

VP70 and RV10 cap minimum quality also.

If you can't make rv10 and vp7 to hit the correct bitrate why don't you increase the bitrate target of other codecs to match with them ?

IMHO as long as the compared clips don't have the same bitrate, their comparison doesn't make sense.

[Sirber]

I'll try 500. What if VP7 always oversize? ;)

[Sagittaire]

IMHO as long as the compared clips don't have the same bitrate, their comparison doesn't make sense.

yes ... with very high quant variability for quality is very high

little less bitrate = high degradation for quality