Ateme H.264 HP Beta Test : Quality Feedback

[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?