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