x264 "Macroblock Tree Ratecontrol" testing (committed)

[juGGaKNot]

Default is 40/changes per profile

max is keyint

why clip it to 80 ?

[ocal5]

Another real life video test, with 1080i59,97 "ideal" picture : 1 sequence, man moving inside stable picture

WITHOUT

--bitrate 1200 --no-mbtree --interlaced --me umh --ssim --psnr
http://img188.imageshack.us/i/without.png/ image 630
http://dl.free.fr/qYKmpjUQz encoded video
SSIM Mean Y:0.8531129
PSNR Mean Y:32.314 U:42.239 V:42.956 Avg:33.865

WITH

--bitrate 1200 --interlaced --me umh --ssim --psnr
http://img33.imageshack.us/i/withj.png/ image 630
http://dl.free.fr/jxU0sG6Cs encoded video
SSIM Mean Y:0.8838190
PSNR Mean Y:33.609 U:42.781 V:43.630 Avg:35.125

Difference is so impressive that I doubt there is only "this" mbtree who do difference. But at least, as Dark Shikari explained in first message the theory, it seems real and not only for animes !

[CruNcher]

finaly lookahead funny that it's sooner finished then weighted p frames :D

btw tetsuo lookahead was allready in Atemes Encoder since about 2-3 years now :)

if it's the same thing visually it should show especialy @ parkrun without AQ heavy improvements i guess

[ocal5]

tetsuo lookahead

Sorry, what is that curious thing?

[Guest]

tetsuo is a member here and a comma was omitted:

btw tetsuo, lookahead ...

[CruNcher]

yeah CruNcher and punctuation ;)

[popper]

Another real life video test, with 1080i59,97 "ideal" picture : 1 sequence, man moving inside stable picture

WITHOUT

--bitrate 1200 --no-mbtree --interlaced --me umh --ssim --psnr
http://img188.imageshack.us/i/without.png/ image 630
http://dl.free.fr/qYKmpjUQz encoded video
SSIM Mean Y:0.8531129
PSNR Mean Y:32.314 U:42.239 V:42.956 Avg:33.865

WITH

--bitrate 1200 --interlaced --me umh --ssim --psnr
http://img33.imageshack.us/i/withj.png/ image 630
http://dl.free.fr/jxU0sG6Cs encoded video
SSIM Mean Y:0.8838190
PSNR Mean Y:33.609 U:42.781 V:43.630 Avg:35.125

Difference is so impressive that I doubt there is only "this" mbtree who do difference. But at least, as Dark Shikari explained in first message the theory, it seems real and not only for animes !

thats really impressive, without even looking at it on the big screen or zooming in, its so clearly better around the man's hair and the statue's head against the sky in the second png.

is that due to the first interlaced sequence we have seen MTR tested here, or is it also the same for a Progressive version of that sequence too ?

[vucloutr]

Strength of MB-tree adjustments can be tweaked using qcompress; higher values mean lower MB-tree strength.
what does higher or lower MB-tree strength mean?
could someone be so kind to explain this on an example?

[ocal5]

is that due to the first interlaced sequence we have seen MTR tested here, or is it also the same for a Progressive version of that sequence too ?

This sequence is interlaced, how do you want me to make it progressive ? Not sure that improvement is due to interlacing. More because it's a shoot choosen because to be ideal regarding the theory of this patch.

I have a somewhat not linked question :

This picture is before I frame, and the second one after (time related). (cropped)

http://img197.imageshack.us/img197/2017/beforeid.jpg (http://img197.imageshack.us/i/beforeid.jpg/)
http://img197.imageshack.us/img197/7545/afterio.jpg (http://img197.imageshack.us/i/afterio.jpg/)

I've try with slow settings, 2 pass, -i 1... everytime, there is a "shock" on the video starting the "I" frame. Background is sharp but before key frame it's blur.

Seems insame in my mind, but... is there a way for the codec to relate B&P frames to the comming I frame ? Or, is the only solution to put an I frame after (in this case) zooming ?

[Dark Shikari]

finaly lookahead funny that it's sooner finished then weighted p frames :D

btw tetsuo lookahead was allready in Atemes Encoder since about 2-3 years now :)Ateme's encoder does not have MB-tree or anything remotely similar.

Its lookahead is for ratecontrol.

[Amefurashi]

Version 1201 seems to have some problems. Maybe it's just me...

:scared:

CLI is the following:

x264.exe --pass 1 --slow-firstpass --bitrate 4642 --stats "xxx.stats"
--level 4.1 --keyint 240 --min-keyint 24 --ref 5 --mixed-refs --bframes 5
--b-pyramid --b-adapt 2 --weightb --direct auto --deblock -2:-1 --subme 9
--trellis 2 --psy-rd 1.0:0 --partitions all --8x8dct --vbv-bufsize 50000
--vbv-maxrate 50000 --me umh --merange 24 --threads auto --thread-input
--aq-strength 1.0 --no-dct-decimate --no-mbtree --output NUL yyy.avs
pause

Everything went fine. Second pass (VERY SAME options, except for --pass 2 and --output "zzz.mp4") goes this way:


x264.exe --pass 2 --slow-firstpass --bitrate 4642 --stats "xxx.stats" --lev
el 4.1 --keyint 240 --min-keyint 24 --ref 5 --mixed-refs --bframes 5 --b-pyramid
--b-adapt 2 --weightb --direct auto --deblock -2:-1 --subme 9 --trellis 2 --psy
-rd 1.0:0 --partitions all --8x8dct --vbv-bufsize 50000 --vbv-maxrate 50000 --me
umh --merange 24 --threads auto --thread-input --aq-strength 1.0 --no-dct-decim
ate --no-mbtree --output "zzz.mp4" yyy.avs
avis [info]: 1280x532 @ 23.98 fps (141409 frames)
x264 [warning]: width or height not divisible by 16 (1280x532), compression will
suffer.
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cach
e64
x264 [info]: profile High, level 4.1
mp4 [info]: initial delay 2002 (scale 24000)
[0.0%] 20/141409 frames, 33.06 fps, 0.00 kb/s, eta 1:11:17
F:\TEST
>pause


It suddendly stops when the encoding begins. Ideas? :confused:




EDIT: nevermind, just read the bug thread... MP4 output is broken in rev1201. My bad >_<

[bob0r]

Version 1201 seems to have some problems. Maybe it's just me...

:scared:

It suddendly stops when the encoding begins. Ideas? :confused:

Confirmed (and fixed?): http://forum.doom9.org/showthread.php?p=1312586#post1312586

[Amefurashi]

Confirmed (and fixed?): http://forum.doom9.org/showthread.php?p=1312586#post1312586

Thanks bob0r, MKV output works fine ;)

[CruNcher]

@Dark_Shikari
i get this error message continuously till the end after the first 250 frames (keyframe interval setting) with mbtree

x264 [warning]: specified frame type (3) is not compatible with keyframe interval

--crf 29 --preset fast --profile high -b 0 --b-adapt 0 --direct temporal --aq-mode 0 --ssim --psnr --scenecut -1 --nf --partitions i8x8,i4x4,p8x8

without mbtree memory consumption was @ the end 110 mb with mbtree 293 mb

[Dark Shikari]

@Dark_Shikari
i get this error message continuously till the end after the first 200 frames with mbtree on parkrun

x264 [warning]: specified frame type (3) is not compatible with keyframe interval

--crf 29 --preset fast --profile high -b 0 --b-adapt 0 --direct temporal --aq-mode 0 --ssim --psnr --scenecut -1 --nf --partitions i8x8,i4x4,p8x8

without mbtree memory consumption was @ the end 110 mb with mbtree 293 mbFixed.

[martinfrombern]

great patch :) here is how it looks on a source i'm currently working with. common parameters for both encodes --bitrate 9000 --aq 0.9 --psy-rd 1.0:0.1 --ref 4 --me umh --merange 32 (...). Here come the results

source / mbtree / no mbtree
http://thumbnails4.imagebam.com/4475/49ae4144744750.gif (http://www.imagebam.com/image/49ae4144744750) http://thumbnails13.imagebam.com/4475/27ee6344744753.gif (http://www.imagebam.com/image/27ee6344744753) http://thumbnails14.imagebam.com/4475/c0546244744755.gif (http://www.imagebam.com/image/c0546244744755)

as you can see, mbtree encode is significantly better, there are no spots on and around muzzle, and it is almost transparent to the source. Inspecting some other screenshots it's visible that mbtree is also better in noise/grain retention.

[poisondeathray]

With all the good, there is usually some bad....Just providing more observations of the trend towards "worse fades" These are just illustrative single frame examples , but EVERY frame in the fade sequences are clearly worse using mbtree. Detail seems to be missing, white clouds in the planet earth example, detail in the background buildings in the TDK example, more blurry, etc... I've done 2 other encodes (not posted here), and the fades seem to exhibit the same behaviour, I'll report back if I find anything different but so far it seems to be a reproducible trend
(Open them in tabs in your browser and flip back & forth)


planet earth trailer 1080i , 1740 frames
source available here: http://www.sendspace.com/file/cr48oe
avcsource,yadif(order=1),lanczosresize(720,400)
r1201, ref 5, 3b-frames, no b-pyramid, subme9, psy1:0, b-adapt2, 2pass 1000kbps

original
http://i26.tinypic.com/1ftrgj.png
mbtree
http://i32.tinypic.com/oa645h.png
no mbtree
http://i25.tinypic.com/n54kua.png



dark knight apple movie trailer 480p , 3042 frames
source available from Apple
r1201, ref 5, 3b-frames, no b-pyramid, subme9, psy1:0, b-adapt2, 2pass 1000kbps

original
http://i25.tinypic.com/wlvrz8.png
mbtree
http://i25.tinypic.com/29dtxys.png
no mbtree
http://i26.tinypic.com/nff9g3.png

[burfadel]

Thats a known side effect of mb-tree, weighted p-frames which is currently being worked on is meant to resolve that issue (as stated by DS).

[martinfrombern]

yep, seems like a signicant blur there :(

[poisondeathray]

Thats a known side effect of mb-tree, weighted p-frames which is currently being worked on is meant to resolve that issue (as stated by DS).

Thanks, I read that, and I know DS is already aware of this issue from earlier in the thread but I just promised to post some examples earlier and never got around to it till this weekend

BTW, I didn't mean to be negative or anything, I'm just providing some feedback/observations. I think these guys are doing an awesome job, and keep up the great work!

[popper]

poisondeathray, if you took the time to actually read the whole thread, you will realise fades are a known problem, and DS already said it will improve later when the other works done, read it, and keep in mind this is still a testing addition even though its committed for Non D9 readers to also see it and get it for testing.

[martinfrombern]

poisondeathray, if you took the time to actually read the whole thread, you will realise fades are a known problemi believe he pretty much knows that, because he was the one who mentioned fades in the first place. so i believe he's not the one who should actually read the whole thread

[Snowknight26]

I'm sure that only really happens in bitrate starved situations anyway.

[poisondeathray]

I'm sure that only really happens in bitrate started situations anyway.

You're probably right Mr. Touhou 50bits/s ! :D

[Fr4nz]

Did you mean "starved"? Well, for 480p 1000kbit/s is not so "starved"... :D

[CruNcher]

This is amazing just amazing parkrun @ 2 mbits 1pass and so great visually and that @ fantastic speeds i almost can't believe it (ok still some temporal fluctuations but hey 720p @ 2 mbits) :D if you compare how it looked like before in terms of artifacting (all the chroma problems colored lines that moved behind motion gone) this is imho a huge step for people knowing the complexity of this source :) not entirely sure what really improved it that much but mbtree alone can't be the only reason :)

And all this @ very sane compression settings :D

[Snowknight26]

Just tried doing a small 1080p sample encode of my Run Fatboy Run Blu-ray. To achieve the same SSIM (of whatever it was, I forget) using the same almost-placebo settings, the encode without mbtree was ~10000kbps while the one with it on was ~6000kbps. Visually identical to me at least.

[Chengbin]

Hey Dark Shikari

How much quality increase do you expect if I increase rc-lookahead to 100? Can I expect 1-2%?

[Sagekilla]

I'd imagine this would be one of those settings that, like ref frames, depend highly on the source in question. I don't think situations where one frame can have effects as far out as 100 frames away are very common, except maybe in anime. So I don't think the quality difference will be significant from 50 -> 100.

Theoretically, a larger lookahead should be better but in practice you might not even seen that difference. In anime you might, though.

[martinfrombern]

I did my tests on poisondeathray's planet earth trailer sample with various bitrates. Here come the results...
264 settings are
x264 --level 3.1 --ref 6 --mixed-refs --no-fast-pskip --bframes 4 --b-adapt 2 --b-pyramid --weightb --direct auto --deblock -3:-3 --subme 9 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh
--merange 32 --threads 6 --aq-strength 1.0 --psy-rd 1.0:0.0 --thread-input --no-dct-decimate --frames 1740 --fps 30000/1001
Screenshots
source / bitrate 500 mbtree / bitrate 500 nombtree / bitrate 1000 mbtree / bitrate 1000 nombtree / bitrate 1500 mbtree / bitrate 1500 nombtree / bitrate 2000 mbtree / bitrate 2000 nombtree
http://thumbnails14.imagebam.com/4491/235e3d44907080.gif (http://www.imagebam.com/image/235e3d44907080) http://thumbnails15.imagebam.com/4491/47939f44907082.gif (http://www.imagebam.com/image/47939f44907082) http://thumbnails8.imagebam.com/4491/9ef89744907064.gif (http://www.imagebam.com/image/9ef89744907064) http://thumbnails14.imagebam.com/4491/dd7c6f44907070.gif (http://www.imagebam.com/image/dd7c6f44907070) http://thumbnails17.imagebam.com/4491/dfd99444907071.gif (http://www.imagebam.com/image/dfd99444907071) http://thumbnails15.imagebam.com/4491/fb4afb44907073.gif (http://www.imagebam.com/image/fb4afb44907073) http://thumbnails15.imagebam.com/4491/b1d2de44907074.gif (http://www.imagebam.com/image/b1d2de44907074) http://thumbnails8.imagebam.com/4491/ca737344907075.gif (http://www.imagebam.com/image/ca737344907075) http://thumbnails16.imagebam.com/4491/538d2944907078.gif (http://www.imagebam.com/image/538d2944907078)
As can be seen, nombtree version is better with all bitrates :(

[shon3i]

Well, comparing to source mbtree to me looks much closer :)

[donis]

As can be seen, nombtree version is better with all bitrates :(True.

Is mbtree really worth to go official? Will all that mbtree adaptations affect picture quality
(in comparison with latest x264 builds w/o mbtree and it's adoptations) even when it will be disabled?

Will make few tests myself, and report back.

[juGGaKNot]

mbtree is comited, download any revision over 1200 and its on by default

--no-mbtree to not use it.

[Chengbin]

Guys, please read the thread.

mb-tree is NOT optimized for fades (yet). The upcoming weight-p will correct this.

[Betsy25]

At this moment, It would certainly make more logic to make --no-mbtree default though.

[donis]

At this moment, It would certainly make more logic to make --no-mbtree default though.Yup, I also think that way. :)

[Chengbin]

Give me a good reason?

mb-tree improves video quality on all video except fading. So you think mb-tree sucks just because of 1 scenario?

[Kurtnoise]

why a such claim ?

Anyway, you're free to not use the last updates. It's up to you after all...

[jdobbs]

I've noticed some odd behaviour that I thought I'd report. It has to do with resulting filesizes of CRF encodes when the mbtree option is enabled.

I have a routine that does short encodes of samples from a source in order to find the closest CRF to obtain correct filesizing (a "quick" first pass). I noticed it stopped working correctly when mbtree was enabled. It failed to converge on a CRF value. Disabling mbtree returns the routine to normal behavior. So I investigated and noticed that at some point it hits a strange situation in which a lower CRF value actually created a smaller (rather than larger) file. Here is an example (all using the same source):

CRF=22.36 --> Filesize: 1,276,648
CRF=22.20 --> Filesize: 1,302,169
CRF=22.14 --> Filesize: 1,304,863
CRF=22.13 --> Filesize: 1,303,447* (smaller than 22.14)
CRF=22.12 --> Filesize: 1,304,684* (smaller than 22.14)
CRF=22.11 --> Filesize: 1,304,552* (smaller than 22.14)
CRF=22.10 --> Filesize: 1,303,587* (smaller than 22.14)
CRF=22.09 --> Filesize: 1,559,003
CRF=22.08 --> Filesize: 1,557,601* (smaller than 22.09)
CRF=22.07 --> Filesize: 1,558,434* (smaller than 22.09)
CRF=22.06 --> Filesize: 1,558,228* (smaller than 22.09)

Since it is sample frames the source is small, in this case 96 frames. It's no big deal and I can work around it, but it seems a little odd that decreasing the CRF would result in a lowered filesize, so I though I'd report it.

Is this an expected side effect of mbtree?

[elguaxo]

@jdobbs

Also, note that CRF is redefined again by this patch--I set it so that it kept the same bitrate on Blackpearl as before, but it may vary for different videos.

"Redefining CRF" means that CRF's measure of quality changes, so some videos may have higher or lower bitrates at the same CRF.

[Dark Shikari]

It's probably just luck; at such tiny increments anything could cause that to happen.

MB-tree just increases the likelihood by significantly increasing the amount of quantizer modification.

[jdobbs]

Cool. :cool: Thanks. I did notice that in the results between the two (no-mbtree and default settings) -- mbtree shows a significantly lower CRF to get the same filesize.

[IgorC]

I did my tests on poisondeathray's planet earth trailer
Have you link to source or upload it somewhere like http://www.mediafire.com/ ?

[rack04]

Have you link to source or upload it somewhere like http://www.mediafire.com/ ?

http://forum.doom9.org/showthread.php?p=1312714#post1312714

[IgorC]

Oh, Thanks. Didn't see it was the same.

[Zachs]

I did notice with aq-mode 2, fades are good enough (as dark has mentioned). On non-fade scenes, quality is visually much closer to source vs no-mbtree.
aq-mode is 1 by default.

[Forteen88]

I did notice with aq-mode 2, fades are good enough (as dark has mentioned). On non-fade scenes, quality is visually much closer to source vs no-mbtree.
aq-mode is 1 by default.Where did he write that? Not here:
"my testing shows that fades, at least with b-adapt 2 and aq-mode 1, are usually good enough."
https://forum.doom9.org/showthread.php?p=1312014#post1312014

EDIT: @DS, okey I was a bit confused about that. Yeah, I prefer better image overall but tiny less good fades. Although I'll wait a while for weightp until I do new encodes.

[Dark Shikari]

Where did he write that? Not here:
"my testing shows that fades, at least with b-adapt 2 and aq-mode 1, are usually good enough."
https://forum.doom9.org/showthread.php?p=1312014#post1312014I think he was just referring to the fact that I said fades were good enough. I didn't do much testing with the different AQ modes though.

[Zachs]

Thanks Dark.

Darn, my post *was* confusing...

What I meant to say was, while fades are good enough (as Dark has mentioned), I did notice aq-mode 2 to be closer to source on fades than mode 1. And comparing non-fade scenes of the same encode between the 2 modes with mb-tree enabled, my eyes tell me they're about the same. aq-mode is set at 1 by default so it may be worth giving aq-mode 2 a try when using mb-tree.

[MasterNobody]

Fades can also look awful with --mbtree and --aq-mode 2. Here is my test (63.2 Mb): http://www.mediafire.com/?yjojzmznzzt
Also in this test I tried to compensate this effect by adding --aq-mode 3 based on the same idea as --aq-mode 2 but with fixed curve center (so more bias to dark scenes).
Used acronyms:
base: --aq-mode 0 --mbtree --b-adapt 2 --psy-rd 0:0 --psnr --ssim
std: --aq-mode 1 --no-mbtree --b-adapt 2 --psy-rd 0:0 --psnr --ssim
auto: --aq-mode 2 --no-mbtree --b-adapt 2 --psy-rd 0:0 --psnr --ssim
new: --aq-mode 3 --no-mbtree --b-adapt 2 --psy-rd 0:0 --psnr --ssim
mbtstd: --aq-mode 1 --mbtree --b-adapt 2 --psy-rd 0:0 --psnr --ssim
mbtauto: --aq-mode 2 --mbtree --b-adapt 2 --psy-rd 0:0 --psnr --ssim
mbtnew: --aq-mode 3 --mbtree --b-adapt 2 --psy-rd 0:0 --psnr --ssim
So you can compare --mbtree with --no-mbtree and between different AQ modes.
It was encoded on Core i7 so --threads auto == --threads 12

P.S. I even though --aq-mode 3 help in this test (and get the highest SSIM) its usefulness highly depend from source. Here are results for different sources: http://stashbox.org/594950/test.xls
P.P.S. Lossless source: http://www.mediafire.com/?kmzz5mdznr2