Speed and MPEG4 AVC

[Sagittaire]

Everyone say "MPEG4 AVC ... it's slow" but ...

http://multimediacom.free.fr/Download/Vitesse-OPSNR.PNG

http://multimediacom.free.fr/Download/Vitesse-SSIM.PNG

For the same speed
MPEG4 AVC in fast mode is by far better for metric than MPEG4 ASP with RDO actived.

For Same Quality
MPEG4 ASP in highest quality mode (lowest speed) is unable to make the same quality than MPEG4 AVC in fastest mode (highest speed)

[berrinam]

Interesting graph. Also interesting to note that x264 is completely above-right of Ateme, signalling that, (by PSNR) for any quality level, x264 is faster, and likewise, for any speed level, x264 is better quality.

Secondly, why are you using OPSNR? Don't you say that SSIM is much better?

EDIT: Why use JPEG? It's got lots of ringing.

[bond]

very interesting results! thx a lot :)

about the encodes, i see you have done 4 encodes with every codec (except ateme), can you post the used settings for those (if you still know them)?

[Sagittaire]

simply little and partial result : I will make 6 graph.

- Low Quality, medium quality and High Quality Encoding
- OPSNR and SSIM

But actually in my test x264 (MP and HP) is always little better than Ateme (MP and HP) in highest quality mode.

Actualy x264 HP is certainely the best codec in the world for metric test

[Sagittaire]

about the encodes, i see you have done 4 encodes with every codec (except ateme), can you post the used settings for those (if you still know them)?

well not choice with WMV9, VP7 and DivX6 : there are simple and limited speed profil.

With XviD I test that:
H263, bframe 2/1.50/0.00, no QPel, no GMC, no AQ
- ME vey low, VHQ0 -> highest speed
- ME low, VHQ0
- ME medium, VHQ0
- ME High, VHQ0
- ME Ultra High, VHQ0
- ME Ultra High, VHQ1
- ME Ultra High, VHQ1, trelli
- ME Ultra High, VHQ3, trelli
- ME Ultra High, VHQ1, trelli, chroma me
- ME Ultra High, VHQ4, trelli, chroma me, brdo -> highest quality

and I choose the best encoding for best possible fps=F(metric) zone limit.


With x264 I test that:

x264.exe --bframe 2 --ref 1 --filter 0:0 --bitrate 1400 --pass 2 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.25 --pbratio 1.33 --analyse "none" --8x8dct --weightb --me "dia" --subme 1 --no-chroma-me --progress --no-psnr -o x264HP_KingKong_400p_Speed1.mp4 Speed.avs


x264.exe --bframe 2 --ref 1 --filter 0:0 --bitrate 1400 --pass 2 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.25 --pbratio 1.33 --analyse "i8x8,p8x8,b8x8" --8x8dct --weightb --me "dia" --subme 2 --no-chroma-me --progress --no-psnr -o x264HP_KingKong_400p_Speed2.mp4 Speed.avs


x264.exe --bframe 2 --ref 1 --filter 0:0 --bitrate 1400 --pass 2 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.25 --pbratio 1.33 --analyse "all" --8x8dct --weightb --me "dia" --subme 6 --no-chroma-me --trellis 1 --progress --no-psnr -o x264HP_KingKong_400p_Speed5.mp4 Speed.avs


x264.exe --bframe 2 --bime --b-rdo --ref 5 --mixed-refs --filter 0:0 --bitrate 1400 --pass 2 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.25 --pbratio 1.33 --analyse "all" --8x8dct --weightb --me "dia" --subme 6 --trellis 1 --progress --no-psnr -o x264HP_KingKong_400p_Speed6.mp4 Speed.avs


With Ateme I test that:

encavc.exe -i Speed.avs -o NDAVCHP_KingKong_400p_Speed1.mp4 -qual fastest -setef xf8x8 -rcmode 2nd -log 1pass.log -br 1400000 -deblock 0 -ref 1 -bref 1

encavc.exe -i Speed.avs -o NDAVCHP_KingKong_400p_Speed2.mp4 -qual fast -setef xf8x8 -rcmode 2nd -log 1pass.log -br 1400000 -deblock 0 -ref 1 -bref 1

encavc.exe -i Speed.avs -o NDAVCHP_KingKong_400p_Speed3.mp4 -qual normal -setef xf8x8 -rcmode 2nd -log 1pass.log -br 1400000 -deblock 0 -ref 1 -bref 1

encavc.exe -i Speed.avs -o NDAVCHP_KingKong_400p_Speed4.mp4 -qual good -setef xf8x8 -rcmode 2nd -log 1pass.log -br 1400000 -deblock 0 -ref 1 -bref 1

encavc.exe -i Speed.avs -o NDAVCHP_KingKong_400p_Speed5.mp4 -qual best -setef xf8x8 -psy 1 -rcmode 2nd -log 1pass.log -br 1400000 -deblock 0 -ref 1 -bref 1

encavc.exe -i Speed.avs -o NDAVCHP_KingKong_400p_Speed6.mp4 -qual extra -setef xf8x8 -enhchrp -psy 1 -rcmode 2nd -log 1pass.log -br 1400000 -deblock 0 -ref 5 -bref 1

[lazyn00b]

Hello Sagittaire, and thank you for your tests of these codecs.

I've noticed lately that you use custom values for qcomp, ipratio, and pbratio for x264 encoding. Would you mind explaining why you change these from the defaults? I was wondering if these values give you better results on PSNR, SSIM, etc.

[uray]

where is x264 point located for same settings with :
--bframe 4 --b-rdo --bime --trellis 2 --me "umh" --subme 7 --no-fast-pskip --ref 8 --mixed-refs

because I always use this for every encode...

btw thanks for the graph, very nice!

[Mutant_Fruit]

I noticed you used --ref 1 for x264 and ateme. Wouldn't you get better quality per filesize if you used --ref 4 or better, and used multiple b-frames/bpyrimid? Or is that bad for metrics?

[Sagittaire]

where is x264 point located for same settings with :
--bframe 4 --b-rdo --bime --trellis 2 --me "umh" --subme 7 --no-fast-pskip --ref 8 --mixed-refs

because I always use this for every encode...

btw thanks for the graph, very nice!

IMO it's useless for meduim quality (usual 100-120 min DVD back-up) and high quality encoding ...

very low speed and not very higher quality ...

[Sagittaire]

I noticed you used --ref 1 for x264 and ateme. Wouldn't you get better quality per filesize if you used --ref 4 or better, and used multiple b-frames/bpyrimid? Or is that bad for metrics?

I use best possible quality/speed setting ... I think ... but perhaps possible to find better fps = F (OPSNR) limitation zone.

[Mutant_Fruit]

I think using --ref 3 or --ref 4 will provide a significant (ish) boost in PSNR supposedly worth the speedloss. After --ref 5 or so, the gains become less and less except maybe for anime.

[akupenguin]

@Sagittaire
use "--me hex" for everything except the fastest.
remove "--analyse all" from #3
"--analyse i8x8,i4x4,p8x8" is both better and faster than "--analyse i8x8,p8x8,b8x8"

[Sagittaire]

@Sagittaire
use "--me hex" for everything except the fastest.
remove "--analyse all" from #3
"--analyse i8x8,i4x4,p8x8" is both better and faster than "--analyse i8x8,p8x8,b8x8"

1) thank you for this fabulous work on the x264

2) thank you for new setting ... I will try that.

[uray]

IMO it's useless for meduim quality (usual 100-120 min DVD back-up) and high quality encoding ...

very low speed and not very higher quality ...

ic that..
so... can't wait for lowbitrate comparison... hehehe...

usually I encoded DVD to 256MB using 380-400Kb/s.

[rozemab]

Is Ateme the same encoder as Nero Digital Pro 2 (in your tests)?

[Doom9]

Is Ateme the same encoder as Nero Digital Pro 2 (in your tests)?No.. it's a non publicly available AVC high profile encoder currently in beta test. And no, they don't take in testers at this point.

[puffpio]

ic that..
so... can't wait for lowbitrate comparison... hehehe...

usually I encoded DVD to 256MB using 380-400Kb/s.
wow! at what resolution?

[uray]

wow! at what resolution?

640x352

[Sagittaire]

Update:
- Elecard AVC High Profil encoder 23/01/2006 (beta testing version)
- DivX 6.1.1 encoder
- Better Target bitrate for VP7 (better result)
- akupenguin setting for x264

I test only speed in second pass (real encoding pass) :
- All codec can use first turbo pass
- be carefull : Ateme can use high turbo pass in real encoding situation (more than 10000 frames) but if second pass is high quality pass (slow encoding) then average speed for 1st + 2nd will not really change for all codec

conclusion :
- Elecard codec is very good AVC codec too
- MPEG4 AVC codec are really better than MPEG4 ASP codec for speed and quality
- MPEG4 AVC seem to have difficulty to progress with high speed now. Certainely that metric quality improvement become very difficult for all AVC developper. IMO it's certainely the time for x264 to choose HVS tuning way with adaptative quantisation for example ...

[IgorC]

Update:
- MPEG4 AVC seem to have difficulty to progress with high speed now. Certainely that metric quality improvement become very difficult for all AVC developper. IMO it's certainely the time for x264 to choose HVS tuning way with adaptative quantisation for example ...

Informative test. :)
That is true. For ssim tests Ateme+noAQ and x264 are close. But Ateme+Aq (psy2) is best imho result. Not always for OPSNR but mostly for SSIM.

[Sagittaire]

update for Elecard ...

[guada 2]

Hello Sagittaire,

- MPEG4 AVC seem to have difficulty to progress with high speed now. Certainely that metric quality improvement become very difficult for all AVC developper. (Sagittaire)

It appears very difficult to harmonize optimal quality with speed.
But you don't think that it is obvious.

IMO it's certainely the time for x264 to choose HVS tuning way with adaptative quantisation for example ... (Sagittaire)

Will that change metric measurements on the low bitrates?

[IgorC]

Will that change metric measurements on the low bitrates?

Of course. Remember Xvid AQ. Ateme Psy2/3 (AQ per macroblock)


Wow, Russian Elecard H.264 is doing progress :p

[Sagittaire]

Of course. Remember Xvid AQ. Ateme Psy2/3 (AQ per macroblock)

yes but here metric will be unable to evaluate HVS progress ... only eyes for that.

IMO x264 metric progress will be very difficult and slow now ...


Wow, Russian Elecard H.264 is doing progress :p

Yes ... Elecard AVC is very good surprise for me:
- High speed encoder
- High quality encoder (for my eyes too)

French trust (for good AVC encoder) is over ... lol

[bond]

with what tool did you encode with elecard? the mainconcept encoder tool?
what settings did you use for elecard?

[Sagittaire]

Update:
- Elecard AVC High Profil encoder "23.01.2006" (beta testing version)
- DivX 6.1.1 encoder
- Better Target bitrate for VP7 (better result)
- akupenguin setting for x264


CLI beta version from Elecard

Setting for best quality are:

- High profil
- 3 bframe, WPred, ref = 5
- high ME search with RDO
- Inloop alpha = -1, beta = -1

[Eric B]

Did somebody test the h.264 encoder of Apple (QuickTime 7 Pro) ??

Actually, I want to use h.264 to re-encode the small video clip shooten by my photo camera. As my camera (Panasonic FX9) make .mov files (MJPEG), I try to use QuickTime to encode them.
I've also tried Nero Recode from Nero7 which recognize the .mov format too.

Here a small comparison with a clip from an other camera (Canon Ixus 40 which gives avi files):
640x480 @ 30 fps like the original for video, sound has to be upsampled because none of the AAC encoder support the poor format of the source (8 bits 11.025 Hz mono, which is still far better than the 8000 Hz soundtrack stored by my Panasonic camera).
The clip is short, only 20 sec. Each test has been done with the maximal quality parameters (in 2 passes), more precisely:
- Xvid 1.1 (without sound, into VirtualDubMod), 1800 kb/s
- Nero h.264 AVC Std 1500 kb/s, audio AAC-HE 48 kHz stereo 64 kb/s because no lower options.
- Apple h.264 AVC Main Profile 1500 kb/s, audio AAC 22 kHz mono 20kb/s.

And the encoding time with my Duron 2 Ghz CPU (no SSE, 64 kB cache L2):
- Xvid : 45s -> (20s / 45s) *30 fps *2 pass = 27 FPS average
- Nero : 3 min 25 -> 5,8 fps
- Apple : more than half an hour !!!!

I couldn't believe this very slow encoding with Apple Encoder. I've made the same encoding under 2 other computers (Centrino Dothan 1.6 Ghz, 2MB L2 for one ; Athlon 64 1.8 Ghz 1MB L2 for the 2nd), and they encoded my clip in 5 min, i.e. 4 FPS.
These CPU are for this encoding 6 times faster. I did not tested the other encoding with them, but I suppose it won't be to far from the result of my duron 2 Ghz.
The question is: Why such a big difference with the Apple Encoder ?
2 ideas:
- SSE only
- very dependant to the L2 cache of the CPU (the duron is a bastard CPU, with more L1 than L2 !!)

Can somebody test the Apple encoder with a Athlon XP (no SSE but with 512 Kb L2) ?

[Manao]

2 ideas:
- SSE only
- very dependant to the L2 cache of the CPU (the duron is a bastard CPU, with more L1 than L2 !!)You forgot the third idea : coded with feets :p

It's not a matter of missing cpu extension, it's only a matter of company politics. They don't want to promote their h264 encoder on PCs, so they make it slow, perhaps purposefully ( in the same way their decoder is slow on PCs ).

[guada 2]

Hello :)

The technology of the CPUs and graphic cards seem still the only efficient remedies for the speed of an encoding AVC.( playing too AVC HD).
I remember, along ago one used in particular the technique of the processors for the codec SNOW on FFDshow video codec..

Why is it so easy to find a parade for the WAVELET and not for AVC?

some suggestions?
Thanks..

[Manao]

Yes, you're clueless.

Snow's decoding was made faster thanks to asm optimizations because there were none previously. Libavcodec h264 decoder has always been quite asmoptimized, so you didn't notice any such speed up, because they were present from the beginning.

Additionnaly, as you may have heard with coreavc, avc decoding can be speeded up by properly coding a decoder.

[guada 2]

:thanks: Manao.

Very interesting..
But I have another question:

If I understand well, it will be a universal decoder specific to all codecs AVC!
it is fantastic.
Therefore, it is for soon standalone AVC??? :)

And "RVxxx"????
It is for little time (not in the competitive spirit) ???

Although, nowadays the places are expensive ( perhaps not).
Who knows?

[Sagittaire]

update:
- SSIM graph

Very surprising result: for this sample, with this resolution and with this bitrate Elecard is simply the best for speed and quality in SSIM test

[Sirber]

CLI beta version from Elecard

Setting for best quality are:

- High profil
- 3 bframe, WPred, ref = 5
- high ME search with RDO
- Inloop alpha = -1, beta = -1Where can I get it?

[Sagittaire]

Elecard AVC High Profil encoder 23/01/2006 (beta testing version)

Ateme and Elecard are only beta testing version

[Sirber]

If I understand correctly, I can't get a copy?

[Sharktooth]

The question is: Why such a big difference with the Apple Encoder ?
Now you know why i call it CrapTime.
Can somebody test the Apple encoder with a Athlon XP (no SSE but with 512 Kb L2) ?
Athlon XP has SSE. However CrapTime is slow even on an Athlon X2 4800...

[Sergey A. Sablin]

If I understand correctly, I can't get a copy?
Official release is planned to be in a middle of March (well, it is pretty soon).
Then you will have access to trial versions of both MainConcept (high profile) and Elecard (main profile) encoders.