Ateme H.264 HP Beta Test : Quality Feedback

[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 ;)