x264 "Macroblock Tree Ratecontrol" testing (committed) [Archive] - Page 6

Sharc

16th August 2009, 12:44

positive:
... in my tests (normal movies) i get 20-30 % higher bitrate without mbtree
negative:
... sometimes in dark scenes i see very blocky picture where with --no-mbtree the picture was good

It seems that you are contradicting yourself. It's pointless to compare 2 methods at unequal bitrates/filesizes. Is the blockiness still there with mbtree at 20-30% higher bitrate (to compare with the --no-mbtree result)?

Dark Shikari

16th August 2009, 12:51

0 for maximum mbtree is bad
default might be bad for psy rd as you said
1.0 will disable mbtree

so when will the default be right ?

and if it is 0 why does the bitrate vary so much ? 12 mb ?

it would be nice to have a valid "quality reference"

ratefactor is 11, quality is good but not great and fades suck.Again, I am not responsible for what happens when you tweak options that you don't understand.

juGGaKNot

16th August 2009, 13:15

Again, I am not responsible for what happens when you tweak options that you don't understand.

the fades actually look better with qcomp 0 than with default but still suck.

Japhsoncross

16th August 2009, 14:01

I think we just need some patient until weightp is ready, which is particularly useful for fades.

juGGaKNot

16th August 2009, 14:13

ofc but in general qcomp 0 looks better now than default

i will try larger lookahead values than the slow profile gives me.

BTW
what values are safe for lookahead

i want to make a script for ram

if 512 than look=20
if 1024than look=40
if 2048 than look=60
if 4096 and windows x64 than look=80
if 8192 and windows x64 than look=keyint/2

would be safe ?

LE :

something like this :

set head=50
GOTO A0
:A0
if %myram% LEQ 128 GOTO set1
if %myram% GEQ 129 GOTO A1
:A1
if %myram% LEQ 256 GOTO set2
if %myram% GEQ 257 GOTO A2
:A2
if %myram% LEQ 512 GOTO set3
if %myram% GEQ 513 GOTO A3
:A3
if %myram% LEQ 1024 GOTO set4
if %myram% GEQ 1025 GOTO A4
:A4
if %myram% LEQ 1536 GOTO set5
if %myram% GEQ 1537 GOTO A5
:A5
if %myram% LEQ 2048 GOTO set6
if %myram% GEQ 2049 GOTO A6
:A6
if %myram% LEQ 3072 GOTO set7
if %myram% GEQ 3073 GOTO A7
:A7
if %myram% LEQ 4096 GOTO set8
if %myram% GEQ 4097 GOTO A8
:A8
if %myram% LEQ 6144 GOTO set9
if %myram% GEQ 6145 GOTO A9
:A9
if %myram% LEQ 8192 GOTO set10
if %myram% GEQ 8193 GOTO A10
:A10
if %myram% LEQ 12288 GOTO set11
if %myram% GEQ 12289 GOTO set12
:SET1
set head=20
GOTO END
:SET2
set head=30
GOTO END
:SET3
set head=40
GOTO END
:SET4
set head=50
GOTO END
:SET5
set head=60
GOTO END
:SET6
set head=70
GOTO END
:SET7
set head=80
GOTO END
:SET8
set head=90
GOTO END
:SET9
set head=100
GOTO END
:SET10
set head=150
GOTO END
:SET11
set head=200
GOTO END
:SET12
set head=250
GOTO END
:END

lookahead 100 uses ~900mb on my sistem so i think its safe, also people with more than 4 gb have a quad so looks k right ?

Zarxrax

16th August 2009, 17:14

BTW
what values are safe for lookahead

i want to make a script for ram

The lookahead isnt the only thing on your system that uses ram. It's not even the only thing in the encoding process that uses ram. This is impossible and pointless.

LoRd_MuldeR

16th August 2009, 17:22

The lookahead isnt the only thing on your system that uses ram. It's not even the only thing in the encoding process that uses ram. This is impossible and pointless.

It only matters how many memory is used inside the encoder process, because there is a 2 GB limit for that in 32-Bit process (even on a 64-Bit system and OS).

The global memory isn't that critical, because even if the OS runs out of physical RAM, it can still use the page file. It will be slow, but it won't cause processes to fail.

But if Avisynth input is used, this may consume a lot of memory inside the encoder process. Running Avisynth in its own process (avs2yuv) can relax the problem...

juGGaKNot

16th August 2009, 17:41

The lookahead isnt the only thing on your system that uses ram. It's not even the only thing in the encoding process that uses ram. This is impossible and pointless.

what if i set lookahead to 100 and someone has 256mb of ram

on my system it goes to 900mb easy, why would it be pointless to have a script based on ram ?

kemuri-_9

16th August 2009, 19:52

on my system it goes to 900mb easy, why would it be pointless to have a script based on ram ?

you obviously skipped this part I already mentioned:
frames are relatively complex in their allocation and have a number of factors relating to what parameters were given on the command line (the cpu's cacheline split comes into play here too) in addition to the standard resolution/ mb count factors.
look at the code for x264_frame_new (http://git.videolan.org/gitweb.cgi?p=x264.git;a=blob;f=common/frame.c;hb=HEAD) to get the picture.

the major factor of a frame's size is the video's resolution. then there are other factors based on the numerous options given on the command line and cpu x264 is running on.
because of this, attempting to script the optimal size of the lookahead will only lead to utter failure.
that is unless you actually do take every factor into account and that would generate one entirely nasty script.

Edit:
not to mention that allocation of frames is not the only place where x264 uses ram, it's just generally the largest.

lych_necross

16th August 2009, 22:40

Another option would be raising "qcomp" a bit and lower the effect of MBTree RC for now. Worth a try at least, I think...
qcomp option aside, couldn't you also lower the CRF value a little bit to compensate?

DarkZell666

16th August 2009, 23:06

I suppose it doesn't matter if the lookahead value isn't optimal, it's just got to be reasonable, and it should increase with the amount of free ram, nevermind if the optimal value is 25% higher than what the script gives. The pitfall here is the script needs to be as pessimistic as possible so as not to overflow the available RAM for systems where pagefile is disabled, since others won't be affected (and if the script could actually detect if the pagefile enabled and act accordinglyt, it's even better :p). A small optimisation is better than none. We've all checked that out many times over here on d9.

x264 itself can't know in advance if the user will launch other processes that will eat up the free ram at the same time, and this with or without mbtree. It doesn't change anything to the situation.

@juGGaKNot: Keep up with your idea, the problem's not trivial but definately solvable :)

burfadel

17th August 2009, 01:52

Disabling the pagefile isn't a good idea IMO for anything less than 6GB of RAM, although for 8GB of RAM I'd probably say its better for now. This is relevant because if the RAM overflows due to the mbtree being 'too high', aka set to a predetermined value based on total RAM, including when you have all the programmes you normally use open, then you do not have enough RAM to disable the pagefile in the first place! This would just add complexity to x264. You'd also have to include resolution in this scenario if you wish it to be dynamic, a mb-tree of 100 at 640x352 would still use less RAM than mb-tree of 50 at 1920x1080, yet you'd be limiting mb-tree to 50 for the lower resolution? Mb-tree size would have to be calculated via expected x264 allocation of RAM, such that x264 ram use is kept to say 1gb on 2gb of system RAM etc, with a minimum mb-tree of the current 40 for example. Afterall, setting it too low isn't ideal. Having it dynamic based on RAM alone is not an optimal solution, at least thats what I think :) Maybe a dynamic range of 40-120 (depending on keyint), if keyint is less than that then of course it is limited.

Just a question regarding mb-tree, does it search to say 100 frames every time, or is the scenecut decision taken in to account so the algorithm terminates early where a keyframe is required? I take it the mb-tree data is reused? I see the memory use is fairly stable for x264, if mb-tree does terminate for that time due to scenecut decision does the RAM allocation for x264 stay as a 'frame pool' size? it seems to otherwise the memory would vary significantly which would degrade performance due to Windows memory & cacheing system?...

IgorC

17th August 2009, 03:12

I set lookahead at 300 but avinaptic informs it's 250.
Why is that?

Settings of two passes:
x264.exe --slow-firstpass --aq-mode 2 --rc-lookahead 300 --mbtree --threads 2 --pass 1 --stats "cx264_stat.log" --qcomp 0.6 --bframes 16 --b-adapt 2 --weightb --subme 10 --keyint 300 --ref 16 --trellis 2 --mixed-refs --8x8dct --partitions all --direct auto --bitrate 380 --no-fast-pskip --me tesa --merange 16 --deblock 0:0 --psy-rd 0.2:0.0 -o t.mp4 1.avs --psnr --ssim

x264.exe --aq-mode 2 --mbtree --rc-lookahead 300 --threads 2 --pass 3 --stats "cx264_stat.log" --qcomp 0.6 --bframes 16 --b-adapt 2 --weightb --subme 10 --keyint 300 --ref 16 --trellis 2 --mixed-refs --8x8dct --partitions all --direct auto --bitrate 380 --no-fast-pskip --me tesa --merange 16 --deblock 0:0 --psy-rd 0.2:0.0 -o t2.mp4 1.avs --psnr --ssim

Dark Shikari

17th August 2009, 03:16

Max is 250 for now.

akupenguin

17th August 2009, 05:39

Just a question regarding mb-tree, does it search to say 100 frames every time, or is the scenecut decision taken in to account so the algorithm terminates early where a keyframe is required?
mbtree terminates at a keyframe in psnr-optimal mode, but not in psy mode, because terminating at a keyframe produces unacceptable fluctuations in quality.

does the RAM allocation for x264 stay as a 'frame pool' size? it seems to otherwise the memory would vary significantly which would degrade performance due to Windows memory & cacheing system?
x264 allocates memory the first time it's needed, and then doesn't free anything until the end of the stream.

IgorC

17th August 2009, 07:39

I think all those complains about bad quality on fades have good reason to exist. There are strong artefacts on dark areas wich weren't actually present on 1195+mbtree patch.
I don't know if it's regression (1195+mbtree patch <->1210 ) or it's caused by high value of lookahead ( I raised it from 40 to 250) on Elephant's Dream 360p lossless video (interval 4:07-4:17 looks extremely bad)

I don't have time right now but I will do some test around 1195/1210 revisions and different values of lookahead.

Maybe have I borked something around settings?
x264.exe --slow-firstpass --aq-mode 2 --rc-lookahead 250 --mbtree --threads 2 --pass 1 --stats "cx264_stat.log" --qcomp 0.6 --bframes 16 --b-adapt 2 --weightb --subme 10 --keyint 300 --ref 16 --trellis 2 --mixed-refs --8x8dct --partitions all --direct auto --bitrate 328 --no-fast-pskip --me tesa --merange 16 --deblock 0:0 --psy-rd 0.2:0.0 -o t.mp4 1.avs --psnr --ssim

x264.exe --aq-mode 2 --rc-lookahead 250 --mbtree --threads 2 --pass 3 --stats "cx264_stat.log" --qcomp 0.6 --bframes 16 --b-adapt 2 --weightb --subme 10 --keyint 300 --ref 16 --trellis 2 --mixed-refs --8x8dct --partitions all --direct auto --bitrate 328 --no-fast-pskip --me tesa --merange 16 --deblock 0:0 --psy-rd 0.2:0.0 -o t2.mp4 1.avs --psnr --ssim

Mr. Brown

17th August 2009, 09:51

It seems that you are contradicting yourself. It's pointless to compare 2 methods at unequal bitrates/filesizes. Is the blockiness still there with mbtree at 20-30% higher bitrate (to compare with the --no-mbtree result)?

I have tested all modes 2pass & 1pass of course i have noticed the higher bitrate at 1pass crf 22 with --no-mbtree
and 2pass with mbtree and with --no-mbtree at same bitrrate is really a difference in quality in dark scenes.

Forteen88

17th August 2009, 12:02

..when Trahald finishes MMCO-related stuff.I'm just wondering, when (approximately) is that finished? Are we talking weeks, month(s), year? I'm not sure if I should wait, or not care (and continue encoding) if it takes too long :)

EDIT: Thanks froggy1 and Underground78

CruNcher

18th August 2009, 13:20

--me hex --ref 2 --mixed-refs --trellis 1 --subme 5

Does Mbtree need anything of this to actually work (dependent on it) ? (result bellow answered this question ;) )

CRF = 23 (--mbtree)

x264 [info]: SSIM Mean Y:0.9764634
x264 [info]: PSNR Mean Y:43.242 U:47.222 V:46.687 Avg:44.071 Global:42.283 kb/s:
1234.12

encoded 3634 frames, 24.63 fps, 1234.38 kb/s

CRF = 25 (--no-mbtree)

x264 [info]: SSIM Mean Y:0.9749972
x264 [info]: PSNR Mean Y:43.137 U:46.977 V:46.403 Avg:43.930 Global:41.698 kb/s:
1253.87

encoded 3634 frames, 26.91 fps, 1254.10 kb/s

CRF = 24 (--no-mbtree)

x264 [info]: SSIM Mean Y:0.9776573
x264 [info]: PSNR Mean Y:43.724 U:47.395 V:46.867 Avg:44.491 Global:42.291 kb/s:
1440.21

encoded 3634 frames, 26.38 fps, 1440.44 kb/s

CRF = 23 (--no-mbtree)

x264 [info]: SSIM Mean Y:0.9801169
x264 [info]: PSNR Mean Y:44.315 U:47.829 V:47.341 Avg:45.058 Global:42.895 kb/s:
1656.50

encoded 3634 frames, 25.57 fps, 1656.73 kb/s

CRF = 21 (--mbtree)

x264 [info]: SSIM Mean Y:0.9810367
x264 [info]: PSNR Mean Y:44.344 U:48.054 V:47.617 Avg:45.141 Global:43.430 kb/s:
1628.80

encoded 3634 frames, 23.49 fps, 1629.05 kb/s

Nice saving for the Speed cost :)

nakTT

18th August 2009, 13:42

I'm just wondering, when (approximately) is that finished? Are we talking weeks, month(s), year? I'm not sure if I should wait, or not care (and continue encoding) if it takes too long :)
Yeah. I also looking for the same clue.

:thanks:

microchip8

18th August 2009, 16:24

Yeah. I also looking for the same clue.

:thanks:

IIRC and correct me if I'm wrong, the GSOC ends on 24th this month and that's when those working on stuff for x264 have to deliver.

nakTT

18th August 2009, 16:32

IIRC and correct me if I'm wrong, the GSOC ends on 24th this month and that's when those working on stuff for x264 have to deliver.
Thanks for sharing this valuable info. I guess I will hold my encoding and wait until everything sorted out at the end of this month

:thanks:.

Underground78

18th August 2009, 16:35

Timeline for weighted prediction is here (http://wiki.videolan.org/SoC_2009/Weighted_P-frame_Prediction#Timeline) but I think it can take some time before the patch is committed.

Riki

18th August 2009, 22:03

What would be a reasonably high setting. Right now Im testing it with 100 but wonder if I can go higher. I have a dual xeon mac pro with 16GB of ram, running x264 in 64bit so it should be able to handle it, I just want to stay in a reasonably high range.

nurbs

18th August 2009, 22:11

--preset veryslow uses a lookahead of 80 frames, so I guess you are already in high territory, considering only --preset placebo is slower.

juGGaKNot

18th August 2009, 22:26

--preset veryslow uses a lookahead of 80 frames, so I guess you are already in high territory, considering only --preset placebo is slower.

it does not

else if( !strcasecmp( optarg, "veryslow" ) )
{
param->analyse.i_me_method = X264_ME_UMH;
param->analyse.i_subpel_refine = 10;
param->analyse.i_me_range = 24;
param->i_frame_reference = 16;
param->i_bframe_adaptive = X264_B_ADAPT_TRELLIS;
param->analyse.i_direct_mv_pred = X264_DIRECT_PRED_AUTO;
param->analyse.inter |= X264_ANALYSE_PSUB8x8;
param->analyse.i_trellis = 2;
param->i_bframe = 8;
param->rc.i_lookahead = 60;

http://mewiki.project357.com/wiki/X264_Settings

nurbs

18th August 2009, 22:41

Oh well, my point still stands.

akupenguin

19th August 2009, 04:22

High would be 250. mbtree doesn't have a huge speed cost, defaults are limited mostly for memory.

Boolsheet

19th August 2009, 04:22

Does mbtree in intra-only mode actually do something?
Because x264 (JEEB's unpatched 1214 x64 build for me) throws a warning but no error and exits if intra-only and mbtree are on:
"x264 [warning]: specified frame type (3) is not compatible with keyframe interval"

Nothing is written in the output file.
Anyone else getting this with mbtree on and --keyint 1?

If I'm understanding it correctly, mbtree only affects the frames in one GOP. There would be no reason to use mbtree with keyint 1.
I don't know... maybe a check for intra-only could fix this if mbtree is not used for anything else.

Dark Shikari

19th August 2009, 04:29

Riki

19th August 2009, 04:58

High would be 250. mbtree doesn't have a huge speed cost, defaults are limited mostly for memory.

wow, thats interesting to note!

Thanks for the others who responded too, man this new feature is AMAZING for camtasia training videos, you have NO IDEA! :)

Great work Dark

G_M_C

19th August 2009, 07:28

Max is 250 for now.

But it is still clamped to --keyint isnt it (which is logical to me) ?

wyti

19th August 2009, 08:13

Yes, but why this limit of 250 ?
On SD contents you can easily go beyond 250 with the 2Go of RAM on 32bits, and with 64bits there would be ne reason to hard limit it.
Is there a erason behind this max value or is this only "idiot proof" ?

G_M_C

19th August 2009, 08:45

wyti

19th August 2009, 09:36

depend on content bu usualy with anime I use about 1000 (seeking don't mind cause with my core i7 it's fast enough^^) and with desktop capture i go up to 5000 (yeah pretty insane) so i think higher mbtree than 250 might help me.

laserfan

19th August 2009, 13:19

OK, you're just making this u--wait a minute, what's this new statsfile, and why is it using up all my hard disk space?

Oh, that? (http://i26.tinypic.com/2s6odxt.jpg) Kyahahahahahaha. (http://mirror05.x264.nl/Dark/ahaha.wav)As a casual user of x264, I just did my first encoding with it and the other (relatively new) defaults using JEEB's b1214M and it looks absolutely amazing--thanks to DS and all who contributed to its creation!

I do so few of these that I save all my files & logs e.g. I used (and save) the video.stats file cuz I'm able to see where the I frames are for some post-encoding chapter marks for my blu-ray muxed output. But I see nothing in that monster video.stats.mbtree that is readable-thus-useable. So it's fine just to toss it? And if there DOES turn-out to be some problem with the encoding there won't be any "post your mbtree file" requests will there?! :eek: ;)

Dark Shikari

19th August 2009, 15:46

As a casual user of x264, I just did my first encoding with it and the other (relatively new) defaults using JEEB's b1214M and it looks absolutely amazing--thanks to DS and all who contributed to its creation!

I do so few of these that I save all my files & logs e.g. I used (and save) the video.stats file cuz I'm able to see where the I frames are for some post-encoding chapter marks for my blu-ray muxed output. But I see nothing in that monster video.stats.mbtree that is readable-thus-useable. So it's fine just to toss it? And if there DOES turn-out to be some problem with the encoding there won't be any "post your mbtree file" requests will there?! :eek: ;)Correct; the MB-Tree file is just a massive dump of quantizers, with nothing human-readable; technically it contains frametypes too, but that's just so that x264 can sanity check the input to make sure it's not completely junk.

laserfan

19th August 2009, 16:41

Correct; the MB-Tree file is just a massive dump of quantizers, with nothing human-readable; technically it contains frametypes too, but that's just so that x264 can sanity check the input to make sure it's not completely junk.Thanks for your reply, which is actually quite a relief to me! :D

benwaggoner

20th August 2009, 06:34

Thanks for the others who responded too, man this new feature is AMAZING for camtasia training videos, you have NO IDEA! :)
That's probably the content I'd expect to benefit the most, really, since you can have 100% perfect matches without any noise, plus some perfect motion vector matches with perfectly 2D motion.

LeonLanford

20th August 2009, 14:45

sorry I just want to ask a little thing,
will it be compatible with bipyramid in the future?

Thanks

Fr4nz

20th August 2009, 14:55

sorry I just want to ask a little thing,
will it be compatible with bipyramid in the future?

Thanks

Yes, but there isn't a timeline yet. Should be soon anyway.

Snowknight26

22nd August 2009, 07:59

http://i28.tinypic.com/20trs4m.png

Only 5500 frames in. Seems like a large amount of RAM. I wonder if all of it is being released properly. What's the theoretical maximum RAM that mbtree alone could take up with the lookahead set to 250 on a 1920x1080 encode?

22nd August 2009, 10:52

Only 5500 frames in. Seems like a large amount of RAM. I wonder if all of it is being released properly. What's the theoretical maximum RAM that mbtree alone could take up with the lookahead set to 250 on a 1920x1080 encode?
http://forum.doom9.org/showthread.php?p=1314527#post1314527

250 * 12 MB + metadata > 3000 MB, so your observation seems pretty normal.

Sagittaire

22nd August 2009, 20:09

I have really spectacular result on OPSNR on my old trailer test: more than 0.2 dB progress. This time x264 is on par with historical DivX3 at half bitrate with really recent build for DivX3 (libavcodec).

yaous

23rd August 2009, 11:24

sorry for the newbie question..

what's the difference between AQ and MB-Tree?

is MB-Tree something like 'detailed AQ'?

nurbs

23rd August 2009, 12:03

As I understand it AQ lowers the quantizer in less complex parts of a frame in order to avoid artefacts like blocking on uniform backgrounds while MB-Tree lowers quantizer on macroblocks that are referenced more often by other frames to aid prediction.
That may be oversimplified, but I think it basically covers it.

TheImperial2004

23rd August 2009, 14:26

A quick question : What will happen if you ran out of RAM while encoding ? Does x264 release RAM after it encode the frame ?

I asked this because , while I encode , RAM reached 0 without crashing and the OS stays responsive ???

Chengbin

23rd August 2009, 14:29

LoRd_MuldeR

23rd August 2009, 14:34

A quick question : What will happen if you ran out of RAM while encoding ? Does x264 release RAM after it encode the frame ?

AFAIK x264 will allocate the required memory at the beginning of the encode and not release any memory until the encoding is finished.

I asked this because , while I encode , RAM reached 0 without crashing and the OS stays responsive ???

32-Bit processes can allocate a maximum of 2 GB of RAM, even if more physical RAM is available and even on a 64-Bit OS.

So probably x264 ran into the 2 GB limit, while the OS still had enough RAM available for its own stuff...

TheImperial2004

23rd August 2009, 14:54

32-Bit processes can allocate a maximum of 2 GB of RAM, even if more physical RAM is available and even on a 64-Bit OS.

So probably x264 ran into the 2 GB limit

I'm not sure becuase I use AviDemux , but if encoding a file with Mb-tree needs 3GB for example , and x264 limited at 2GB . Will that affect encoding quality or compression capability ?