Ateme H.264 HP Beta Test : Quality Feedback

[bobololo]

This thread is intented to discuss about quality issues from Ateme AVC/HP beta encoder. For troubleshootings, issues and bugs, please use the other thread :

http://forum.doom9.org/showthread.php?t=95803

-- bobo

[*.mp4 guy]

I just made a quick test with a fully redone csm file using mostly linear matrices, initial results are quite pleasing. In my test blocking stayed about the same, but block noise and details went up (I'm not sure if there are actually more details or if that is just a side effect of the noise). Surprisingly ringing didn't increase much.

For lossless mode what would you recomend for switches?

[Latexxx]

Can I post screen shots?

[Manao]

Latexxx : of course, they are even welcomed.

*.mp4 guy : for lossless, don't touch rcmode settings, don't use quality over normal, use cabac, part. The rest is pretty much content dependant : bframes might help or hurt the quality, wpred might help or be useless, mbaff will help if it's interlaced, xf8x8 i have no idea if it'll help or not. Gop settings should be as loose as possible. Psy, deblocking, enhchrp, cmx don't matter.

[couscous]

I've just made a few test with the new encoder provided by ateme using the Sagittaire's clip.

During these tests, no problems for encoding or decoding (no probleme for registring Ateme Encoder).

Here are my results:
settings : -br 450000 -qual extra -rcmode 2pass -psy 3 -adaptdbk -setef xf8x8,ipred,ppred,bpred,wpred,cabac,deblock,part,hpel,qpel -maxb 3 -bref 4 -enhchrp -ref 8 -psnr -priority idle
resultat : 1ere pass : 8.45 fps
2eme pass : 5.3 fps
psnr mean : 41.83 dB
psnr overall : 40.31 dB
time elapsed : 17 min 28
SSIM 1 : 71.27

As you can see, the speed is pretty good (for me, the same speed than Nero Digital/Ateme AVC MP but with the settings of HP!).
But, there is something stange. When I use the same settings but with quality "full" (and not "extra") the speed is the same for the 1st pass but is only 0.5 to 1 fps for the 2nd pass and the quality is not very good : SSIM 1 : 69.44 (like a another guy in the Bugs/Issues threat).

I've also compared the clip encoded by the Ateme encoder with the clip encoded by X264 rev 261 encoder (SSIM 1 : 69.07 for x264). On the graph we can see that ateme is far better than x264 at the beginning of the clip but at the end this is the same and sometimes x264 is better...

http://img221.echo.cx/img221/4818/sanstitre3cq.jpg


I have a problem with ateme decoder when I use it in virtualdub with the x264 HP clip for SSIM analyse. The decoding isn't fluid and there are some jolts. With ffdshow decoder no problem. I don't know why...

Config computer : Windows XP SP2
Athlon XP2200
Ram : 1 gb

[Latexxx]

Clip: Cradle 2 the Grave Trailer, first 500 frames
Resolution: 640x256
Bitrate: 200 kbps

Settings common for all test clips:
- enhchrp
- deblock 0
- fx8x8
- qual best

Encoding speed about 2.5 fps on an old Pentium III 500 MHz machine; plays the clips at about 20 fps.

Clip no. 5 (my filename):
psy 2, cbr, file size 521 kb

Clip no. 6:
psy 2, abr, 521

Clip no. 7:
psy 3, abr, 549

Clip no. 8:
psy 3, cbr, 523

Notes:
- Abr looks much better than cbr and file sizes are almost identical except for clips 7 & 8.
- Clips 6 & 7 look the best.
- 6 is foggier than 7 but 7 blocks more on plain surfaces. 7 also has some details (on edges) which look too sharp and annoying (hard to describe).
- In general, 6 looks better when the camera doesn't move much and no. 7 looks better when camera moves. I would probably say that 7 looks better but I must also say that it has some irritating artefacts which no. 6 doesn't have.

I would post some screenshots but it appears that I can't load these clips to avisynth using directshowsource (black image) and mediaplayer classic doesn't allow me to capture frames.

[dragongodz]

i did a quick test with a multifading clip, fades from black to white to greyscale scene to colours. tested using defaults except ABR at 500 kb/s. all fades looked good and smooth.

will to run it through some different settings tommorow night. :)

[babayaga]

I've just made a few test with the new encoder provided by ateme using the Sagittaire's clip.

During these tests, no problems for encoding or decoding (no probleme for registring Ateme Encoder).

Here are my results:
settings : -br 450000 -qual extra -rcmode 2pass -psy 3 -adaptdbk -setef xf8x8,ipred,ppred,bpred,wpred,cabac,deblock,part,hpel,qpel -maxb 3 -bref 4 -enhchrp -ref 8 -psnr -priority idle
resultat : 1ere pass : 8.45 fps
2eme pass : 5.3 fps
psnr mean : 41.83 dB
psnr overall : 40.31 dB
time elapsed : 17 min 28
SSIM 1 : 71.27

But, there is something stange. When I use the same settings but with quality "full" (and not "extra") the speed is the same for the 1st pass but is only 0.5 to 1 fps for the 2nd pass and the quality is not very good : SSIM 1 : 69.44 (like a another guy in the Bugs/Issues threat).

CyberGuy seems to have the same problem (http://forum.doom9.org/showthread.php?p=673100#post673100) so I double-checked with another internal test software that is kind enough to compute PSNR and SSIM while encoding. This avoids any directshow/avisynth potential problems. The results are consistant with what I found a few weeks ago measuring with Sagittaire's scripts (the codec evolved slightly since then) .
be careful that command-line switches are not exactly the same

Quality extra :

Command line of this test app :
testeavc.exe Encodage.avs -qp 24 -psnr -qual extra -rcmode two -rcstat -psnr -ssim -o new_hp2_450_extra.mp4 -br 447000 -mingop 1 -maxgop 300 -ref 8 -bref 3 -setef xf8x8,cabac,bpred,wpred -maxb 2 -enhchrp -psy 3
results :
3076 frames encoded
6874626 bytes produced
MP4 file size: 6907924 bytes
Average bitrate : 447.0 kb/s (Total = 6713 kB, Error = 0 kB)
Mean PSNR : Y:41.314 dB U:44.773 dB V:45.689 dB
Average PSNR : 42.1449 dB
Overall PSNR : 40.8720 dB
SSIM0 : 75.875 SSIM1 : 71.366 SSIM2 : 71.324


Quality full :

Command line of this test app :
testeavc.exe Encodage.avs -qp 24 -psnr -qual full -rcmode two -rcstat -psnr -ssim -o new_hp2_450_full.mp4 -br 447000 -mingop 1 -maxgop 300 -ref 8 -bref 3 -setef xf8x8,cabac,bpred,wpred -maxb 2 -enhchrp -psy 3
results :
3076 frames encoded
6874873 bytes produced
MP4 file size: 6908171 bytes
Average bitrate : 447.0 kb/s (Total = 6713 kB, Error = 0 kB)
Mean PSNR : Y:41.422 dB U:44.789 dB V:45.720 dB
Average PSNR : 42.2370 dB
Overall PSNR : 40.9670 dB
SSIM0 : 76.238 SSIM1 : 71.719 SSIM2 : 71.678

So there is an issue with the measurement, encavc.exe or both. We will check encavc now.

[Sharktooth]

Ok, i tried the denoiser and fgm/fgboost. It seems to work but the noise reproduction is weird. I mean, it's artificial/innatural/doesnt look good. In some scenes it works well, but in other scenes it doesnt at all. Maybe i didnt play enaugh with settings or maybe different scenes have different noise (and need different denoising/fgboost settings).
I'll try to separate and re-encode those scenes and see if things get better.
Also i started testing with custom scale matrices (sorry, couldnt resist :D ).

[708145]

I just tried a first shot yesternight and managed to get it really slow :p

settings out of my head: with full and 5+5 ref and 8x8dct (I'll post the command line later if needed) I got down to 0.2 fps!

source: mobcal and parkrun in 720p25 mode.

results: 33.27db @ 10Mbit/s for parkrun.

specs: AXP1800+; 768MB;

many more jobs running atm. (CPU at 51C) :)

bis besser,
Tobias

[kwtc]

I just tried a first shot yesternight and managed to get it really slow :p

settings out of my head: with full and 5+5 ref and 8x8dct (I'll post the command line later if needed) I got down to 0.2 fps!


For information, the full quality mode is mainly a development tool. Its goal is mainly to help development of the higher quality mode best and extra. These modes are much faster and provide, in my opinion, a better quality-speed ratio.

[Razorblade2000]

Just a quick low bitrate test:

Input file : Test.avs
Output file : Test.mp4
Resolution : 640x368 @ 25.00 fps
Length : 8123 Frames

Commandline

encavc.exe -i Test.avs -o Test.mp4 -qual normal -rcmode 2pass -br 325632 -psy 3 -deblock -2 -adaptdbk -maxb 3 -enhchrp -setef ipred,ppred,bpred,wpred,cabac,deblock,part,hpel,qpel,xf8x8


Script:

avisource("D:\tvcapture.avi",false)
SelectRangeEvery(1000, 125)
ConvertToYV12()



I am really impressed with the quality I achieved using these settings! I wanted to resize to 480*X to get a satisfying kbit/pixel ratio but I forgot to :P
But using only my eyes I am really pleased (especially watching it on my TV)

I tired the best quality mode... but encoding at <1 fps on my 2500+ AMD Athlon XP Mobile didn't really give me the shivers :sly:

[708145]

For information, the full quality mode is mainly a development tool. Its goal is mainly to help development of the higher quality mode best and extra. These modes are much faster and provide, in my opinion, a better quality-speed ratio.

I know I am insane. With best it's about 2.7fps btw.
I was looking for what the limit is :]

For longer encodes I will have to use some quality-speed tradeoff for sure.

bis besser,
Tobias

[Manao]

RazorBlade2000 : you should definitely get more than 1 fps with -qual best and your computer ( here ( 2800+ ), 720x576 @ 25fps runs around 4 fps for the second pass )

@all : by default, ipred,ppred,bpred,wpred,cabac,part,hpel,qpel, deblock are enabled, no need to add them again ( it will reduce command line size )

[Razorblade2000]

@Manao: maybe something else was hogging my CPU Cycles...


But I really like the speed of the CQ Mode!
And eben at 35, it's watchable when you step back or use a small TV!

6408 kb for 8123 Frames --> avg bitrate of 158 kbit/s!!!
Amazing...
Guess I'll have to try highest quality settings to see how low I can push the bitrate on that one :)


* Encoding summary

Input file : Test.avs
Output file : Test.mp4
Resolution : 640x368 @ 25.00 fps
Length : 8123 Frames
Quality : Normal
Rate Control : Vbr
Init Quantiser : 35 [0 - 51]
Gop Size Min - Max : 1 - 300 (closed)
Process Priority : Normal [1 thread(s)]


* Encoding Features

- prediction : ipred ppred bpred(2) wpred : using 4:1 ref(s)
- entropy : cabac
- subsampling : hpel qpel
- mb partition : 16x16/16x8/8x16/8x8
- interlaced : disabled
- misc : deblock(-2:fixed)

-- Start processing pass 1 / 1
* 06285: encoding @ 26.09 fps - bitrate 256.15 kb/s - 77.39% completed

[kwtc]

@Manao: maybe something else was hogging my CPU Cycles...

- prediction : ipred ppred bpred(2) wpred : using 4:1 ref(s)


Its the four references that clobbers your cpu...

[Manao]

They weren't in the original command line...

[*.mp4 guy]

I just did an encode of a rock concert (good quality source) and used psy3 for the first time, Overall the encode was rather good. however on some particularly frenetic shots there were huge blocks all over. This detracted from the otherwise quite good quality of the encode.

E:\encavc-beta2-1\encavc.exe -i E:\clip.avs -o E:\clip.mp4 -br 900000 -ref 3 -bref 3 -mingop 48 -maxgop 240 -qual best -enhchrp -rcmode 2pass -maxb 3 -deblock -6 -setef ipred,ppred,bpred,wpred,cabac,part,hpel,qpel,xf8x8,deblock,csm

[edit] It apears that the blocks usually apear on mostly-flat gradients with few details, the reason I was seeying them during high-motion shots was motion blur.

[CyberGuy]

CyberGuy seems to have the same problem (http://forum.doom9.org/showthread.php?p=673100#post673100) so I double-checked with another internal test software that is kind enough to compute PSNR and SSIM while encoding. This avoids any directshow/avisynth potential problems. The results are consistant with what I found a few weeks ago measuring with Sagittaire's scripts (the codec evolved slightly since then) .
be careful that command-line switches are not exactly the same

Quality extra :

Command line of this test app :
testeavc.exe Encodage.avs -qp 24 -psnr -qual extra -rcmode two -rcstat -psnr -ssim -o new_hp2_450_extra.mp4 -br 447000 -mingop 1 -maxgop 300 -ref 8 -bref 3 -setef xf8x8,cabac,bpred,wpred -maxb 2 -enhchrp -psy 3
results :
3076 frames encoded
6874626 bytes produced
MP4 file size: 6907924 bytes
Average bitrate : 447.0 kb/s (Total = 6713 kB, Error = 0 kB)
Mean PSNR : Y:41.314 dB U:44.773 dB V:45.689 dB
Average PSNR : 42.1449 dB
Overall PSNR : 40.8720 dB
SSIM0 : 75.875 SSIM1 : 71.366 SSIM2 : 71.324


Quality full :

Command line of this test app :
testeavc.exe Encodage.avs -qp 24 -psnr -qual full -rcmode two -rcstat -psnr -ssim -o new_hp2_450_full.mp4 -br 447000 -mingop 1 -maxgop 300 -ref 8 -bref 3 -setef xf8x8,cabac,bpred,wpred -maxb 2 -enhchrp -psy 3
results :
3076 frames encoded
6874873 bytes produced
MP4 file size: 6908171 bytes
Average bitrate : 447.0 kb/s (Total = 6713 kB, Error = 0 kB)
Mean PSNR : Y:41.422 dB U:44.789 dB V:45.720 dB
Average PSNR : 42.2370 dB
Overall PSNR : 40.9670 dB
SSIM0 : 76.238 SSIM1 : 71.719 SSIM2 : 71.678

So there is an issue with the measurement, encavc.exe or both. We will check encavc now.
I discovered why I had lower SSIM values. The more threads the encoder uses the lower the quality; FYI to all beta testers. I used the following command line parameters and got the following SIMM 1 values. Still not quite the high score you got.


ENCAVC.EXE -i ENCODE.AVS -o HPII.MP4 -qp 24 -qual full -rcmode 2pass -rcstat -psnr -ssim -br 447000 -mingop 1 -maxgop 300 -ref 8 -bref 3 -setef xf8x8,cabac,bpred,wpred -maxb 2 -enhchrp -psy 3

SSIM: Structural Similarity Index Metric 0.23
Average SSIM= 71.56947112

ENCAVC.EXE -i ENCODE.AVS -o HPII.MP4 -qp 24 -qual full -rcmode 2pass -rcstat -psnr -ssim -br 447000 -mingop 1 -maxgop 300 -ref 8 -bref 3 -setef xf8x8,cabac,bpred,wpred -maxb 2 -enhchrp -psy 3 –thread 2

SSIM: Structural Similarity Index Metric 0.23
Average SSIM= 70.42695220

[IgorC]

SSIM will take varios values depending on if auto PP is enabled and CPU power was used by another programs(Antivirus, Player etc) during SSIM test. Maybe it's explanation for this case.

[Andrey]

Hi guys !
Tested such a clip (Die Hard 3): 608x304, 20000 frames long.
Encode settings: encavc.exe -i dh3.avs -o dh3.mp4 -qual full -rcmode 2pass -br 660000 -adaptdbk -par 235:100 -maxb 3 -ref 2 -bref 2 -setef xf8x8 -maxgop 240
The speed was:
1st pass: ~17 frames/sec
2nd pass: ~1 frame/sec
My machine is C2400.

EDIT:
Just found:
>>For information, the full quality mode is mainly a development tool.
May be this issued the speed problem...

So, first question is: -ref 2 -bref 2 do affect speed so much, or 17 times slower 2nd pass is usual thing ? I 'll test it at evening too.

2nd: -par 235:100 was and error :) So, I can not play the clip normally now :(
Is there any way to change par setting in .mp4 file ?
What will the correct pixel aspect ratio be for this clip ?
EDIT: Hope this will help me http://forum.doom9.org/showthread.php?t=86870. Will see.

Last question: What is mpaff, baff and whatever ? :)

[Manao]

First pass is a fast first pass, that's why it's faster. First pass speed is usually the same whatever the quality setting is, whereas second pass speed is totally linked to the quality settings. Since full is uberslow ( and meant to be that way ), if think that explains the 17 times slower.

The correct par is around 92:100, since iirc Die Hard 3 is shooted in 1.85.

Paff / Mbaff are explained in this forum. Summed up, they are tools to handle interlaced content, paff at a frame level, and mbaff at a macroblock level. Search for more information.

[Andrey]

>>Paff / Mbaff are explained in this forum. Summed up, they are tools to
>>handle interlaced content, paff at a frame level, and mbaff at a
>>macroblock level. Search for more information.
Found it. Thanks !

>>The correct par is around 92:100, since iirc Die Hard 3 is shooted in 1.85.
You may be right. Will check it. 32:27 or 92:100 should fit :)

Thanks for the info, anyway !

[couscous]

I discovered why I had lower SSIM values. The more threads the encoder uses the lower the quality; FYI to all beta testers. I used the following command line parameters and got the following SIMM 1 values. Still not quite the high score you got.


ENCAVC.EXE -i ENCODE.AVS -o HPII.MP4 -qp 24 -qual full -rcmode 2pass -rcstat -psnr -ssim -br 447000 -mingop 1 -maxgop 300 -ref 8 -bref 3 -setef xf8x8,cabac,bpred,wpred -maxb 2 -enhchrp -psy 3

SSIM: Structural Similarity Index Metric 0.23
Average SSIM= 71.56947112




I obtained the same result as you with the same settings :D
Average SSIM1 = 71.570
I don't know why the first time, I didn't. Maybe not exactly the same settings

@ateme staff : is it normal that I haven't anything for SSIM result in the command line windows ? (however I put -ssim option in the settings)

couscous

[Latexxx]

I did some retesting with the same clip than previously. This time I used extra quality, xf8x8, db -2, abr, enhchrp and bitrate 200000. Resolution was same as before (640x256).

Last time I used best quality and psy 2 and psy 3 were pretty close to each other. 3 blocked more than 2 but looked sharper. It was pretty impossible to say which one looked better.

Now with extra quality it becomes clear that psy 3 blocks too much; psy 2 looks much better than psy 3 but both look ridiculous goot considering that this is a 200 kbps one-pass encode at common 1 cd resolution. Cbr looks somewhat worse than abr but not as much worse than at best quality.

Just for kicks I did 2-pass psy2 and psy3 versions. Psy2 looks overall worse than abr version of the same clip but high motion scenes do look better than when using abr. All in all, I'd choose the abr version over 2-pass with this clip and psy2 because I really do prefer sharpness in low-motion scenes to less blurring and blocking in hi-motion scenes. The psy3 2-pass version of the clip is almost identical to the psy2 2-pass version. Psy3 could be a little bit better but it screws a very low-motion scene in the beginning of the clip much more severely than psy.

Some conclusions: psy2 and abr for 1-pass encodings. maybe psy3 for 2-pass encodings.

[dragongodz]

well i tested a few different settings with the multi-fading clip. this clip[ starts as a black picture then fades to all white then fades to a greyscale scene then the colours fade in to the scene.

resolution = 720x576 @ 25fps
pc = amd athlonxp 2400+, windows xp sp1

base command line and encoded clip to compare against
encavc.exe -i test.avs -o test1.mp4 -rcmode abr -br 300000 -psnr

setting -fgm = the fade from white to greyscale scene and greyscale to colour appeared to show the details quicker and slightly better.

setting -enhchrp = like -fgm this appeared to help show the details better for the white to greyscale fade.

setting -xf8x8 = did not appear to help much at all.

for the other fades there was no noticable difference. all mean and overall psnr values where the same given by the encoders -psnr setting. except -fgm which showed none as reported in the bugs thread.

[bobololo]

I discovered why I had lower SSIM values. The more threads the encoder uses the lower the quality; FYI to all beta testers. I used the following command line parameters and got the following SIMM 1 values. Still not quite the high score you got.


ENCAVC.EXE -i ENCODE.AVS -o HPII.MP4 -qp 24 -qual full -rcmode 2pass -rcstat -psnr -ssim -br 447000 -mingop 1 -maxgop 300 -ref 8 -bref 3 -setef xf8x8,cabac,bpred,wpred -maxb 2 -enhchrp -psy 3

SSIM: Structural Similarity Index Metric 0.23
Average SSIM= 71.56947112


After some investigation, we've found that a little bug was introduced just before the beta was built and which fix wasn't committed in time before I sent out to testers. That definitely explains why you don't reach baba's figures.

The next beta release will have this fix included.

btw: thanks for the report, we're quite afraid at first, we believed we broke something seriously :)

[bobololo]

I obtained the same result as you with the same settings :D
Average SSIM1 = 71.570
I don't know why the first time, I didn't. Maybe not exactly the same settings

@ateme staff : is it normal that I haven't anything for SSIM result in the command line windows ? (however I put -ssim option in the settings)

couscous

Yes this is normal, the -ssim option isn't available in encavc (it's only present in our internal tools). But we may add it on the next beta release.

[babayaga]

I just did an encode of a rock concert (good quality source) and used psy3 for the first time, Overall the encode was rather good. however on some particularly frenetic shots there were huge blocks all over. This detracted from the otherwise quite good quality of the encode.

E:\encavc-beta2-1\encavc.exe -i E:\clip.avs -o E:\clip.mp4 -br 900000 -ref 3 -bref 3 -mingop 48 -maxgop 240 -qual best -enhchrp -rcmode 2pass -maxb 3 -deblock -6 -setef ipred,ppred,bpred,wpred,cabac,part,hpel,qpel,xf8x8,deblock,csm

[edit] It apears that the blocks usually apear on mostly-flat gradients with few details, the reason I was seeying them during high-motion shots was motion blur.
Could you please upload your clip to ftp://mood.ateme.net/incoming ? I'm interested in seeing those huge blocks.

[acidsex]

Ok, only have done a couple of encodes since I just got my beta login this morning and my initial thoughts are: WOW! I test a 2 minute clip 320x240 and got 30fps encode on the same machine that only got 10-15 fps with the first beta. Quality output was awesome.

Second clip I tested was 1280x720 and was much quicker than I expected and quality again, was outstanding.

I used fairly easy commands and plan to make them more complex later tonight.

I have some Lynda.com tutorial files in the mov format 880x660 that I would like to encode. Now with the current offering in Recode, if I use the Cinema AVC profile and a bitrate of 2.00, I can still see everything clearly but the file size is almost twice the size of the original. If I drop the bitrate to half that, my video becomes blurry and the text is hard to make out.

Can I use AviSynth to open a QT file? Hopefully I can and then I can see if the quality will improve with this latest beta.

[Soulhunter]

MP4 splitter: It doesnt support QT7 files, but I was told that its the fault of QT (not spec-conform). However the support for QT7 files would be a nice addition!

Encoder: Damn, good work guys! The quality improvement is big enough to notice it even without doing lots of metric tests. And I get around 4fps for a 1024x576 encode (-qual best) on my XP2800, which is damn nice as well!

Film grain modeling: Well, it doesn't seem to work, or at least not like what I expected. If I feed a grainy source and encode it at low bitrates, the result looks very smooth, whether I use "-fgm -fgboost 1" or "-fgm -fgboost 100". Also I've noticed that the denoising is auto-enabled when using film grain modeling, is this the pre-defined behavior?

The denoiser: It seems that high motion/temp values cause ghosting and "mismatches". But high spatial values work well, perhaps the max value is still too weak as it leaves some noise/grain. In my opinion there is much to improve, because AVS filters like Deen() still work a lot better! BTW as the codec does frequency transforms anyway, wouldn't it be possible to implement something similar to FFT3D without getting a significant speed drop?


Bye

[IgorC]

Preview of first day. Short clip (47 seconds)1136 frames : 720x304, 23.976. Bitrate 715 kbit/s. Progressive

Decoder didn´t crash but it was mentioned that speed of decoding is slow.

encavc.exe -i mtx20pj.avs -o 1.mp4 -qual extra -rcmode 2pass -br 715000 -psy 3 -deblock -2 -enhchrp -ref 16 -mvrange +512 -maxb 3 -setef xf8x8 -bref 3 . SSIM 79.80

encavc.exe -i mtx20pj.avs -o 2.mp4 -qual full -rcmode 2pass -br 715000 -psy 3 -deblock -2 -enhchrp -ref 16 -mvrange +512 -maxb 3 -setef xf8x8 -bref 3 . SSIM 80.21

encavc.exe -i mtx20pj.avs -o 2.mp4 -qual extra -rcmode 2pass -br 715000 -psy 3 -deblock -2 -enhchrp -ref 16 -mvrange +512 -maxb 2 -setef xf8x8 -bref 16 . SSIM 79.80 This encoding has a fewest artefacts. Maybe because of large numbre of bref. But identical ssim result for ref:bref - 16:3 and 16:16

encavc.exe -i mtx20pj.avs -o 2.mp4 -qual best -rcmode 2pass -br 715000 -psy 3 -deblock -2 -enhchrp -ref 16 -mvrange +512 -maxb 2 -setef xf8x8 -bref 16. SSIM 79.72. The same settings but with psy 2 gives 79.44. It's hard to spote difference between psy 2 and psy 3. Psy 2 is slightly sharp but there're more blocks, while psy 3 aparently good looking but some smooth details. SSIM give slightly more scores to Psy 3 cause it likes more smooth.

Looks like film grain is useless for low bitrates. Only fewest first frames received a low quantizers (it'look promise for high bitrate) and a good film grain, after it all frames slightly lacked details. SSIM 78.69.

tonight going to leave CPU encoding some bigger videos (interlaced material).

[ChronoCross]

so I finished my first full length anime episode test on it and I have to say that I am suberbly impressed with ateme's work. My encoding was as follows.

Resolution: 1280x720
Final filesize: 416MB 2498kb/s
Target Filesize: 657MB 3944kb/s

Command Line:(LigH actually pointed out that I got the max and minqp switched but interesting enough it only mattered slightly as it produced some blocking around edges.)
encavc.exe -i F:\DOT_HACK_SIGN_V6_BONUS\VIDEO_TS\HackAVCTest.avs -o C:\HackAVCTest.mp4 -qual best -rcmode 2pass -maxqp 1 -minqp 51 -mingop 1 -maxgop 300 -br 3944000 -psy 0 -deblock -2 -setef ipred,ppred,bpred,wpred,cabac,deblock,part,hpel,qpel,xf8x8 -adaptdbk -maxb 2 -enhchrp -par 1:1 -ref 2 -bref 2 -priority normal -thread 1 -fgboost 1.0

The thing that most stood out for me is how there is little to no blocking in areas where there is large amounts of the same color(sky for example) oftentimes in xvid these become blocky ever so slightly but in this it's not even noticeable.

Clip: I'd put up one but I'm afraid my skills with mp4 are a little lacking. I tried exporting it to mkv and then to avi but something gets fubared in the process.Can anyone give a small tut of the necessary programs to either cut the mp4 or make the mp4 to avi so I can make an avi sample?

[Manao]

Chronocross : the encoder missed the target bitrate in your last encode, isn't it ?

Soulhunter : in order to modelize noise, you need to identify it. Usually, it is done by denoising and substracting the original video with the denoised one. And since the purpose of noise modelization is not to eliminate noise during the encoding process, and recreate it during the decoding stage, denoising the video is expected.

Acidsex : you can open QT video in avisynth. Have a look here : http://www.avisynth.org/QuickTime

[Soulhunter]

Soulhunter : in order to modelize noise, you need to identify it. Usually, it is done by denoising and substracting the original video with the denoised one. And since the purpose of noise modelization is not to eliminate noise during the encoding process, and recreate it during the decoding stage, denoising the video is expected.
Hmm, I assumed it would compare the raw frame with the coded one to measure n' recreate the grain/noise that was lost by compression (quantization and in-loop filtering). The way its implemented now, it can only work if you use strong denoising values. But this again would need a very smart denoiser to work perfectly (not to mention a possibility to preview/tweak the denoising values) So, wouldnt the raw/coded subtract method (if something like this is possible) work much better than the current one? Coz, its "auto-adjusting" itself to the bitrate/compression n' compensates the real/actual loss of noise/grain!?


Bye

[couscous]

I've made an other test with the beginning of the LOTR 3. I've just wanted to test the "grain" feature.
clip encoded : 1431 frames

clip with no "grain" feature :
-qp 24 -qual extra -rcmode 2pass -br 447000 -mingop 1 -maxgop 300 -ref 8 -bref 3 -setef xf8x8 -maxb 2 -enhchrp -psy 3 -deblock 2 -adaptdbk -priority idle

time : 9 min 09
bitrate : 446.47 kb/s
SSIM 1 result : 72.71643213

clip with "grain" feature :
-qp 24 -qual extra -rcmode 2pass -br 447000 -mingop 1 -maxgop 300 -ref 8 -bref 3 -setef xf8x8 -maxb 2 -enhchrp -psy 3 -deblock 2 -adaptdbk -priority idle -fgm

time : 11 min 50
bitrate : 446.37 kb/s
SSIM 1 result : 71.55612729

When I play the clip with MPC I don't see much difference...

@ateme staff :- in the babayaga settings I see the "-rcstat" feature. For us beta testers, this feature doesn't exist, does it ? Will it be included in the next beta package ?
- is it possible to pause the encoder and resume it in the command line windows (or to break it)?

@all : is it possible to save the info that is in the command line windows in a .txt file for exemple ?

[Mr_Schizo]

@all : is it possible to save the info that is in the command line windows in a .txt file for exemple ?
sure! just copy&paste it into the txt

[couscous]

sure! just copy&paste it into the txt

Thanks ! I've never seen the "right click" in the command line windows... :rolleyes:

[ChronoCross]

Chronocross : the encoder missed the target bitrate in your last encode, isn't it ?

Yeah by a mile. I restarted the same test thios time with the settings fix LigH pointed out. I'll post again once it finishes and let you know if it still misses the target bitrate.

[Sagittaire]

OS: WinXP Pro SP2
Config: Sempron 2500+ O/C 1750@2100 Mhz

Day 2: HDTV 1080i interlacing demo
encavc: 1.2.0.14
Ateme H264 Decoder: 2.0.1.0
Ateme MPEG-4 Parser: 1.2.5.2

French HDTV for French codec: http://multimediacom.free.fr/Video/1080i.mp4
Source MPEG2 1920*1088*25 interlaced 15 Mbps
I don't know if I use the good setting but interlaced -> deinterlaced (ateme parser + ateme dec and deinterlacing process) playback is not good for me. Source seem very good but it's very difficult for me to make good encoding (encoding with and without MPEG2 deblocking, with various deblocking treshold ... ). If you want source it's possible (1.9 Go for 18 min).

Video=Mpeg2Source("d:\Mes dossiers\Download\alt.binaries.hdtv\azerty.d2v", idct=2, iPP=true, cpu=4, moderate_h=20, moderate_v=20)
Video=Crop(Video,0,0,0,-8)
video=trim(video,0,749)
return video

encavc.exe -i hdtv.avs -o 1080i.mp4 -qual extra -setef interlaced,xf8x8 -qp 25 -deblock 0 -ref 5 -bref 5 -deblock 0 -enhchrp -psy 3 -psnr -priority idle

Vive la France ... ;-)

[Manao]

@all : when testing interlaced encoding, we came to the conclusion that :
*interlaced alone provides a worse quality than progressive, because the whole clip isn't necessarily interlaced ( slow motion leads to a progressive picture ).
*paff is often on par with progressive. There again, even if the interlaced support with paff is more adaptive, it's not enough : some part of the frame can be showing interlacing, while others look progressive.
* mbaff is systematically better than progressive, and the margin increases with the motion in the clip ( which is of course to be expected ).

So, Sagittaire, add mbaff to interlaced in the setef flags, and it should help a lot.

[Sagittaire]

I try it too (mbaff and/or pbaff) but impossible to reproduce the MPEG2 source quality (interlaced but playback MPEG2 is beautifull)

I will try in AVC lossless mode for real comparison interlaced -> deinterlaced

[dragongodz]

tested default settings with ABR and CBR. found a scene change that shows a real difference in the advantage of ABR blocking less.

Resolution : 720x576 @ 25.00 fps
Length : 141 Frames
Quality : Best
Target Bit Rate : 500 kb/s (cbp size 224 kB)

note that i did this small section so as to provide a small download for anyone wanting to look at it. CBR undersized and ABR oversized the target bitrate. however what you see is about the same as it was with a longer encode so should give an idea of what i mean.

http://rapidshare.de/files/2500233/abr-cbr-scenechange.zip.html

[Sagittaire]

little blind test in progress with that:

# custom scaling matrix

# 4x4 intra luma
16, 17, 18, 19,
17, 18, 19, 21,
18, 19, 22, 25,
19, 21, 25, 32

# 4x4 intra chroma
16, 17, 18, 19,
17, 18, 19, 21,
18, 19, 22, 25,
19, 21, 25, 32

# 4x4 inter luma
20, 21, 22, 24,
21, 22, 23, 27,
22, 23, 38, 32,
24, 27, 32, 40

# 4x4 inter chroma
20, 21, 22, 24,
21, 22, 23, 27,
22, 23, 38, 32,
24, 27, 32, 40

# 8x8 intra luma
16, 16, 16, 16, 17, 17, 18, 19,
16, 16, 16, 16, 17, 18, 19, 20,
16, 16, 16, 17, 18, 19, 20, 22,
16, 16, 17, 18, 19, 21, 23, 26,
17, 17, 18, 19, 21, 24, 27, 31,
17, 18, 19, 21, 24, 28, 33, 40,
18, 19, 20, 23, 27, 33, 42, 51,
19, 20, 22, 26, 31, 40, 51, 64

# 8x8 inter luma
20, 20, 20, 20, 21, 22, 23, 24,
20, 20, 20, 20, 21, 22, 24, 25,
20, 20, 20, 21, 22, 24, 26, 28,
20, 20, 21, 22, 24, 27, 29, 32,
21, 21, 22, 24, 28, 31, 34, 39,
22, 22, 24, 27, 31, 37, 42, 49,
23, 24, 26, 29, 34, 42, 52, 60,
24, 25, 28, 32, 39, 49, 60, 80

and that:

deblock strength [-6;+6]

encavc.exe -i Encodage.avs -o NDAVCHP-X-450.mp4 -qual extra -rcmode 1st -log 1pass.log -br 447000 -deblock X -ref 16 -bref 16 -setef xf8x8,csm -csm sag.txt -enhchrp -psy 3 -psnr -priority idle
encavc.exe -i Encodage.avs -o NDAVCHP-X-450.mp4 -qual extra -rcmode 2nd -log 1pass.log -br 447000 -deblock X -ref 16 -bref 16 -setef xf8x8,csm -csm sag.txt -enhchrp -psy 3 -psnr -priority idle

encavc.exe -i Encodage.avs -o NDAVCHP-X-900.mp4 -qual extra -rcmode 1st -log 1pass.log -br 896000 -deblock X -ref 16 -bref 16 -setef xf8x8,csm -csm sag.txt -enhchrp -psy 3 -psnr -priority idle
encavc.exe -i Encodage.avs -o NDAVCHP-X-900.mp4 -qual extra -rcmode 2nd -log 1pass.log -br 896000 -deblock X -ref 16 -bref 16 -setef xf8x8,csm -csm sag.txt -enhchrp -psy 3 -psnr -priority idle

[IgorC]

I did some encoding with diferent values of deblocking -6,6 with/without adapt deblock and film grain enabled to test how encoder preserve grain.
Source : DVD 23.976 fps, resized 720x304. Bitrate 1500 kbit/s
Settings :
encavc.exe -i mtx20pj.avs -o d2.mp4 -qual fast -rcmode 2pass -br 1500000 -psy 3 -deblock -2 -enhchrp -ref 8 -mvrange +512 -maxb 2 -setef xf8x8 -bref 3 -fgm -adaptdbk
Visually deblock -2 was best for this source. I coudln´t spote difference if adaptive deblock was enabled or not. Maybe custom matrix will improve quality.

Xvid 1.1 beta 2 (MPEG matrice)

Results :
Ateme http://img85.echo.cx/img85/6697/m22ne.th.jpg (http://img85.echo.cx/my.php?image=m22ne.jpg)

Source http://img85.echo.cx/img85/511/avs1jd.th.jpg (http://img85.echo.cx/my.php?image=avs1jd.jpg)

Xvid http://img15.echo.cx/img15/4487/xvid7xw.th.jpg (http://img15.echo.cx/my.php?image=xvid7xw.jpg)

Comments : During playback Xvid looks more natural.

[Manao]

IgorC : your codec configuration isn't homogenous. Rather try : -rcmode 2pass -br 1500000 -qual good -enhchrp -setef xf8x8 -ref 2 -psy 2 -deblock -2 -fgmAdaptive deblock, as stated in the 'Bugs & Issues' thread, and as you remarked, only has a placebo effect for the moment.

[708145]

Hi folks,

I'm testing an aspect which so far nobody did mention so much. I started with 2 targets:
1) a full featured movie should fit on a DVD5 and
2) My computer should be able to play it with 25fps

The first condition leads to approx. 5Mbit/s and the second means probably not all options are possible on my 1800+.

I'm testing with a quite difficult source (VQEG parkrun) which means that what I can reach with this material is quite probable to be possible with other material as well.

I did a few encodes with various settings from good to full at several resolutions as well as with and without 8x8. All encodes have in common that they use only 3 references.
The playback speed of the clips encoded with defaults "best" + 8x8 can be found below:
25fps playback in 360p
25fps playback in 432p
21fps playback in 576p
15fps playback in 720p

This leaves me with resizing to 432p for atemes (and x264 as well I guess) encodes.

Since I want to estimate the quality I reach on a true 720p display I compare the upscaled version to the source.
It looks quite blurry (for obvious reasons) but the SSIM is between 82 and 85.

edit: just computed the average: It's 85.4 due some good scores at the end of the clip :D

I'll try to optimize the settings for this purpose in the following week.
Also I'll compare to X264 and XviD under the same constraints.

bis besser,
Tobias

[IgorC]

@Manao I'll try to use less or more stable setting
I tried another one
encavc.exe -i mtx20pj.avs -o m2extra.mp4 -qual extra -rcmode 2pass -br 1500000 -psy 3 -deblock -2 -enhchrp -ref 8 -mvrange +512 -maxb 2 -setef xf8x8 -bref 3 -fgm

There´re some artefacts
http://img248.echo.cx/img248/5315/qextra4tm.th.jpg (http://img248.echo.cx/my.php?image=qextra4tm.jpg)

Maybe the issue is -bref 3 with -maxb 2?

[vinouz]

Hi folks,

I'm testing an aspect which so far nobody did mention so much. I started with 2 targets:
1) a full featured movie should fit on a DVD5 and
2) My computer should be able to play it with 25fps

The first condition leads to approx. 5Mbit/s and the second means probably not all options are possible on my 1800+.
[...]
25fps playback in 432p
21fps playback in 576p
[...]
This leaves me with resizing to 432p for atemes (and x264 as well I guess) encodes.


With this resolution, the target size is certainly more a CD.

[708145]

With this resolution, the target size is certainly more a CD.

yeah! 720p on 1CD would be nice but is just impossible right now.

And no, I'm not talking about DVD quality here, target is more like what 16Mbit/s MPEG2 looks like.

Here a couple of more results:
85.48 (average SSIM0) for ateme (768x432)
85.23 (average SSIM0) for XviD (1024x576)

The XviD file looks a bit better though. I guess its due to the higher resolution :p
The ateme file is more blurry.

So they are really close in this aspect, which to remind you is maximum possible quality at 720p display resolution at 25p on a AXP1800+.

Now tuning the results a bit... maybe anamorphic will help a bit.

bis besser,
Tobias

[IgorC]

Ateme GUI has a bug with deblock option. if I click two times it writes to CLI 'deblock' two times

What if I'll encode with this custom matrix? I got it from qm2 for x264. But qm2 for x264 in addition has custom matrix for lumaU,V chromaU,V. Ateme has only luma and chroma. I don't know if it will be correct to use this matrix. Anyway I'm going to try some combinations like this one.
Please correct me if the formats of number is right. space beween coma and numbers etc.


# qm2 for H.264 custom scaling matrix

# 4x4 intra luma
7,16,22,24,
16,22,24,28,
18,22,27,33,
22,24,32,47

# 4x4 intra chroma
7,16,22,24,
16,22,24,28,
18,22,27,33,
22,24,32,47

# 4x4 inter luma
13,15,17,18,
15,17,18,20,
17,18,21,22,
18,20,22,25

# 4x4 inter chroma
13,15,17,18,
15,17,18,20,
17,18,21,22,
18,20,22,25

# 8x8 intra luma
7,13,16,18,22,22,24,28,
13,13,18,20,22,24,28,31,
16,18,22,22,24,28,28,32,
18,18,22,22,24,28,31,33,
18,22,22,24,27,29,33,40,
22,22,24,27,29,33,40,48,
22,22,24,28,32,38,47,57,
22,24,29,32,38,47,57,69

# 8x8 inter luma
13,14,15,16,17,17,18,19,
14,15,16,17,17,18,19,20,
15,16,17,17,18,19,20,21,
16,17,17,18,19,20,21,22,
17,17,18,19,21,22,22,23,
17,18,19,20,22,22,23,25,
18,19,20,22,22,23,25,26,
19,20,21,22,23,25,26,27

[Blue_MiSfit]

I'm amazed at the HD performance. I took a 1080i ntsc transport stream sample and did several tests.

Test 1 - 720p

LoadPlugin("C:\PROGRA~1\GORDIA~1\DGMPGDec\DGDecode.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\removegrainsse2.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\KernelDeInt.dll")

mpeg2source("C:\Documents and Settings\Blue_MiSfit\Desktop\torrents\hdtv.d2v")

removegrain(mode=1)

KernelDeInt(order=1,sharp=true)

LanczosResize(1280,720)


CLI was as follows:

encavc.exe -i 720p.avs -o 720p.mp4 -qual extra -rcmode 2pass -br 3000000 -deblock -2
-psy 3 -ref 5 -bref 5 -par 1:1 -setef xf8x8 -priority idle -mingop 10 -maxgop 300


This encode turned out VERY well. In fact, I am hard pressed to find differences on playback when viewed on my 1024x768 CRT. The deinterlacing seems to have worked perfectly, and playback (although not perfect) is almost totally smooth.

I did another encode at 1024x576 (native screen size), also at 3 mbit, and this turned out well also, with a bit of lost detail due to the lower resolution.

When I tried to process the 1080i unresized at 8.5 mbit, and still interlaced with the following command:

encavc.exe -i 1080i.avs -o 1080i.mp4 -qual extra -rcmode 2pass -br 8500000 -deblock 1
-psy 3 -ref 2 -bref 2 -par 1:1 -setef xf8x8, interlaced -priority idle -mingop 4 -maxgop 300 -bff


Playback was a slideshow (as expected), but there were quite a few interlacing artifacts. DGIndex reported the file as being bff interlaced content, so I think I chose the proper setting there. I am not familiar with encoding interlaced content at all - suggestions?

Amazing though, at 720p I really cannot emphasize enough how nice the video looked - and it played back at almost full speed. All at 3 mbit, the original MPEG-2 ts had a bitrate of near 20 mbit!!

BTW, I was using the 2005_06_19 build of ffdshow to decode.

H.264-HP is way too cool.

-MiSfit

[Manao]

Blue_MiSfit : once again, i can't emphasis hard enough the fact that -setef interlaced used alone should not be used, because it is unefficient ( in comparison to not using it ). -setef paff or mbaff will yields far better results.

And to go on with that feature : interlaced / paff / mbaff don't deinterlace the video, and don't allow it to be shown progressive on playback. On the contrary, they are specifically designed to efficiently encode interlaced content and preserve as good as possible the interlaced nature of the source.

And, EDIT : since i just saw your own edit, once and for all FFDSHOW CAN'T DECODE PROPERLY INTERLACED CONTENT

[Blue_MiSfit]

:) Sorry about that, I haven't read this whole thread yet, just figured I would spit out test results!

[Sergei_Esenin]

I finished watching the entire encode I made of the full DVD Go (http://www.imdb.com/title/tt0139239/), preprocessed and upscaled to 976x416 with Didee's IIP script before encoding to enhance apparent detail. I used the pretty basic settings:

encavc.exe -i Go.avs -o "J:\GO\Go.mp4" -qual best -rcmode 2pass -qp 25 -br 1600000 -minqp 4 -psy 3 -enhchrp -ref 4 -bref 4 -setef xf8x8

I was expecting to see some blocking and artifacts in the backgrounds of some lower-bitrate segments, since the film contains several "rave club" scenes with many two-second cuts and the bitrate of 1600000 is slightly low for this source due to that and the preprocessing. The same film previously encoded with x264 rev. 235 had some blocking in largely static scenes at 1700000, so I was pleasantly surprised that the Ateme encode looked uniformly natural throughout. Very impressive, and my only disappointment is not having some criticism and more feedback to give. :D The only blocking was during those fast multiple scene changes during raves, which is to be expected and is unnoticeable during normal-speed playback.

My only issue so far is the same for all AVC codecs, and is mentioned before by others: even giving extremely large bitrate in some encodes, no current AVC implementations will preserve as much fine detail as ASP codecs with high bitrates and custom matrices do. There is always more smoothing of fine detail, I suppose because of the matrices used by default in current AVC encoders. It would be useful if a final release product would include a "high detail" or similar option, tuned to preserve finer details at high bitrates by using a custom matrix set and encoding options which complement it. Given all the talk about custom matrices with various encoders right now, it seems like a feature which might be very welcome in a final release product. I recognize that it wouldn't be of as much interest to the casual mainstream user though, as it is to us encoding nuts, so I can understand why little time has been spent on such matters yet.

I did notice that the Ateme decoder filters are able to acheive smooth playback of a 1280x768 clip which causes stuttering under ffdshow on the same system, so again I'm impressed. The only issue I've had with the Ateme decoder so far isn't a real issue since it's due to my own quirk; I know it's intended to decode AVC from the MP4 container, but I've made many Matroska files with AVC video and was disappointed that the Ateme decoder could not be used with them. A quick look in Graphedit confirmed no ability to connect. At least the old Nero decoder works fine for them. :) I do hope future versions of the Nero decoder won't change this, though.

Hopefully I'll have better feedback (and big screenshots) when my grainy Veronica Mars (http://www.imdb.com/title/tt0412253/) 1080i TS is finished encoding. -fgm on a very grainy HD source should be fun. :sly: After that, some analogue captures to throw analogue noise at it...

[Tommy Carrot]

My only issue so far is the same for all AVC codecs, and is mentioned before by others: even giving extremely large bitrate in some encodes, no current AVC implementations will preserve as much fine detail as ASP codecs with high bitrates and custom matrices do. There is always more smoothing of fine detail, I suppose because of the matrices used by default in current AVC encoders.
Nah, the main reason is the deblocking filter, which has a strong smoothing side-effect (similarly to the ASP's postfiltering). If you disable it, the AVC codecs will behave similarly to the ASP codecs (some blocking, the image is not so clean, but the details are intact). Also, someone previously reported that -psy 3 can harm the sharpness of the image in some circumstances.

[vinouz]

yeah! 720p on 1CD would be nice but is just impossible right now.

And no, I'm not talking about DVD quality here, target is more like what 16Mbit/s MPEG2 looks like.

Here a couple of more results:
85.48 (average SSIM0) for ateme (768x432)
85.23 (average SSIM0) for XviD (1024x576)

The XviD file looks a bit better though. I guess its due to the higher resolution :p
The ateme file is more blurry.

So they are really close in this aspect, which to remind you is maximum possible quality at 720p display resolution at 25p on a AXP1800+.

Now tuning the results a bit... maybe anamorphic will help a bit.

bis besser,
Tobias


Don't get me wrong, I'm talking about the fact that you resize your 720p to 432p. Then you have almost three (2.78) times less pixels. Encoding 432p on a 5m DVD is not something particularly hard to attain with any good ASP encoder, even SP ones.

And, as you show it, SSIM scores are relevant up to a point. fractional point differences on scores of more than 80 seem anecdotic, to say the less.

But it's a good comparative on the total deal of output quality you can get for a given decode power, a given size, between different codecs.

In my opinion, unfortunately, these tests are not very useful, considering that you test only your machine. Any hardware decoder will have adequate logic to seamlessly decode HD 1080i, 1080p or 720p content as long as it has its FULL HD ou HD sticker on it. And specialized chips can do this easily nowadays. Not to mention future home appliance all-purpose chips as the STI CELL processor, that can handle 48 DVD MPEG-2 streams (decode) at the same time. And it's not a specialized chip for AVC.

Anyway, for the test that it is, it gives a good warning to the average encoderjoe, that is not just to consider the more efficient codec, but the more efficient at the average PC decoding power of today.

And your 432p AVC resized to 720p (lanczos, bicubic (a=?), bilinear ?) scores against 576p resized to 720p ASP ones are interesting.

Thanks,

Vincent.

[708145]

Don't get me wrong, I'm talking about the fact that you resize your 720p to 432p. Then you have almost three (2.78) times less pixels. Encoding 432p on a 5m DVD is not something particularly hard to attain with any good ASP encoder, even SP ones.

And, as you show it, SSIM scores are relevant up to a point. fractional point differences on scores of more than 80 seem anecdotic, to say the less.

But it's a good comparative on the total deal of output quality you can get for a given decode power, a given size, between different codecs.

In my opinion, unfortunately, these tests are not very useful, considering that you test only your machine. Any hardware decoder will have adequate logic to seamlessly decode HD 1080i, 1080p or 720p content as long as it has its FULL HD ou HD sticker on it. And specialized chips can do this easily nowadays. Not to mention future home appliance all-purpose chips as the STI CELL processor, that can handle 48 DVD MPEG-2 streams (decode) at the same time. And it's not a specialized chip for AVC.

Anyway, for the test that it is, it gives a good warning to the average encoderjoe, that is not just to consider the more efficient codec, but the more efficient at the average PC decoding power of today.

And your 432p AVC resized to 720p (lanczos, bicubic (a=?), bilinear ?) scores against 576p resized to 720p ASP ones are interesting.

Vincent.

All right, I guess I should switch to another source :) I told this is a particularily hard one, others should look alright at much lower rate.

For the protocol: xvid needs ~23Mbit/s at quant4 (which makes it indistinguishable/transparent to the source for me ;) , so 5Mbit/s is quite a compression already.

Further results:
ateme scaled to 576p yields an SSIM0 of 87.22 which doesn't playback at 25p and still has noticable blurring in some parts!
Just for reference: x265 (aka x264r265) yields 86.98 in 576p.

BTW, I use Lanczos4 for resizing (in both directions). I know it's not metric optimal but that's also not what I'm optimizing here.
I provide the SSIM results just to get a relative idea since a difference of 2 points is noticable ususally.

bis besser,
Tobias

[superdump]

*puffs* Here goes.

I've done a fair amount of testing in the background and I'm now going to post all of my results and thoughts here so that everyone can see what I think of what I'm seeing. :) Your opinions may differ to mine, that doesn't invalidate mine or yours.

The clip I'm using is a random section I chose from Lord of the Rings: Return of the King - Extended Edition, disc 2. The source is cropped and resized to 720x288, 25 fps and frames 30000 - 31999 are taken. The target bit rate is 400kbps and all encodes are conducted using 2 passes. At the moment I'm only interested in quality, not speed. The scene involves a group of orcs carrying off Frodo after he has been 'stung' by Shelob and cocooned in spider web. Sam looks on helplessly. The next scene involves Pippin trying to stop Denethor from burning his son, Faramir, alive.

EncAVC is in blue, x264 is in red. (http://www.swains.plus.com/superdump/blue-encavc-red-x264.png) Note the unusual opposite reaction in the rate control which prompts the PSNR increase/drop approximately 1/3 of the way through.

Testing basic options to find a basic set for best quality. (http://www.swains.plus.com/superdump/refining.html)

Retesting some options which had possible anomalous results due to having a bad base (using fastest quality setting for example). (http://www.swains.plus.com/superdump/refining-2.html)

Testing of options that will require visual 'tuning' with the new basic set of options. (http://www.swains.plus.com/superdump/refining-3.html)

Comments on deblocking. (http://www.swains.plus.com/superdump/comments.txt)

Comments on psychovisual levels. (http://www.swains.plus.com/superdump/psycomments.txt)

Next up to be tested are denoising and then film grain but my basic choice of settings before I do this are as follows:

-qual full -rcmode 2pass -psy 3 -ref 3 -maxb 2 -setef xf8x8 -enhchrp -bref 2 -deblock -2

[Sagittaire]

@ superdump

1) for encavc bref < ref ... if you want see real beref impact use always ref=16

2) If you want test Ateme RC use more than 10 000 frames. Use x264 multipasse with qcomp = 0.75 for reference ...

[Manao]

Sagittaire : there were 3 ref, so 2bref is ok. And what makes you think that our RC doesn't need testing with clips with less than 10000 frames :p

[Sagittaire]

encavc.br2.mp4 33.6986 39.1560 45.0226 60.19 -qual fastest -clref deblock -maxb 0 -psy 0 -bref 2
encavc.br3.mp4 33.6986 39.1560 45.0226 60.19 -qual fastest -clref deblock -maxb 0 -psy 0 -bref 3
encavc.br4.mp4 33.6986 39.1560 45.0226 60.19 -qual fastest -clref deblock -maxb 0 -psy 0 -bref 4
encavc.br5.mp4 33.6986 39.1560 45.0226 60.19 -qual fastest -clref deblock -maxb 0 -psy 0 -bref 5

I think that here ref=1 ...


Fast first pass
The progression percentage of the first pass on long encoding will seem to jump. It's normal. The very fast first pass is enabled on clips longer than 10000 frames. On shorter clip, the first pass is done at a quality level of min(good, requested level).

[LigH]

The more I read about the relation between "ref" and "bref", the more I suspect if "ref" means forward predictions only, or the sum of forward and backward predicted refrences, because I don't see much reason why any bref>ref has no different effect.

[Manao]

Sagittaire : i thought you were referring to the command line posted by superdump in his post

LigH : 'ref' defines the max number of references in the L0 list. 'bref' defines the number of references in the L0 list that will be used for bframes. They are separated because reference frames slows the codec down, and are not necessarily as helpful for bframes than for pframes.

[LigH]

So the documentation is (inexact..wrong) regarding this point: The readme for encavc said: "ref = forward references, bref = backward references". I think I shall rename these options in my GUI, too.

[Manao]

Indeed the documentation is wrong. I'll update the sticky accordingly.

[couscous]

Ok, here I go.
I've made a test on a 45 min's length clip. This clip is the beginning of the LOTR3.
My will was to compare Ateme's encoder to x264 rev267's encoder on a long clip at low bitrate (450kb/s).

Here are my settings for ateme's encoder :
-qp 24 -qual extra -rcmode 2pass -psnr -br 447000 -mingop 1 -maxgop 300 -ref 5 -bref 3 -setef xf8x8 -maxb 2 -enhchrp -psy 3 -deblock 2 -adaptdbk -priority idle


* Encoding summary

Resolution : 720x304 @ 25.00 fps
Length : 67813 Frames
Quality : Extra
Rate Control : 2pass
Target Bit Rate : 447 kb/s
Init Quantiser : 24 [0 - 51]
Gop Size Min - Max : 1 - 300 (closed)
Process Priority : Idle [1 thread(s)]


* Encoding Features

- prediction : ipred ppred bpred(2) wpred : using 5:3 ref(s)
- entropy : cabac
- subsampling : hpel qpel
- mb partition : 16x16/16x8/8x16/8x8
- interlaced : disabled
- misc : deblock(2:adaptive) xf8x8 enhchrp psy(3)

Here are my settings for x264 rev267's encoder :
"G:\Multimedia\Encodage Video\x264\x264.exe" --bitrate 447 --pass 1 --stats "G:\Multimedia\Encodage Video\test codecs\Encodage\Encodage-x264\statsx264.log" --weightb --bframe 2 --b-pyramid --ref 5 --me "dia" --subme 4 --analyse "all" --8x8dct --progress -o NUL "G:\Multimedia\Encodage Video\test codecs\Script Encodage\Encodage-LOTR3.avs"

"G:\Multimedia\Encodage Video\x264\x264.exe" --bitrate 447 --pass 3 --stats "G:\Multimedia\Encodage Video\test codecs\Encodage\Encodage-x264\statsx264.log" --weightb --bframe 2 --b-pyramid --ref 5 --me "hex" --subme 5 --analyse "all" --8x8dct --progress -o NUL "G:\Multimedia\Encodage Video\test codecs\Script Encodage\Encodage-LOTR3.avs"

"G:\Multimedia\Encodage Video\x264\x264.exe" --bitrate 447 --pass 2 --stats "G:\Multimedia\Encodage Video\test codecs\Encodage\Encodage-x264\statsx264.log" --weightb --bframe 2 --b-pyramid --ref 5 --me "hex" --subme 6 --analyse "all" --8x8dct --progress -o "G:\Multimedia\Encodage Video\test codecs\Encodage\Encodage-x264\x264-450-LOTR3-bis-bis.mp4" "G:\Multimedia\Encodage Video\test codecs\Script Encodage\Encodage-LOTR3.avs"

Here are the results:
ateme encoder :

-- Start processing pass 1 / 2
* 100.00% completed
* 67813 frames processed @ 29.83 fps
-- Start processing pass 2 / 2
* 67812: encoding @ 5.26 fps - bitrate 374.42 kb/s - 100.00% completed
* 67813 frames encoded @ 5.18 fps - average bitrate 446.97 kb/s
* mean psnr 42.63 dB [41.45|47.45|47.75], overall psnr 41.42 dB (buggy as says Manao)

Encoding complete (time elapsed 04:36:51)

x264 encoder :

pass1 : encoded 67813 frames, 8.98 fps, 451.33 kb/s

pass2 : encoded 67813 frames, 8.41 fps, 447.14 kb/s
pass3 : encoded 67813 frames, 6.21 fps, 447.10 kb/s
x264 [info]: PSNR Mean Y:41.19 U:47.55 V:47.95 Avg:42.44 Global:41.12 kb/s:447.0
Encoding complete (time elapsed about 07:22:00)
Results SSIM1 :
Ateme encoder : Average SSIM= 77.10644624
x264 rev 264 encoder : Average SSIM= 75.48093325

I've made an analyse of the data, and here are the results:
ECARTYPE-Ateme-SSIM1 = 0.01361572
ECARTYPE-x264-SSIM1 = 0.01547125

As you can see, SSIM1 is far better for ateme's encoder (but x264 is quick good too).
But what is very interesting is that ecartype of Ateme is lower which means for me that the rate control is better for Ateme's encoder (it's my opinion, at least).

I've computed also the number of frames included between two values of SSIM1 and here is the result :

http://img41.echo.cx/img41/226/differencenombredeframex264ate.png
As you can see, the number of frames between two values of SSIM1 is more important in x264 than Ateme except for 0.96 < SSIM1 < 0.98 which prove for me that this is a "issue" in x264 encoder (for me and for my eyes).

I've also compared the values of SSIM 1 and I've plot the graph corresponding.
Here are the results :
Ateme is far better at the beginning of the clip and at the end. But in the middle x264 equals Ateme or is quick better

Three examples:
the beginning of the clip:

http://img87.echo.cx/img87/3488/graphssim11100007yp.png

the middle of the clip :

http://img287.echo.cx/img287/96/graphssim130000400006fz.png

the end of the clip :

http://img102.echo.cx/img102/3791/graphssim150000600004ai.png

Now what can I say :
I've seen the two clip with MPC and I can say that Ateme is by far better than x264 (but this one is very good two). I've compared this encodage with an xvid's encodage at more than 900kb/s and I can't say which is better (maybe Ateme's one :D )

Negative points :
It seems to me that the color aren't very vivid compared to the original clip.
Sometimes, the background moves (less than x264's clip but...). I know that I can use an avisynth's filter , but if this encoder is included in Recode...

@ateme staff : is it possible to pause/resume the encoder or break it without closing the command line windows (I know this is the second time I question, but I was not sure that you saw the first this question, as I haven't had any answer). Thanks.

couscous

[LigH]

I somehow missed that during the last months of development: Could someone please point me to a description of the difference between SSIM0 and SSIM1, and what's new since SSIM 0.23?
__

Furthermore:

We have been warned that too high values for references would slow down remarkably but not gain much quality; would a pair of (max:5, bidi:3) be a quite fair comprimise?

[Manao]

couscous : don't forget that our psnr measurement is buggy in two passes. I disagree with your analysis on the two RCs : saying that x264's has an issue it leads to a greater standard deviation in SSIM than ours is not necessarily obvious, since, imho, a good rate control should be able to trash scenes where the eye can't notice the trashing ( but where the neverfailing metrics can ), which automatically leads to high standard deviation.

Anyway, it's a nice test.

Edit : LigH : SSIM0 and 1 are the 'original' SSIM, as implemented by Lefungus ( 0 -> no lumimasking, 1 -> lumimasking, 2 -> better lumimasking )

[IgorC]

SSIM0 (lumimask = false)
SSIM1 (lumimask = true)
SSIM2 (enchased by On2)
Look last comparison test http://forum.doom9.org/showthread.php?t=90784.
Difference between SSIM1 and SSIM2 isn´t that big

@couscous . You use stranges settings for x264 . Subme 4 , 5, 6? Deblock?
I didn´t get difference between x264 and Ateme H.264 bigger than 1 SSIM.

[LigH]

Thank you - knowing about On2 being involved, made me find the according thread (http://forum.doom9.org/showthread.php?s=&threadid=92532). Great! :)

[couscous]

@couscous . You use stranges settings for x264 . Subme 4 , 5, 6? Deblock?


I used the settings of Sagittaire in this thread http://forum.doom9.org/showthread.php?t=96030 but with the default debloking and more settings.
subme 4, subme 5 and subme 6 : this is to have a better speed and a good quality for the last pass.

I didn´t get difference between x264 and Ateme H.264 bigger than 1 SSIM.

Have a look at this thread :http://forum.doom9.org/showthread.php?t=90784

I think it depends of the clip and the length of this one. But for sure, I didn't use the better settings for either x264 or Ateme (It's too long, and 7 hours for a 45 mins clip, it's enough)

couscous

[IgorC]

It wasn´t my intention to go to offtopic (coparing x264 and Ateme H.264). Next time all post to other thread. But that difference is +1.23 SSIM because for Ateme was used full quality mode ( speed fps < 1 ), while for x264 wasn´t used full qualtity mode.
Do it for x264 3 pass , -uma, RDO mode. And I don't know what deblock you got

[couscous]

It wasn´t my intention to go to offtopic (coparing x264 and Ateme H.264). Next time all post to other thread. But that difference is +1.23 SSIM because for Ateme was used full quality mode ( speed fps < 1 ), while for x264 wasn´t used full qualtity mode.
Do it for x264 3 pass , -uma, RDO mode. And I don't know what deblock you got

No I didn't use Ateme in full quality mode. Only extra. And with this setting, the Ateme's encoder was by far faster. (cf my post)

[babayaga]

No I didn't use Ateme in full quality mode. Only extra. And with this setting, the Ateme's encoder was by far faster. (cf my post)
Your test is quite impressive :)
LOTR is part of my internal test batch. In this case, I target 2 CD which leads to close to 1Mbps. I've never tried pushing the limit down to 447kbps. Is it still good enough for your eyes ?

Regarding ssim and quality settings, psy 3 was reworked lately and the results are better now in extra than with the current version in the awfully slow "full" quality (have a look at http://forum.doom9.org/showthread.php?p=675511#post675511 compared to previous results in full http://forum.doom9.org/showthread.php?p=618225#post618225 ).
OPSNR will also be higher : roughly 0.1dB below the maximum that we can currently achieve.

[Andrey]

>>LigH : 'ref' defines the max number of references in the L0 list. 'bref'
>>defines the number of references in the L0 list that will be used for
>>bframes.
Oh ! Thanks for the info, Manao...
So, what recommended setting for bref is ?

Still can not find any flaws in quality of the encoder :)
I'm a bad tester :scared:

Compared noisy encode of Star Wars 4 XViD vs Atheme.
With quant 2 in XViD and corresponding bitrate (1360Kbit) in Atheme - no winner.

Tried film grain in Die Hard 3 on high bitrates. Can not distinquish encodes. So, I suppose, film grain is designed for low bitrates ? :)

Only one problem I can notice: in Die Hard on comparably high bitrate (2500Kbit, 608x304) threre are some blocks on flat areas. But XViD quant 2 makes no better, so I suppose the main reason is that source is mpeg 2, not raw video. Bitrate of 3500Kbit eliminate those blocks...

[Andrey]

>> Is it still good enough for your eyes ?
I got an answer :)
I tried to encode LOTR films some time ago with XViD...

That depends on the goal.
If you will watch it on 17" - 19" flat screen sitting on the chair in 1m from it - it will be good. In some scenes XViD has obvious moving background, but with h264 inloop filtering it will be less noticable, I think. So, VHS quality could be achieved, I should say.
But if you will try to watch it on plasma panel or large TV you will easily notice the difference...

BTW: There were some "magical" LOTR encodes, that have had extremely good quality picture with some prefiltering, that makes picture a bit (but noticable) darker. They were marked with white MPEG4 logo into right low corner...

[couscous]

Your test is quite impressive :)
LOTR is part of my internal test batch. In this case, I target 2 CD which leads to close to 1Mbps. I've never tried pushing the limit down to 447kbps. Is it still good enough for your eyes ?


Yep. The quality is not perfect but it can be seen... :)
I selected two clips of this encode (maybe the two most complicated scenes, as finally in the first 45 mins of the LOTR3 there isn't much movement).

http://rapidshare.de/files/2534130/Ateme-450-LOTR3-Encodage_45_mins-clip1.mp4.html

http://rapidshare.de/files/2534200/Ateme-450-LOTR3-Encodage_45_mins-clip2.mp4.html

couscous

(ftp ateme...income not possible in my school, I think)

[CyberGuy]

I assume that most people know this or have discovered this, but the best quality that I was able to get with the Harry Potter II clip in the Metric Benchmark Challenge was using these parameters. I know that some of the parameters are defaults and are not needed, while others are not documented or may be set higher or lower than needed.

Full (Average SSIM 2 = 71.85123533)

ENCAVC.EXE -i ENCODE.AVS -o HPII.MP4 -qual full -rcmode 2pass -qp 0 -minqp 0 -maxqp 51 -mingop 0 -maxgop 300 -br 450000 -psy 3 -deblock 0 -adaptdbk -setef ippred,ppred,bpred,wpred,cabac,deblock,subpart,hpel,qpel,xf8x8 -maxb 2 -enhchrp -par 1:1 -ref 16 -bref 16 -priority normal -thread 1 -fgboost 1.0

[Manao]

couscous : it seems we fotgot to answer you about the pause & resume encoding. It's not possible. However, you can try sysKin's trick if it does what you want : in the command window, select some text : the encoding process should stop. To resume it, right click on the same window.

[kwtc]

However, you can try sysKin's trick if it does what you want : in the command window, select some text : the encoding process should stop. To resume it, right click on the same window.


On most keyboard there is a Pause key that works perfectly for command line applications... :)

[bill_baroud]

Hello, i wanted to share my first try with some HD content.

The original clip can be found here :
ftp://ftp.ldv.e-technik.tu-muenchen.de/dist/test_sequences/
it's the "720p50_parkrun_ter.yuv" sequence, converted to mjpeg q100 and slowed down to 25fps for (almost) real time playback.
What's interesting with those sequences is that they are uncompressed, comes (almost) straight from an HD camera, sort of "real-life" test, and are copyright free.

The resulting video at 5000Kbit/s is here : http://moodub.free.fr/x264/park_2pass_5000.mp4
and the log here:
http://moodub.free.fr/x264/park_2pass_5000.log

What can i say ? it's just impressive, to think that you can put 1h30 of video on a DVD at that quality. Well there is perhaps not much motion, but the water is quite detailed, the background doesn't get too blurred, there is just a little bleeding on the moving legs...

If anybody have comments about the options to use, i'll be glad to hear them.

a note : noise was nicely removed, but i don't think it's added at playback (like ffdshow noise ?). Did i something wrong or misunderstood the film-grain modeling concept ?

[IgorC]

I did some encoding with different custom matrices but result weren't better visually or for metrics.


Setings :
"C:\m\encavc.exe" -i "C:\m\fullma.avs" -o "C:\m\q2m.mp4" -qual extra -psy 3 -mvrange 256 -enhchrp -cpb 1048576 -rcmode 2pass -br 705000 -priority below -setef deblock,xf8x8,csm -ref 8 -bref 5 -maxb 2 -deblock -2 -csm "C:\m\qmatrix2.txt"

Source : 720x304, Film 23.976, Progressive, 6004 frames.

Default (flat matrix) SSIM 76.78

# qm2 for H.264 custom scaling matrix

# 4x4 intra luma
7,16,22,24,
16,22,24,28,
18,22,27,33,
22,24,32,47

# 4x4 intra chroma
7,16,22,24,
16,22,24,28,
18,22,27,33,
22,24,32,47

# 4x4 inter luma
13,15,17,18,
15,17,18,20,
17,18,21,22,
18,20,22,25

# 4x4 inter chroma
13,15,17,18,
15,17,18,20,
17,18,21,22,
18,20,22,25

# 8x8 intra luma
7,13,16,18,22,22,24,28,
13,13,18,20,22,24,28,31,
16,18,22,22,24,28,28,32,
18,18,22,22,24,28,31,33,
18,22,22,24,27,29,33,40,
22,22,24,27,29,33,40,48,
22,22,24,28,32,38,47,57,
22,24,29,32,38,47,57,69

# 8x8 inter luma
13,14,15,16,17,17,18,19,
14,15,16,17,17,18,19,20,
15,16,17,17,18,19,20,21,
16,17,17,18,19,20,21,22,
17,17,18,19,21,22,22,23,
17,18,19,20,22,22,23,25,
18,19,20,22,22,23,25,26,
19,20,21,22,23,25,26,27 SSIM 75.96


Matrix
# 4x4 intra luma
16, 17, 18, 19,
17, 18, 19, 21,
18, 19, 22, 25,
19, 21, 25, 32

# 4x4 intra chroma
16, 17, 18, 19,
17, 18, 19, 21,
18, 19, 22, 25,
19, 21, 25, 32

# 4x4 inter luma
20, 21, 22, 24,
21, 22, 23, 27,
22, 23, 38, 32,
24, 27, 32, 40

# 4x4 inter chroma
20, 21, 22, 24,
21, 22, 23, 27,
22, 23, 38, 32,
24, 27, 32, 40

# 8x8 intra luma
16, 16, 16, 16, 17, 17, 18, 19,
16, 16, 16, 16, 17, 18, 19, 20,
16, 16, 16, 17, 18, 19, 20, 22,
16, 16, 17, 18, 19, 21, 23, 26,
17, 17, 18, 19, 21, 24, 27, 31,
17, 18, 19, 21, 24, 28, 33, 40,
18, 19, 20, 23, 27, 33, 42, 51,
19, 20, 22, 26, 31, 40, 51, 64

# 8x8 inter luma
20, 20, 20, 20, 21, 22, 23, 24,
20, 20, 20, 20, 21, 22, 24, 25,
20, 20, 20, 21, 22, 24, 26, 28,
20, 20, 21, 22, 24, 27, 29, 32,
21, 21, 22, 24, 28, 31, 34, 39,
22, 22, 24, 27, 31, 37, 42, 49,
23, 24, 26, 29, 34, 42, 52, 60,
24, 25, 28, 32, 39, 49, 60, 80 SSIM 76.44

I also encoded some video with x264 and custom matrices but since ateme decoder doesn´t play well x264 I didn't obtain SSIM results.

´Output before deblocking ´ in Ateme Decoder is swithced on by default. Why is that? At low bitrates video without PP looks not good.

[LigH]

@ IgorC:

Try to put a "CODE" vbTag around your matrices; this shall enhance the readability.

[kwtc]

´Output before deblocking ´ in Ateme Decoder is swithced on by default. Why is that? At low bitrates video without PP looks not good.


It should be grayed by default. Thus it takes the information from the stream. As far as I known, encavc never position the flag that let the decoder output the frame before deblocking it.

[Andrey]

Today tested low bitrates.
In my opinion, codec behaves very well, eliminating details it can't handle and maintaining balance between macroblocks and details...
Samples (still pics):
http://rapidshare.de/files/2554850/snapshot20050623002325.PNG.html
http://rapidshare.de/files/2554878/snapshot20050623002357.PNG.html
http://rapidshare.de/files/2554892/snapshot20050623002530.PNG.html
http://rapidshare.de/files/2554904/snapshot20050623002559.PNG.html
http://rapidshare.de/files/2554918/snapshot20050623002643.PNG.html
http://rapidshare.de/files/2554925/snapshot20050623002705.PNG.html
http://rapidshare.de/files/2554953/snapshot20050623002728.PNG.html

Res: 608x304, 20000 frames, 450Kbit
encavc.exe -i dh3.avs -o dh3.mp4 -qual extra -rcmode 2pass -br 450000 -adaptdbk -enhchrp -par 25:23 -maxb 3 -ref 4 -bref 2 -setef xf8x8

One note: rate control seems to behave a bit strange - in the last third of the clip bitrate became as high as 1.2Mbit, while visually it is lacked at the clip begining...

[superdump]

@ superdump

1) for encavc bref < ref ... if you want see real beref impact use always ref=16

2) If you want test Ateme RC use more than 10 000 frames. Use x264 multipasse with qcomp = 0.75 for reference ...

Point 1 taken. Point 2, I tested with 30000 frames and that anomaly was still present in the psnr/ssim plots. Also, what is your basis for qcomp 0.75?

[calinb]

<snip>The only issue I've had with the Ateme decoder so far isn't a real issue since it's due to my own quirk; I know it's intended to decode AVC from the MP4 container, but I've made many Matroska files with AVC video and was disappointed that the Ateme decoder could not be used with them. A quick look in Graphedit confirmed no ability to connect. At least the old Nero decoder works fine for them. :) I do hope future versions of the Nero decoder won't change this, though. Yes!!! In fact, muxing to mkv with mkvmerge / mmg GUI would be a workaround for the Ateme parser 4GB file bug/limitation, if the Ateme decoder could connect!

[Kurtnoise]

Hi,

Does anyone have already compare JM vs Ateme codecs (visual quality & metrics) ? I suppose that the Ateme devs have already made such things ;) but I ask this concerning all betas testers here. I begun some tests with the last beta (not finished yet coz I'm really busy with my job) and I would like to have some hints with the JM settings. What are the good points for a b&w noisy source ?

Thanks...

[Andrey]

Tested low bitrates.
384x192, 200Kbit
When playing fullscreen 1024x768 there are many artifacts ;), but lot of them are from downsizing and upsizing. On a small screen looks perfectly.

512x256, 275Kbit
This time managed to get ringing artifacts sometimes for the first time with this encoder. But anyway, objects and details looks very good for such a low bitrate, the blocks are mostly on flat areas or large areas with constant texture fill. Looks much better than first on a full screen.

Still no problems with the encoder. :cool:

EDIT: Still wonder, what are recommended settings for -ref and -bref ?
I can not catch a difference with 4:2 and 2:2 for example with my eyes...
Any suggestions ?

[superdump]

EDIT: Still wonder, what are recommended settings for -ref and -bref ?
I can not catch a difference with 4:2 and 2:2 for example with my eyes...
Any suggestions ?
Multiref doesn't have too great an impact on visual quality. The difference between ref 5 and ref 16 is minuscule compared to the difference between ref 1 and ref 5, but the increase is still not huge and I don't know if you'd notice it visually. As for bref, you can probably tune that setting indivdually for each number of ref and again it won't give huge increases in quality, probably not visually noticable but every little helps. :)

[Andrey]

Multiref doesn't have too great an impact...
Ok. Thanks.
But what about correct values ? To not to waste bits, I mean.
Or 4 bits are reserved for ref number anyway ?

[Manao]

Thanks to the way cabac / cavlc works, the actual cost for storing the ref index isn't 4 bits per macroblock, but a lot less because some refs are used a lot more often than others.

[Andrey]

>>Thanks to the way cabac / cavlc works,
So, the entropy coding works on whole frame including some tech data. Seems logically. :)
Thanks for the info.

[LigH]

In my opinion, a range between 5:3 and 6:4 shall be a fair comprimise between encoding efficiency and speed.

[plonk420]

how much do ssim comparisons really matter? i could put ssim results up until i'm blue in the face, now that i finally forced myself to figure out how to use it :P (and make those nifty bar graphs) -- whoda thunk the plugin didn't make a graph itself ^_^ as for visual comparisons, that might be a bit harder and more time consuming...

[dragongodz]

movie: Rebecca - http://www.imdb.com/title/tt0032976/

black and white, 720x480

encoded to 800kb/s

encode1 = defaults - 2 pass
encode2 = defaults - 1 pass VBR
encode3 = defaults - 1 pass VBR + FGM
encode4 = defaults - 1 pass VBR + MONOCHROME

comments:
first this is a rather soft pictured movie, lightly blurred in places, but most edges are reasonably solid. encode2 had some scenes where the edges where preserved better than encode1 but in general encode1 was better. encode3 and encode4 however kept quality of edges better still and overall quality was,IMHO, better than encode1 a lot of the time. so FGM and MONOCHROME do make a noticable difference to atleast this B&W movie.

[hubereevez]

Hi,
since I'm not such a powerfull tester like you guys, I hope I did nothing wrong in my command line. Hoping that helps ateme too :)
First, I'd like to thank Manao, and Kurtnoise for their works int the UniteVideo forum.
Voilà:
Two movies encoded, 10 hours for each approximativly (p4 Ht , 3 Ghz), that's good. Specially not to have to suffer clicking on the nero gui :p.
Used hybridfupp in avs. Asking me if the mvrange option has the same approach
I did not use the mp4 container, since their is no reliable tools to join 2 "h264 AVC" (credits(@50000b/s) or splitted movie) and HeAAC (splitted movie). Mkv do a great job happening such streams (video and audio).

"J:\Programmes\Encodage\Ateme\encavc.exe" -i "D:\bf\Movie.avs" -o "D:\bf\Movie.mp4" -qual extra -psy 3 -enhchrp -rcmode 2pass -br 850000 -priority realtime -psnr -setef ppred,bpred,wpred,cabac,deblock,part,hpel,qpel,xf8x8 -ref 5 -bref 3 -maxb 2 -deblock 0 -adaptdbk
-- Start processing pass 1 / 2
* 100.00% completed
* 162190 frames processed @ 40.97 fps
-- Start processing pass 2 / 2
* 162189: encoding @ 11.08 fps - bitrate 370.74 kb/s - 100.00% completed
* 162190 frames encoded @ 4.76 fps - average bitrate 849.96 kb/s
* mean psnr 48.42 dB [47.65|50.64|51.04], overall psnr 47.87 dB

-- Start processing pass 1 / 2
* 100.00% completed
* 201496 frames processed @ 47.44 fps
-- Start processing pass 2 / 2
* 201495: encoding @ 31.79 fps - bitrate 4.91 kb/s - 100.00% completed
* 201496 frames encoded @ 5.41 fps - average bitrate 644.04 kb/s
* mean psnr 46.74 dB [45.75|50.19|50.10], overall psnr 46.02 dB

I did not post the results for credits, 1Mo for 6 min and still readable !! :)

The two movies (608*368, 608*320) are just great. A really good quality (no macro block, no speed issue, no strange faces). Target size is very accurate. I do not know what to add since I'm not so familiar with PSNR value..... (but it seems buggy ?)

[JasonFly]

There was some discussion last week about the optimal setting for the -ref -bref parameters.
So I decided to make some tests.

The length of the clip is 562 frames. Seeing the results I get, I wonder if that was high enougth because I cannot get some clear conclusion. Even if that would have been surprising to find some "ideal" setting, I expected to clearly find some "good" ones, and some "bad" ones. But as you'll see with the results, that's not so easy. The bitrate was set to 1000kbps for a 720x288 framesize. Results should depend on the bitrate, that's obvious. I 'll see later if it's worth the try to do the same test for a lower and a higher bitrates.

Settings:
The idea was to test the large panel of possibilities for the -ref and the -bref settings. So I encoded the sample using 0,1,2,4,8,16 ref frames and within that, I also set the -bref setting from 0 to 16 the same way I did with the ref setting. I also tried to see the influence of bframes on the -ref / -bref setting so I launch this encode list for 0bf, 1bf, 2bf and 3bf.

Results:
It was visually very hard (impossible?) to see any real difference between all the encoded files. In this case, the only mean to put a judgment on the settings are the metrics (PSNR and SSIM). I know that some people would criticize this approach but for me it seems to be the only way. So I used the CompareYV12 and SSIM0.23 avisynth plugins. I have discovered the upgrade of SSIM recently and didn't installed it yet but I doubt the results would have been very different.
I don't doubt that you'll have understood that but just in case: I used ref"x"_bref"x" typo which correspond to the number of ref and bref.
I have bolded the Max and Min value for each category to enhance visibility.

PSNR:

|------------|---------|------------|---------|------------|---------|------------|---------|
| 0 bframes | PSNR | 1 bframes | PSNR | 2 bframes | PSNR | 3 bframes | PSNR |
|------------|---------|------------|---------|------------|---------|------------|---------|
|ref0_bref0 | 39,0497 |ref0_bref0 | 39,1937 |ref0_bref0 | 39,1956 |ref0_bref0 | 39,1974 |
|ref1_bref1 | 39,0497 |ref1_bref1 | 39,1956 |ref1_bref1 | 39,1956 |ref1_bref1 | 39,1974 |
|ref2_bref1 | 39,0426 |ref2_bref1 | 39,1921 |ref2_bref1 | 39,1990 |ref2_bref1 | 39,1847 |
|ref2_bref2 | |ref2_bref2 | 39,2042 |ref2_bref2 | 39,1663 |ref2_bref2 | 39,2008 |
|ref4_bref1 | 39,0501 |ref4_bref1 | 39,2004 |ref4_bref1 | 39,1989 |ref4_bref1 | 39,2131 |
|ref4_bref2 | |ref4_bref2 | 39,1950 |ref4_bref2 | 39,2092 |ref4_bref2 | 39,2065 |
|ref4_bref4 | |ref4_bref4 | 39,2006 |ref4_bref4 | 39,2156 |ref4_bref4 | 39,1981 |
|ref8_bref1 | 39,0621 |ref8_bref1 | 39,1923 |ref8_bref1 | 39,2035 |ref8_bref1 | 39,2063 |
|ref8_bref2 | |ref8_bref2 | 39,1834 |ref8_bref2 | 39,2089 |ref8_bref2 | 39,2074 |
|ref8_bref4 | |ref8_bref4 | 39,2063 |ref8_bref4 | 39,1731 |ref8_bref4 | 39,2068 |
|ref8_bref8 | |ref8_bref8 | 39,2013 |ref8_bref8 | 39,2142 |ref8_bref8 | 39,2013 |
|ref16_bref1 | 39,0523 |ref16_bref1 | 39,1913 |ref16_bref1 | 39,1924 |ref16_bref1 | 39,2148 |
|ref16_bref2 | |ref16_bref2 | 39,2053 |ref16_bref2 | 39,2101 |ref16_bref2 | 39,2121 |
|ref16_bref4 | |ref16_bref4 | 39,1852 |ref16_bref4 | 39,1937 |ref16_bref4 | 39,1982 |
|ref16_bref8 | |ref16_bref8 | 39,1996 |ref16_bref8 | 39,1706 |ref16_bref8 | 39,1937 |
|ref16_bref16| |ref16_bref16| 39,2127 |ref16_bref16| 39,1875 |ref16_bref16| 39,2090 |
|------------|---------|------------|---------|------------|---------|------------|---------|


SSIM(lumimasking=true):

|------------|-------|------------|-------|------------|-------|------------|-------|
| 0 bframes | SSIM | 1 bframes | SSIM | 2 bframes | SSIM | 3 bframes | SSIM |
|------------|-------|------------|-------|------------|-------|------------|-------|
|ref0_bref0 | 72,06 |ref0_bref0 | 73,30 |ref0_bref0 | 73,30 |ref0_bref0 | 73,32 |
|ref1_bref1 | 72,06 |ref1_bref1 | 73,30 |ref1_bref1 | 73,30 |ref1_bref1 | 73,32 |
|ref2_bref1 | 72,00 |ref2_bref1 | 73,27 |ref2_bref1 | 73,27 |ref2_bref1 | 73,20 |
|ref2_bref2 | |ref2_bref2 | 73,34 |ref2_bref2 | 73,06 |ref2_bref2 | 73,32 |
|ref4_bref1 | 72,03 |ref4_bref1 | 73,29 |ref4_bref1 | 73,31 |ref4_bref1 | 73,40 |
|ref4_bref2 | |ref4_bref2 | 73,26 |ref4_bref2 | 73,35 |ref4_bref2 | 73,37 |
|ref4_bref4 | |ref4_bref4 | 73,30 |ref4_bref4 | 73,38 |ref4_bref4 | 73,31 |
|ref8_bref1 | 72,14 |ref8_bref1 | 73,26 |ref8_bref1 | 73,32 |ref8_bref1 | 73,36 |
|ref8_bref2 | |ref8_bref2 | 73,22 |ref8_bref2 | 73,36 |ref8_bref2 | 73,36 |
|ref8_bref4 | |ref8_bref4 | 73,36 |ref8_bref4 | 73,13 |ref8_bref4 | 73,35 |
|ref8_bref8 | |ref8_bref8 | 73,34 |ref8_bref8 | 73,40 |ref8_bref8 | 73,35 |
|ref16_bref1 | 72,07 |ref16_bref1 | 73,23 |ref16_bref1 | 73,25 |ref16_bref1 | 73,41 |
|ref16_bref2 | |ref16_bref2 | 73,32 |ref16_bref2 | 73,37 |ref16_bref2 | 73,43 |
|ref16_bref4 | |ref16_bref4 | 73,23 |ref16_bref4 | 73,25 |ref16_bref4 | 73,32 |
|ref16_bref8 | |ref16_bref8 | 73,32 |ref16_bref8 | 73,13 |ref16_bref8 | 73,31 |
|ref16_bref16| |ref16_bref16| 73,36 |ref16_bref16| 73,23 |ref16_bref16| 73,39 |
|------------|-------|------------|-------|------------|-------|------------|-------|


"Conclusions":
(1) The first conclusion is very clear: the number of ref and bref hasn't much influence on quality. Nevertheless, you can see that they are not useless. The difference between the higher and the lower value in the whole test is 0.1730 db for PSNR and 1.43 point for SSIM. That's not much but not so negligible as it seems to be at first sight.

(2) The second remark is the "random" effect of ref and bref settings. For example, in the case of 1 brame:
ref2_bref2 | 39,2042 ref2_bref1 | 73,27
ref8_bref2 | 39,1834 ref8_bref2 | 73,22
We could expect tha going from ref2 to ref8, the PSNR and SSIM should increase but that's not the case, the metrics are decreasing.
If we watch at the 2 bframe results:
ref2_bref2 | 39,1663 ref2_bref2 | 73,06
ref8_bref2 | 39,2089 ref8_bref2 | 73,36
In this case, the metrics are increasing as the ref setting is also increasing.

The same fact is present in the case of the -bref setting:
1bframe, PSNR ans SSIM are decresing as -bref is increasing:
ref4_bref1 | 39,2004 ref4_bref1 | 73,29
ref4_bref2 | 39,1950 ref4_bref2 | 73,26
2bframe, PSNR ans SSIM are incresing as -bref is increasing:
ref4_bref1 | 39,1989 ref4_bref1 | 73,31
ref4_bref2 | 39,2092 ref4_bref2 | 73,35

(3) bframe influence:
The mean value for each test in the four different config of bframes setting show that the increasing of bframe number is benefic.
Mean values are:

|-----------|-----------|
| PSNR | SSIM |
|-----------|-----------|-----------|
|0 bframe | 39,0530 | 72,07 |
|1 bframe | 39,1977 | 73,29 |
|2 bframes | 39,1959 | 73,27 |
|3 bframes | 39,2033 | 73,35 |
|-----------|-----------|-----------|


I'm wondering if that could lead to something to compare te mean value from a same line in the above PSNR and SSIM tables? I think this could help to spot influence of the ref or bref setting idependently but I'm not sure this is really "scientifical". For example, studiing the five last lines from the two tables could help us to extract some quality infos. Here are the last lines and the mean value(I didn't took into account the 0bframe in the mean value as the -bref setting as no influence in this case):

|-----------|-----------|-----------|-----------|-----------|-----------|-----------|-----------|
| PSNR(1bf) | SSIM(1bf) | PSNR(2bf) | SSIM(2bf) | PSNR(3bf) | SSIM(3bf) | Mean PSNR | Mean SSIM |
|------------|-----------|-----------|-----------|-----------|-----------|-----------|-----------|-----------|
|ref16_bref1 | 39,1913 | 73,23 | 39,1924 | 73,25 | 39,2148 | 73,41 | 39,1995 | 73,2967 |
|ref16_bref2 | 39,2053 | 73,32 | 39,2101 | 73,37 | 39,2121 | 73,43 | 39,2092 | 73,3733 |
|ref16_bref4 | 39,1852 | 73,23 | 39,1937 | 73,25 | 39,1982 | 73,32 | 39,1924 | 73,2667 |
|ref16_bref8 | 39,1996 | 73,32 | 39,1706 | 73,13 | 39,1937 | 73,31 | 39,1880 | 73,2533 |
|ref16_bref16| 39,2127 | 73,36 | 39,1875 | 73,23 | 39,2090 | 73,39 | 39,2031 | 73,3267 |
|------------|-----------|-----------|-----------|-----------|-----------|-----------|-----------|-----------|



Even if we must be carefull because of the only sample on which these settings were tested, the previous table show that using more than -bref 2 is not really efficient.

A larger view on these mean values gives the following graphs:
PSNR:
http://perso.wanadoo.fr/paille/avc/PSNR_mean.jpg

SSIM:
http://perso.wanadoo.fr/paille/avc/SSIM_mean.jpg

From these graphs, we could say that -ref 4 seems to be a good choice between the -ref settings. -ref 8 and -ref 16 are sometimes higher but often lower than -ref 4 which is more constant.

Again, I should insist on the fact that this test is done with only one sample and that the results would probably be different with an other sample or with an oter bitrate. This test should be taken as a global indication on the relations between bframes/ref/bref settings.

Any commentary/critic concerning the results and the procedure is welcome.

[IgorC]

I also reported that ref:bref 16:16 look worse(too many artefacts) than 16:3. Source was quite high motion. Maybe keeping too many b-frames as references frames isn't good idea since bframes have a high quantizers. Or it's just an issue of this beta?

[IgorC]

In new beta 2 Psy 3 very good for low bitrates and has a highest OPSNR. But comparing visually for midle and high bitrates I still prefer psy 2. It's the same case as deblcoking filter 0 is better than -2 for metrics, but visually -2 is sharp and provide more details.

[dragongodz]

clip - Love Hina preview(anime)

target bitrate 850kb/s, 720x576 at 25fps

test 1 - default settings, 2 pass
pass 1 speed - 10.79fps
pass 2 speed - 8.21fps
mean psnr 41.79 dB [40.80|44.81|45.67], overall psnr 41.24 dB

test 2 - default settings , 2 pass, transform 8x8
pass 1 speed - 8.48fps
pass 2 speed - 6.06fps
mean psnr 42.42 dB [41.52|45.00|45.88], overall psnr 41.93 dB

actually watching the clips it is hard to spot any real difference. you have to look very hard or freeze on frames to notice some fine lines etc are slightly better. i will try it with an even lower bitrate next to see if i can get a bigger viewable difference.

[Sharktooth]

In new beta 2 Psy 3 very good for low bitrates and has a highest OPSNR. But comparing visually for midle and high bitrates I still prefer psy 2. It's the same case as deblcoking filter 0 is better than -2 for metrics, but visually -2 is sharp and provide more details.
Same for me.
Psy 3 is good for low bitrates coz it seems to smooth things a bit.

[Sharktooth]

clip - Love Hina preview(anime)

target bitrate 850kb/s, 720x576 at 25fps

test 1 - default settings, 2 pass
pass 1 speed - 10.79fps
pass 2 speed - 8.21fps
mean psnr 41.79 dB [40.80|44.81|45.67], overall psnr 41.24 dB

test 2 - default settings , 2 pass, transform 8x8
pass 1 speed - 8.48fps
pass 2 speed - 6.06fps
mean psnr 42.42 dB [41.52|45.00|45.88], overall psnr 41.93 dB

actually watching the clips it is hard to spot any real difference. you have to look very hard or freeze on frames to notice some fine lines etc are slightly better. i will try it with an even lower bitrate next to see if i can get a bigger viewable difference.

theoretically, the lower the bitrate the lower will be the difference between the 2 encodes...

[dragongodz]

theoretically, the lower the bitrate the lower will be the difference between the 2 encodes...
somewhat true but sometimes the differences can be easier to see aswell. so basically i am trying to see if this is true in this instance with the 8x8 transform. i will trying and do a higher bitrate encode aswell for comparison and completeness. :)

[superdump]

After JasonFly's tests on ref/bref I decided to conduct an exhaustive test to see what could be discovered. The main trend I've noted is that if you're using an odd number of refs then setting the number of brefs to 1 always gives the best global PSNR.

Graph of PSNR vs BRefs for different numbers of references (http://www.swains.plus.com/ateme/Ateme.beta2-2.RefBRef.png)

The key for the number of reference frames used is as follows:

red diamond dot
green plus
blue square dot
pink cross
black triangle dot
brown asterisk
turquoise circle dot
black dot
grey square
green diamond
mustard triangle
purple triangle
grey pentagon
blue triangle dot
yellow circle dot
orange square dot


You can find the Excel spreadsheet and individual charts of PSNR vs BRefs for each number of references here (http://www.swains.plus.com/ateme/refbref.xls).

My conclusion - I will probably use 5 references and 1 bref as I was using 5 references before. However, I may reconsider and just use 1 ref and 1 bref as I'm not sure the extra is really worth it for 0.1dB. I couldn't get SSIM working, if/when I do I'll post graphs of those results too. In the meantime, on to Psy 3 again and denoising.

[dragongodz]

clip - Love Hina preview(anime)

720x576 at 25fps

target bitrate 400kb/s,
test 1 - default settings, 2 pass
pass 1 speed - 12.15fps
pass 2 speed - 9.14fps
mean psnr 38.64 dB [37.49|42.69|43.53], overall psnr 37.92 dB

test 2 - default settings, 2 pass, 8x8 transform
pass 1 speed - 10.86fps
pass 2 speed - 6.92fps
mean psnr 39.51 dB [38.45|42.92|43.72], overall psnr 38.88 dB

target bitrate 1800kb/s,
test 1 - default settings, 2 pass
pass 1 speed - 9.38fps
pass 2 speed - 6.96fps
mean psnr 44.42 dB [43.53|46.98|47.76], overall psnr 43.96 dB

test 2 - default settings, 2 pass, 8x8 transform
pass 1 speed - 7.34fps
pass 2 speed - 5.08fps
mean psnr 44.92 dB [44.10|47.18|47.96], overall psnr 44.48 dB

first i will comment on the higher bitrate test. quality was excellent both with and without 8x8 transform. both looked just as good as the source playing back and even paused its hard to find any real major differences.

now for the lower bitrate encode. this actually yeilded a bigger seeable difference. in action parts there was less blocking and edges were preserved better. if not looking for it or watching on a small screen it may have been harder to notice ofcourse but when looking it was seeable. a couple of captures to help illustrate what i mean.

this is encode 1
http://img347.imageshack.us/img347/7483/l16vy.th.png (http://img347.imageshack.us/my.php?image=l16vy.png)
this is encode 2 with 8x8 transform
http://img347.imageshack.us/img347/9946/l22px.th.png (http://img347.imageshack.us/my.php?image=l22px.png)

look at the edges such as on the foot, on the sides of the trousers, on the shadows of the trousers(both middle and near the shirt) and especially the large line on the shirt near the top. infact look at most edges and you will get an idea of what i am talking about.
there was infact both better and worse frames than this but this best represents IMHO the general difference i saw.

EDIT: thumbnails instead of pictures :)

[Sharktooth]

Uhm... seems 8x8 still preserves more details even at the lowest bitrates.
I always thought the 8x8dct gain was a sort of gaussian (bitrate on the x axis and details on the y) but having done myself some more testing i should say that's not true.
So it seems high profile with 8x8dct is always better than main profile even for lower bitrates.
well it seems i should start to work on very low bitrate avc matrices too :scared:

[JasonFly]

Is there any mean to test interlace encoding using metrics such as PSNR and SSIM?

I was proudly writing my PSNR and SSIM scripts after some test with different interlaced parameters but then I realised that my source is interlaced(telecined in fact) and that the clip that ateme decoder outputs is deinterlaced.

So I decided that there were two means to obtain metrics results:

1)To deinterlace the source and compare it to the avc encode. But this doesn't mean anything because the source isn't the same anymore. So I tough to the second method:

2)Take the real source clip and compare it to the avc encode but without checking the "interlaced material" checkbox in the decoder.

I 'm just wondering which one of the two methods is the best. For me, it would be the second but I wanted to have your opinion. Of course, i'll also do some captures and visual testing but I would be happy to have some metric results in addition.

[kwtc]

The decoder does not deinterlace; it simply sets flags in the VIDEOINFOHEADER2 structure so that downstream filters (including any renderer) can make the best out of the decoded stream.

[IgorC]

Did anybody test filmgrain preservation function. what are optimal values for DVD's filmgrain? I tried a few values. And the result was worse than without -fgm.
Adaptive deblock seems to work(OPSNR changes - lower values ), but no visual effect.

[Sirber]

Seems I lost again my letter with my password. :(

[calinb]

Seems I lost again my letter with my password. :(No Sirber--didn't you know the Ateme letter contains "Mission Impossible Technology" and it self-destructs? You must disavow any knowledge of..... :)

[dragongodz]

Did anybody test filmgrain preservation function.
if you read back you will find i did test FGM with a black and white film. it actually did ok with that IMHO. i will do some more tests with other types of source and give an opinion aswell. just have to sort things back out as 1 of my hd dies so i have had to replace it.

[Sigmatador]

after de lossless test, the lossy one ^^:

Coral reef adventure resized to 1920*1080

33257 frames from the wmv-dvd (~23minutes)

encavc.exe -i coralreef1080.avs -o coralreef1080.mp4 -qual extra -rcmode 2pass -br 6300000 -deblock 1 -ref 2 -bref 2 -setef xf8x8,cabac -mingop 1 -maxgop 300 -bff -adaptdbk -enhchrp -psnr

1pass: 2.73fps
2pass: 1.35fps

psnr mean : 40.67 dB
psnr overall : 39.88 dB

took a while (but i was sleeping ^^)

visual impressions: Sometimes the textures are a bit too blurry for my taste (no downsize, i watched the mp4 at full size) but well, the overall quality is quite beautiful ^^ very impressive for the edges

[IgorC]

If the video is blure for eyes , why don't try a weaker deblocking filters . Instead of -1 put -2 or -3.

[IgorC]

some results with different cpu extention

Time spent for encode
mmx - 44 min 00 sec
isse - 22 min 39 sec
sse - 21:58
sse2 - 21:25

sse3 should be more faster

[Sharktooth]

uhm... it cant be that mmx is twice as slow as isse...
there's something wrong.
and btw sse3 wont add a noticeable speed boost...

[Manao]

Not at all, try with x264, you'll see

[kwtc]

With isse, there are nice instructions like psadbw (parallel sum of adsolute differences on bytes), which greatly increase the speed of some part of the software.

[dragongodz]

as promised here is some more fgm(film grain modeling) tests
default settings except 2 pass vbr with target 800kbs

source 1 is guyver: dark hero. low quality, fairly grainy, contains macroblocks.

useing fgm smoothed the edges slightly so there was less stepped edges and IMHO looked slightly better during playback but you really had to be watching for it to see it otherwise you probably wouldnt have noticed. so this is a similar result as the old black and white movie i tested before.

example
with fgm -
http://img238.imageshack.us/img238/7299/guyfgm2xd.th.png (http://img238.imageshack.us/my.php?image=guyfgm2xd.png)
without fgm
http://img238.imageshack.us/img238/4164/guynofgm8jh.th.png (http://img238.imageshack.us/my.php?image=guynofgm8jh.png)

source 2 is ghostbuster. very good quality. no real grain and no macroblocking.

this much better quality source tells a different story. with this the edges didnt get all stepped without fgm so once fgm was used all it ended up doing is killing fine detail and looked actually slightly worse IMHO. again you really need to be watching for it to really notice.

example
with fgm -
http://img238.imageshack.us/img238/2915/g1fgm1jy.th.png (http://img238.imageshack.us/my.php?image=g1fgm1jy.png)
without fgm -
http://img238.imageshack.us/img238/256/g1nofgm2yn.th.png (http://img238.imageshack.us/my.php?image=g1nofgm2yn.png)

considering that using fgm nearly doubled the time/halved the speed and only produced slightly better results with lower quality(grainy) sources i wouldnt really consider using it much personally.

[Sirber]

I like more ghostbuster whitout fgm...

[Sharktooth]

FGM is not for high quality clean sources...
i did several tests too and once you understand the difference between noise and grain, you will know HOW and WHEN (or when not) to use FGM.

[Soulhunter]

@ Sirber

Yeah, and it doesnt add grain back... :\


Bye

[berrinam]

i did several tests too and once you understand the difference between noise and grain, you will know HOW and WHEN (or when not) to use FGM.
Could you elaborate on that please?

[LigH]

"Grain" is "temporally averaged noise".

Try to remember the intro/cast of the TV series "X Files", looking to be recorded by surveilance or temperature cameras.

[dragongodz]

I like more ghostbuster whitout fgm...
yes thats what i said in my comments.

FGM is not for high quality clean sources...
i did several tests too and once you understand the difference between noise and grain, you will know HOW and WHEN (or when not) to use FGM.
is that suposed to be a shot at me or something ?
fact is it was asked previously in this thread about fgm tests and had anyone done any. i had done 1 with an old black and white movie and said i would do some more with different sources. so i did. now people can see and have my humble opinion of its effects on 3 different sources. if others want to also spend hours to do tests and give their opinions then they should feel free to do so. its funny but i thought thats what the quality feedback thread was for, feedback on what different options do quality wise to different sources and not to make assumptions. i thought the 8x8 transform test i did should have shown that.

[Sharktooth]

no, sorry, it was not directed to you. well, it was directed to no one.
i was puntualizing noise is different from grain, and the FGM is not able to reproduce certain kind of "artifacts".

[Soulhunter]

Could you elaborate on that please?

Have a look here (http://www.imx.nl/photosite/technical/Filmbasics/filmbasics.html), here (http://forum.doom9.org/showthread.php?p=667479#post667479) and here... (http://forum.doom9.org/showthread.php?t=93744) ^^


Bye

[plonk420]

sorry for disappearing off the face of the earth... i did 6-8 encodes of Empire Falls part 1 @ 720p, ran into some issues with SSIM (still haven't quite figured it out yet) and haven't touched it much since...

i AM however, uploading some clips that are pretty much free opensource (capture from a demoscene winning asm05 entry, Iconoclast). if Ateme has the bandwidth, i'm sure they'd be nice to play around with with everyone.

thruout the video, there's a staticy noise that i've only been able to retain with MPEG2, at the cost of artifacts all over the rest of the video (and an obscenely high bitrate)

i cut the whole video up and uploaded what i think is lossless...
clip1 is the intro. easy stuff, except maybe the 8-bit-per-pixel-or-less gradient artifact effect (which i'd prefer to retain)
clip2 immediately jumps into the insanity: noise, video that goes distorted as an effect, many small particles, a crossfade, and more gradient artifacts
clip3 is moving thru a field of textures that is detailed up close but becomes a jumbled mess from afar, tunnel effect, water effect, glow+gradient artifact, particles
clip4 has fast motion, finding nemo's ocean floor effect (briefly on an object), lots more full screen motion mayhem, super-white glow, flying particle mayhem
clip5 smoke/fog

edit: trying out rapidshare.de
clip1 (http://rapidshare.de/files/3781931/iconoclast-hp-lossless-clip1_00_00.mp4.html)
clip2-1of2 (http://rapidshare.de/files/3797792/iconoclast-hp-lossless-clip2_01_25.part1.rar.html)
clip2-2of2 (http://rapidshare.de/files/3797767/iconoclast-hp-lossless-clip2_01_25.part2.rar.html)
clip3-1of2 (http://rapidshare.de/files/3784403/iconoclast-hp-lossless-clip3_01_55.part1.rar.html)
clip3-2of2 (http://rapidshare.de/files/3784340/iconoclast-hp-lossless-clip3_01_55.part2.rar.html)
clip4-1of2 (http://rapidshare.de/files/3783550/iconoclast-hp-lossless-clip4_02_46.part1.rar.html)
clip4-2of2 (http://rapidshare.de/files/3783515/iconoclast-hp-lossless-clip4_02_46.part2.rar.html)
clip5 (http://rapidshare.de/files/3782642/iconoclast-hp-lossless-clip5_03_50.mp4.html)

mpeg-2 1of2 (http://rapidshare.de/files/3798749/iconoclast-mpeg2-2pass2400.part1.rar.html)
mpeg-2 2of2 (http://rapidshare.de/files/3798718/iconoclast-mpeg2-2pass2400.part2.rar.html)

edit2: i've done my own encodes, and the artifact-filled mpeg-2 seems to look better (noise wise) than the xvid or avc ones... i'll have to mess around with settings or matricies maybe, tho

[berrinam]

Thanks for the replies about noise vs. grain.

[dragongodz]

no, sorry, it was not directed to you. well, it was directed to no one.
sorry but since it came after my FGM tests and you wre talking about FGM tests etc its easy to see where one could think it was aimed at my tests. :)

i was puntualizing noise is different from grain, and the FGM is not able to reproduce certain kind of "artifacts".
i agree. however now people can see for themselves an example that not only can FGM be good on some sources it can actually be destructive with others so they really need to consider their source before using it. who knows it may also give the Ateme guys some ideas on improving FGM to reduce such behaviour on clean sources. ;)

[superdump]

I suppose the distinct lull in feedback suggests everyone is perfectly happy with the quality of the outputs... or at least they're waiting for an update to denoising/fgm. ;)

[LigH]

Well - it seems that bobo is still on vacation. Similar problem for the "bugs" thread, where we hope for more suggestions which specific functions we shall test deeper.

[hubereevez]

Still have no problem with encoder beta2, just strange psnr value (isn't it ?).... Tested with hybridfupp....Encoding is fast, I think.....

-qual extra -psy 3 -spmvp -enhchr
p -rcmode 2pass -br 779000 -priority high -threads 2 -psnr -setef ppred,bpred,wp
red,cabac,deblock,part,subpart,hpel,qpel,xf8x8 -ref 5 -bref 3 -maxb 2 -deblock 0
-adaptdbk

Core encoder version 1.2.0.17


* Encoding summary

Resolution : 608x320 @ 25.00 fps
Length : 174990 Frames
Quality : Extra
Rate Control : 2pass
Target Bit Rate : 779 kb/s
Init Quantiser : 24 [0 - 51]
Gop Size Min - Max : 1 - 300 (closed)
Process Priority : High [2 thread(s)]
CPU Extension : mmx sse sse2


* Encoding Features

- prediction : ipred ppred bpred(2) wpred : using 5:3 ref(s)
- entropy : cabac
- subsampling : hpel qpel
- mb partition : 16x16/16x8/8x16/8x8/8x4/4x8/4x4
- interlaced : disabled
- misc : deblock(0:adaptive) xf8x8 enhchrp psy(3)

-- Start processing pass 1 / 2
* 100.00% completed
* 174990 frames processed @ 54.63 fps
-- Start processing pass 2 / 2
* 174989: encoding @ 38.23 fps - bitrate 7.20 kb/s - 100.00% completed
* 174990 frames encoded @ 8.20 fps - average bitrate 779.03 kb/s
* mean psnr 45.46 dB [44.73|47.49|47.84], overall psnr 44.82 dB

[LigH]

Hereby, once again I request any signs of life from the developers.

[plonk420]

FINALLY, i found a clip that i could finally tell the difference between x264 and ateme HP... (i guess most of my test clips don't have much flashing)

but i still can't tell the diff between the ateme switches...

x264 still hurts with flashes, from what i see :O

uploading results

further quick notes:

-the less blocking is at a slight compromise to detail (but the blocking sticks out like a sore thumb more so than the blocking)

-the difference in blocking between x264 and ateme is less noticeable on a TN-Film LCD (compared to CRT)

(i'll probably need to figure out how to ABX this to double check that last claim, tho)

currently encoding with different psy modes...

[bobololo]

Please don't forget to use this thread for quality issue with beta2-3. Thanks!

[superdump]

I ran a quick test last night, just to see the improvements from beta2-2 to beta2-3.

For the duration of testing this time I will be using a sequence of CIF test clips, uncropped to avoid alteration of the clip due to resizing, all stuck together. To be more specific - akiyo, bus, flower, foreman, hall, mother, news, stefan, waterfall. These are being read using rawsource() from the yuv files.

Alongside this bunch of test clips I will be using a section from Lord of the Rings: Return of the King (Extended Edition) PAL. I ripped both DVDs, created d2vs, stuck one to the end of the other in avisynth and then took frames 215743 to 225319, cropping to 712x420. The resolution might change on this to something mod 16, I haven't decided yet. But for this test it was as stated. The clip has been compressed to ffv1 though I may switch to lossless h.264 or ffvhuff if they prove faster to decode.

Command line options: -qual extra -rcmode 2pass -br 600000 -deblock -2 -setef xf8x8 -maxb 3 -enhchrp -ref 5 -bref 1 -psy 0 -psnr

I've had a CPU upgrade since I was last testing. I can't entirely remember what I had before, but I now have an AMD Athlon 64 3700+ 1MB L2 cache and 1GB PC3200 RAM.

LOTR: ROTK clip
0.14dB improvement
2% speed

CIF reference clips
1% speed

I was doing stuff during the beta2-3 encode of the LOTR clip so it should have gained a little more speed than that, but probably not much. Still, looking good. :)

I think I'll refamiliarise myself with the codec (it's been quite a while since I used it properly) and then get down to testing psy and stressing it as usual. :) See you on the other side.

Here's the full specification:
(beta2-3 lotr, beta2-2 lotr, beta2-3 cif clips, beta2-2 cif clips)

ENCAVC - Copyright (c) 2004-2005 ATEME (http://www.ateme.com/)

This software is an experimental MPEG-4 AVC / H.264 encoder. It is intended
for evaluation purpose only and redistribution is strictly PROHIBITED.

Core encoder version 1.4.0.3


* Encoding summary

Input file : e:/lotrsource.avs
Output file : c:/videostuff/ateme-b2-3-lotr.mp4
Resolution : 712x420 @ 25.00 fps
Length : 9577 Frames
Quality : Extra
Rate Control : 2pass
Target Bit Rate : 600 kb/s
Init Quantiser : 24 [0 - 51], chrdq(1)
Gop Size Min - Max : 1 - 300 (closed)
Process Priority : Normal [1 thread(s)]
CPU Extension : mmx sse sse2 sse3


* Encoding Features

- prediction : ipred ppred bpred(3) wpred : using 5:1 ref(s)
- entropy : cabac
- subsampling : hpel qpel
- mb partition : 16x16/16x8/8x16/8x8
- interlaced : disabled
- misc : deblock(-2:fixed) xf8x8 enhchrp

-- Start processing pass 1 / 2
* 100.00% completed
* 9577 frames processed @ 9.17 fps
-- Start processing pass 2 / 2
* 09576: encoding @ 3.99 fps - bitrate 1013.07 kb/s - 100.00% completed
* 9577 frames encoded @ 5.27 fps - es average bitrate 599.86 kb/s
* mean psnr 38.19 dB [36.86|43.84|44.61], overall psnr 37.43 dB

- Total processing time 00:00:53:03
- Output file (c:/videostuff/ateme-b2-3-lotr.mp4) closed
* Encoding complete - Exiting !
ENCAVC - Copyright (c) 2004 ATEME (http://www.ateme.com/)

This software is an experimental MPEG-4 AVC / H.264 encoder. It is intended
for evaluation purpose only and redistribution is strictly PROHIBITED.

Core encoder version 1.2.0.17


* Encoding summary

Input file : e:/lotrsource.avs
Output file : c:/videostuff/ateme-b2-2-lotr.mp4
Resolution : 712x420 @ 25.00 fps
Length : 9577 Frames
Quality : Extra
Rate Control : 2pass
Target Bit Rate : 600 kb/s
Init Quantiser : 24 [0 - 51]
Gop Size Min - Max : 1 - 300 (closed)
Process Priority : Normal [1 thread(s)]
CPU Extension : mmx sse sse2 sse3


* Encoding Features

- prediction : ipred ppred bpred(3) wpred : using 5:1 ref(s)
- entropy : cabac
- subsampling : hpel qpel
- mb partition : 16x16/16x8/8x16/8x8
- interlaced : disabled
- misc : deblock(-2:fixed) xf8x8 enhchrp

-- Start processing pass 1 / 2
* 100.00% completed
* 9577 frames processed @ 6.89 fps
-- Start processing pass 2 / 2
* 09576: encoding @ 3.10 fps - bitrate 1183.60 kb/s - 100.00% completed
* 9577 frames encoded @ 4.32 fps - average bitrate 599.88 kb/s
* mean psnr 38.02 dB [36.68|43.80|44.56], overall psnr 37.29 dB

Encoding complete (time elapsed 00:00:54:02)
ENCAVC - Copyright (c) 2004-2005 ATEME (http://www.ateme.com/)

This software is an experimental MPEG-4 AVC / H.264 encoder. It is intended
for evaluation purpose only and redistribution is strictly PROHIBITED.

Core encoder version 1.4.0.3


* Encoding summary

Input file : c:/videostuff/sources/sources.avs
Output file : c:/videostuff/ateme-b2-3-sources.mp4
Resolution : 352x288 @ 25.00 fps
Length : 2250 Frames
Quality : Extra
Rate Control : 2pass
Target Bit Rate : 600 kb/s
Init Quantiser : 24 [0 - 51], chrdq(1)
Gop Size Min - Max : 1 - 300 (closed)
Process Priority : Normal [1 thread(s)]
CPU Extension : mmx sse sse2 sse3


* Encoding Features

- prediction : ipred ppred bpred(3) wpred : using 5:1 ref(s)
- entropy : cabac
- subsampling : hpel qpel
- mb partition : 16x16/16x8/8x16/8x8
- interlaced : disabled
- misc : deblock(-2:fixed) xf8x8 enhchrp

-- Start processing pass 1 / 2
* 100.00% completed
* 2250 frames processed @ 35.77 fps
-- Start processing pass 2 / 2
* 02249: encoding @ 14.81 fps - bitrate 500.25 kb/s - 100.00% completed
* 2250 frames encoded @ 18.07 fps - es average bitrate 599.66 kb/s
* mean psnr 41.32 dB [40.65|42.70|44.07], overall psnr 40.31 dB

- Total processing time 00:00:03:16
- Output file (c:/videostuff/ateme-b2-3-sources.mp4) closed
* Encoding complete - Exiting !
ENCAVC - Copyright (c) 2004 ATEME (http://www.ateme.com/)

This software is an experimental MPEG-4 AVC / H.264 encoder. It is intended
for evaluation purpose only and redistribution is strictly PROHIBITED.

Core encoder version 1.2.0.17


* Encoding summary

Input file : c:/videostuff/sources/sources.avs
Output file : c:/videostuff/ateme-b2-2-sources.mp4
Resolution : 352x288 @ 25.00 fps
Length : 2250 Frames
Quality : Extra
Rate Control : 2pass
Target Bit Rate : 600 kb/s
Init Quantiser : 24 [0 - 51]
Gop Size Min - Max : 1 - 300 (closed)
Process Priority : Normal [1 thread(s)]
CPU Extension : mmx sse sse2 sse3


* Encoding Features

- prediction : ipred ppred bpred(3) wpred : using 5:1 ref(s)
- entropy : cabac
- subsampling : hpel qpel
- mb partition : 16x16/16x8/8x16/8x8
- interlaced : disabled
- misc : deblock(-2:fixed) xf8x8 enhchrp

-- Start processing pass 1 / 2
* 100.00% completed
* 2250 frames processed @ 32.31 fps
-- Start processing pass 2 / 2
* 02249: encoding @ 13.23 fps - bitrate 508.39 kb/s - 100.00% completed
* 2250 frames encoded @ 16.24 fps - average bitrate 599.63 kb/s
* mean psnr 41.33 dB [40.64|42.77|44.14], overall psnr 40.27 dB

Encoding complete (time elapsed 00:00:03:37)

EDIT: Just a quick decoder speed test on beta2-2 lotr.

Ateme h.264 decoder beta2-2:
User: 64s, kernel: 2s, total: 67s, real: 68s, fps: 142.2, dfps: 140.4
Ateme h.264 decoder beta2-3:
User: 56s, kernel: 0s, total: 56s, real: 57s, fps: 168.3, dfps: 166.7
ffdshow 2005-11-29 SSE (Milan):
User: 64s, kernel: 0s, total: 64s, real: 65s, fps: 147.9, dfps: 145.4
ffdshow 2005-12-08 GCC 4.0.2 SSE (Jarod/bob0r):
User: 63s, kernel: 0s, total: 63s, real: 65s, fps: 149.9, dfps: 147.0

(Thanks to Haali for the timeCodec tool. In short, it pwns.)

[superdump]

Hmm, I smell a rat here. Do I see edge sharpening or some sort of edge detection and disabling of deblocking or am I misguided?

[Manao]

Deblocking can't be disabled on a per MB basis, except by lowering the quantizer a lot. I'd be the first astonished if our encoder was doing edge sharpening :p

[Latexxx]

Unbelievable!

CBR severely kicks ABR's ass at my low bitrate high motion clip (Cradle 2 the Grave trailer, see my old posts somewhere). And my cbr files are smaller than their abr counterparts. Abr looks like it used to look back in summer but CBR looks divine.

Not much difference between psy 2 and psy 3 but both look amazing at cbr. Resolution was 640*256, xf8x8 used and bitrate 200 kbps. Way to go Ateme! I'm pretty positive that this is the best codec when it comes to low bitrate video.

[IgorC]

Did anybody test BFF/TFF with/without mbaff? separatefields().complementparity().weave().

As it was mentioned beta was going be able in the next weekend (and not this weekend). So I already planned my free time after 21 of dec. I will be here soon. :)

Seems like mp4box can't set field per second.

How minb can be usefull? Probably encoder is smart to decide how many b-frames to put [0,3].

[Sharktooth]

minb is usefull if you plan to always have at least 1-bframe (for example) or having from 2 to 3 bframes.

[IgorC]

Sharktoothhave at least 1-bframe (for example) or having from 2 to 3 bframes.

The purpose of this feature is clear. But usefulness? Why would I need at least 1 bframes when encoder is enough smart to make desecion by itself.

[Sharktooth]

maybe for the cases where the encoder fails to "decide" when to put or not bframes.

[IgorC]

Regresion of quality in some videos.

Something wrong with this beta. Quality was optimized for OPSNR result. But SSIM goes down comparing to previos beta 2.
Beta2-2 already has some optimization for OPSNR - psy3. This way beta 3 is even more optimizied for OPNSR.
Psy 3 is very usefull for very low bitrates but it's evil for middle and higher bitrate ( 700 kbit/s and higher).
I made just a few fast test beta2-2 beta2-3 with 2 samples (14 and 45 seconds). OPSNR of beta 3 was higher, SSIM was higher for beta2. My eyes and SSIM say me that OPSNR is sometimes wrong strongly.
I wish I wrong.

uploading some shorts samples and going to do some bigger encoding 2-20 mins later.
Original video http://rapidshare.de/files/9393154/choped.vob.html
http://rapidshare.de/files/9390335/psy.7z.html

encavc -qual extra -psy 2 -mvrange 1024 -spmvp -enhchrp -cpb 1048576 -rcmode 2pass -br 702000 -priority idle -psnr -setef wpred,cabac,deblock,part,subpart,hpel,qpel,xf8x8,pcm -clref interlaced,paff,mbaff -ref 16 -bref 3 -maxb 3 -deblock -2 -i hp3.avs -o ateme_beta3_extra_psy2.mp4 pause

ssim.dll from http://multimediacom.free.fr/Download/SSIM.rar


ateme_beta2_extra_psy2_4130 (72.22).mp4 . OPSNR 41.30 SSIM 72.22
ateme_beta3_extra_psy2_4136(70.65).mp4
ateme_beta3_full_psy3_4156 (69.6764).mp4. Highest OPNSR and lowest SSIM. Imo worst visual result

[DeathTheSheep]

It looks like you have 'pcm' as one of your setef encoding tools. Do you mean 'csm'?

[IgorC]

No. It´s PCM. Search in forum.

[DeathTheSheep]

Oops my bad ;)

[superdump]

pcm and -spmvp aren't documented in the packages.

[Manao]

Psy settings have never been tweaked neither for PSNR nor SSIM, only for the eyes of the devs ( which can be failing ;) ). So if PSNR is higher with psy 3, it's pure luck. A lower visual quality is however more troublesome.

[Latexxx]

I also did some lowbitrate 2-pass testing and I can't believe my eyes. The difference between cbr and 2-pass vbr is hardly noticeable. But yet it is possible to see some difference in favour of 2-pass. So in its current state abr is pretty much useless because it looks much worse than cbr and gives bigger filesize, at least with my sample. So no abr for final product please or some people will definately use it because they are going to believe that it gives better quality than cbr.

[Manao]

Well, ABR should be better than CBR. It's just that with the speed of our first pass, we never felt the need to spend much time on it. CBR is mandatory for the broadcast industry, so we worked hard. 2 passes gives very good results when CBR isn't required, and is almost as fast as a one pass encoding.

So that comment definitely means works will have to be done for ABR.

[baer999]

Wow I'm looking forward to see the comparison of Doom9. There was a lot of development in codecs like x264 and Ateme. The two best codecs of the MSU comparison, but at that test the revision of x264 was 293 now its almost 400 !!! And the Beta 3 of Ateme has also interesting improvements :-)
so when will the test start, which codecs will take part ?

[Sagittaire]

ateme_beta2_extra_psy2_4130 (72.22).mp4 . OPSNR 41.30 SSIM 72.22
ateme_beta3_extra_psy2_4136(70.65).mp4
ateme_beta3_full_psy3_4156 (69.6764).mp4. Highest OPNSR and lowest SSIM. Imo worst visual result

be carefull you test with extra and full motion estimation search and your test must be always with the same ME mode if you want make real psy comparison.

In fact the best psy optimisation for Metric seem to be psy 1 but be carefull metric are unable to evaluate visual optimisation with psy option or with custom matrix option ... only eyes for that ... ;-)

[IgorC]

It's not the case
I've compared psy 2/3 on extra mode and psy2/3 on full mode.

I've test all possbile combinations. Maybe I didn't upload neither mentioned all of them.

seems like my poorly poor engilsh is getting even worse :p

[Sharktooth]

Yeah... there's indeed a visual difference in favour of beta2 (with that settings).

[dragongodz]

was planning to do some tests this week but christmas stuff etc got in the way. should be able to next week.

what were you Ateme guys thinking releasing a new beta this close to christmas ? ;) :D

[ChronoCross]

Even though I won't be able to do more tests until January 18th(I'm currently on Christmas break and unfortunately I had to fly home 4000 miles so bringing my entire setup was out of the question) my initial impressions aren't good or bad. it seems there was no real noticeable improvement in quality however speed has increased somewhere around 10-15% on my setup. The fact that adaptdbk was broken in this beta is kinda a downturn because shouldn't one check to make sure everything at least starts encoding lol. but aside from that it seems like step in the positive direction. I'll probably do some more test when I get back and post the results.

[thegeby]

Finally got down to do some proper testing. As usual, looking at high definition at cbr br 6000, (psy 2). First impressions, great picture quality, but a real resource hog. Encoding on my AMD Athlon 64 3000 reaches about 5 fps. That is not too dramatic as real time encoding would be likely to use dedicated DSPs, but worse is that this processor, combined with the ATI 9800 chokes on playback. High Profile seems to require a masive leap in resources compared to Main Profile AVC.

[CruNcher]

Try this for playback

http://picard.exceed.hu/tcpmp/test/tcpmp.win32.0.71d.zip
http://picard.exceed.hu/tcpmp/test/avc.win32.0.71e.zip

Merry Christmas

[Manao]

High Profile seems to require a masive leap in resources compared to Main Profile AVCNot decoding wise. 8x8 dct is hardly slower than 4x4 dct, CQM are as fast, and intra 8x8 is a bit more slower, but it's not that much used anyway.

[IgorC]

Can somebody playback these interlaced samples smoothly? I dont know whats problem. Ateme Decoder or encoder. There are a lot of artefacts.

encavc.exe -i "C:\interlace\interlace_tff.avs" -o "C:\interlace\ateme\interlace_tff_paff_mbaff.mp4" -qual extra -psy 2 -mvrange 1024 -enhchrp -cpb 1048576 -par 12:11 -rcmode 2pass -br 1000000 -psnr -setef ppred,bpred,wpred,cabac,deblock,part,subpart,hpel,qpel,xf8x8,pcm,interlaced,paff,mbaff -ref 16 -bref 3 -maxb 3 -deblock -2



http://rapidshare.de/files/9756729/interlcaed.7z.html
http://rapidshare.de/files/9757231/interlace_tff_paff_NOmbaff_fastest.mp4.html

[CruNcher]

all the samples show white blocks with Atemes Decoder ?

[*.mp4 guy]

Can somebody playback these interlaced samples smoothly? I dont know whats problem. Ateme Decoder or encoder. There are a lot of artefacts.

Those "artifacts" arent normal, there a bug of some sort.

[dragongodz]

finally found some time over this busy period to do some testing.

tests done with small sorting program running in the background.

settings = defalt + 2pass to 700kbps + good quality level.
athlonxp 2400+

beta 2 = 14.26fps average
beta 3 = 15.32fps average
beta 3 + rt = 20.81fps average

so a noticable difference in speed. :)

quality wise they all looked the same. i even checked random frames throughout the encodes to compare and there was no noticable differences with these settings.

[ChrisBensch]

I keep seeing updates to the Ateme cli encoder in the forums, will this final product be released as a stand-alone tool like x264?

[lexor]

I keep seeing updates to the Ateme cli encoder in the forums, will this final product be released as a stand-alone tool like x264?
highly doubtful, the only reason it is cli now is that for encoder testing they take gui out of equation. final I would think will be integrated into Recode.

[bond]

I keep seeing updates to the Ateme cli encoder in the forums, will this final product be released as a stand-alone tool like x264?the codec is already sold on ateme's site, for, rumours say, more than 1000$ ;)

[ChrisBensch]

All I can say is...WOW, how rediculous!

[ChrisBensch]

So since you guys are talking about Ateme's quality, do you agree with that MSU comparison that put Ateme ahead of x264 in some of the quality categories? Does Nero's Ateme implementation beat x264?

[Manao]

You should read entirely threads when they interest you. You'd learn that this version isn't implemented in Nero yet, that MSU's comparison has serious flaws, and that quality-wise, x264 has slightly more than filled the gap that existed one year ago.

[Sirber]

the codec is already sold on ateme's site, for, rumours say, more than 1000$ ;)
http://www.ateme.com/products/pcencoder.php ?

[dragongodz]

All I can say is...WOW, how rediculous!
hmm and whats you view on CCE SP being something like $2000 then ?

you are failing to consider the target customer. both CCE SP and i am assuming the Ateme encoder from the link given is aimed at business sales and not joe smith on the street. for joe there is CCE basic and Nero respectivly as commercial products(of course there are others, these 2 are just examples).

finally there are of course freeware encoders aswell so its not like anybody is making you pay those prices.

[ChrisBensch]

You are absolutely right...I guess it's just a matter of perspective (like you said, target clients). I sometimes forget that not all software is for us end users!

[bobololo]

Ok the encoder currently doesn't support paff and mbaff simultaneously. And we forgot to disable paff when mbaff is enabled. That could explain the results when both are set in the cli. However, the clips you obtained with PAFF_noMBAFF show some defects that shouldn't occur. Could you please upload the source and provide the exact cli you used so we can investigate it ? Thanks !

Can somebody playback these interlaced samples smoothly? I dont know whats problem. Ateme Decoder or encoder. There are a lot of artefacts.

encavc.exe -i "C:\interlace\interlace_tff.avs" -o "C:\interlace\ateme\interlace_tff_paff_mbaff.mp4" -qual extra -psy 2 -mvrange 1024 -enhchrp -cpb 1048576 -par 12:11 -rcmode 2pass -br 1000000 -psnr -setef ppred,bpred,wpred,cabac,deblock,part,subpart,hpel,qpel,xf8x8,pcm,interlaced,paff,mbaff -ref 16 -bref 3 -maxb 3 -deblock -2



http://rapidshare.de/files/9756729/interlcaed.7z.html
http://rapidshare.de/files/9757231/interlace_tff_paff_NOmbaff_fastest.mp4.html

[bobololo]

@IgorC: you don't need to upload your source anymore, we have succeeded to reproduce the issue. We have a flaw in the simd optimized mb field/frame decision functions. Thanks a lot for your discoveries !

Ok the encoder currently doesn't support paff and mbaff simultaneously. And we forgot to disable paff when mbaff is enabled. That could explain the results when both are set in the cli. However, the clips you obtained with PAFF_noMBAFF show some defects that shouldn't occur. Could you please upload the source and provide the exact cli you used so we can investigate it ? Thanks !

[hubereevez]

Since beta 3, it's like encoding speed has greatly increased by me....

-- Start processing pass 1 / 2
* 100.00% completed
* 185373 frames processed @ 49.38 fps
-- Start processing pass 2 / 2
* 185372: encoding @ 25.82 fps - bitrate 29.00 kb/s - 100.00% completed
* 185373 frames encoded @ 6.04 fps - es average bitrate 709.00 kb/s
* mean psnr 43.03 dB [41.95|46.89|48.23], overall psnr 42.20 dB
- Total processing time 00:09:59:46

[dragongodz]

Since beta 3, it's like encoding speed has greatly increased by me....

what was you previous speed ? if you look back some posts you will see where i gave an example of speed difference with my pc. will have to try it with absolutly nothing running aswell soon.