x264 "Macroblock Tree Ratecontrol" testing (committed)

[LoRd_MuldeR]

(Out of topic)
Why the encoders add lot lot lot lot of colors if the source is only count 256 colors?

x264 works on the YV12 colorspace. This means there are 12 bits per pixel: 8-Bit luma (brightness) per pixel and 2x8-Bit chroma (color) per 4-pixel-block.

Even if the source originally only had 256 colors, it will be up-converted to that "higher" color-resolution before it's fed into the encoder...

[Slabrdix]

Hi
I recently did some avinaptic DRF Analysis on MB-Tree Encoded Files
and all my results looked similar to this

[ DRF analysis ]
Average DRF: 26.961957
Standard deviation: 0.336384
Max DRF: 27

DRF<19: 0 ( 0.000 %)
DRF=19: 1 ( 0.000 %)
DRF=20: 0 ( 0.000 %)
DRF=21: 0 ( 0.000 %)
DRF=22: 16 ( 0.006 %)
DRF=23: 16 ( 0.006 %)
DRF=24: 3114 ( 1.232 %)
DRF=25: 53 ( 0.021 %)
DRF=26: 19 ( 0.008 %)
DRF=27: 249630 ( 98.727 %) #########################
DRF>27: 0 ( 0.000 %)

The Deviation was very very small, everything all P/B Frames seemed to have one DRF
ist that normal for MB-tree ?

[LoRd_MuldeR]

It has been explained various times why those frame-quantizers are absolutely useless as a quality measurement :search:

[MatLz]

I understand.
But result is bad...
Just take the source pic in xyloy's first post.
Do two imagesource scripts with one with converttoyv12.....
It's horrible!

[LoRd_MuldeR]

I understand.
But result is bad...
Just take the source pic in xyloy's first post.
Do two imagesource scripts with one with converttoyv12.....
It's horrible!

That's chroma subsampling! You can upscale the source by a factor 2 before converting it to YV12 in order to keep the full chroma resolution of the original...

http://en.wikipedia.org/wiki/Chroma_subsampling#Sampling_systems_and_ratios

[akupenguin]

Why the encoders add lot lot lot lot of colors if the source is only count 256 colors?
Because there aren't any good ways to lossily compress paletted images.

[VFR maniac]

Add missing fclose( rc->p_mbtree_stat_file_in ).


diff --git a/encoder/ratecontrol.c b/encoder/ratecontrol.c
index cb8a9d4..0037b12 100644
--- a/encoder/ratecontrol.c
+++ b/encoder/ratecontrol.c
@@ -841,6 +841,8 @@ void x264_ratecontrol_delete( x264_t *h )
x264_free( rc->psz_mbtree_stat_file_tmpname );
x264_free( rc->psz_mbtree_stat_file_name );
}
+ if( rc->p_mbtree_stat_file_in )
+ fclose( rc->p_mbtree_stat_file_in );
x264_free( rc->pred );
x264_free( rc->pred_b_from_p );
x264_free( rc->entry );

[Forteen88]

Is there a noticeably quality-increase when increasing from default rc-lookahead to 250?

EDIT: thx LoRd_MuldeR, I didn't know that "Placebo"-preset had that rc-lookahead value. Yeah, that surely gives me a hint :)

[LoRd_MuldeR]

Is there a noticeably quality-increase when increasing from default rc-lookahead to 250?

The fact the even x264's Placebo preset uses a value of "only" 60 should give you a hint on what the reasonable range for that option is ;)

Also note that the memory requirement for rc-lookahead 250 will be extraordinary...

[Snowknight26]

Also note that the memory requirement for rc-lookahead 250 will be extraordinary...

Over 4GB @ 1920x816.

[LoRd_MuldeR]

Over 4GB @ 1920x816.

This will be possible only with a 64-Bit build of x264 running on a 64-Bit OS. And of course more than 4 GB of physical RAM should be available ;)

Any 32-Bit build would certainly abort with memory allocation failure...

[burfadel]

Doesn't it also depend on keyframe frequency? if the maximum distrance between a keyframe is 80 frames, and you stipulate 250 as the lookahead, wouldn't it be more disadvantageous rather than advantageous to run such a high lookahead? (or needing to reduce CRF if in CRF mode?)...

[akupenguin]

if the maximum distrance between a keyframe is 80 frames, and you stipulate 250 as the lookahead
x264 doesn't let you do that.

[burfadel]

Sorry I mis-worded my response :) I meant the actual keyframe distance. If numerous I frames are needed for the material such that the maximum keyframe interval will only ever be 80 for that material, setting a too high rc-lookahead could reduce the quality since it would be limited the quality of the more frequent I-frames? (I hope that makes more sense...)

[akupenguin]

MB-tree doesn't look beyond scenecuts, only beyond keyframes forced by max-keyint. If you have I-frames more frequently than required by keyint, then they must have been scenecuts, so excess lookahead isn't detrimental. And if not, then the whole lookahead is useful.

[user822]

wow this one of the amazing downloads i ever had!

i tested it with Megui and Dxva Crf22 with provided and this version, my results with a small animation-clip:

old: 18,5MB
new: 9,97MB

Thanks alot!

[Chengbin]

wow this one of the amazing downloads i ever had!

i tested it with Megui and Dxva Crf22 with provided and this version, my results with a small animation-clip:

old: 18,5MB
new: 9,97MB

Thanks alot!

CRF has changed. With the same CRF, the MBtree encode will be much smaller.

[user822]

CRF has changed. With the same CRF, the MBtree encode will be much smaller.

thats the positive thing here :)

but same crf means same quality doesn't it?

[Chengbin]

thats the positive thing here :)

but same crf means same quality doesn't it?

No. It does not.

The scale for CRF changed, you can't compare CRF.

[LoRd_MuldeR]

but same crf means same quality doesn't it?

No, it doesn't. Same CRF gives roughly similar quality, but only for the same x264 version (CRF was re-defined several times in the past), the same settings (there are settings that effect both, the size and the quality, at a given CRF) and the same kind of source. The usual method is as follows: Try to find the highest possible CRF value that still gives satisfactory quality. And then use it!

[user822]

oke thanks for telling me that

just did some comparisions with Elecard Video Quality Estimator, i saw some little difference!

[me7]

oke thanks for telling me that

just did some comparisions with Elecard Video Quality Estimator, i saw some little difference!

The devs try to keep CRF as similar as possible. The addition of MB-Tree changed x264's behaviour so CRF was readjusted to produce the same results for "The Curse of the Black Pearl" as before if I remember correctly. Therefore it is no surprise that you see little diferrence, but this does not guarantee that the results stay the same for all sources.

[Zelos]

as mbtree drops some frames and so the final file is size reduced, do mbtree affect the overall quality ?

[dj_tjerk]

as mbtree drops some frames and so the final file is size reduced, do mbtree affect the overall quality ?
Where did you hear/read this?

[Dark Shikari]

as mbtree drops some frames and so the final file is size reduced, do mbtree affect the overall quality ?If it didn't affect the quality, what would be the point of it to begin with?

[Zelos]

that will be magic :p

[chipzoller]

Is mb-tree still conflicting with b-pyramids in r1271? If so, and if they're both enabled in the same line, does mb-tree override b-pyramid or the other way around?

[Dark Shikari]

Is mb-tree still conflicting with b-pyramids in r1271? If so, and if they're both enabled in the same line, does mb-tree override b-pyramid or the other way around?MB-tree overrides B-pyramid.

[benwaggoner]

MB-tree overrides B-pyramid.
Something you're working on? I'd think MB-tree would be a very useful tool in making optimum B-pyramid strucure decisions. But that could pretty quickly become a non-Euclidian tree :).

[Fr4nz]

Something you're working on? I'd think MB-tree would be a very useful tool in making optimum B-pyramid strucure decisions. But that could pretty quickly become a non-Euclidian tree :).

Hmm no, I think he means that "b-pyramid" is disabled if "mb-tree" is on :)

[kemuri-_9]

Hmm no, I think he means that "b-pyramid" is disabled if "mb-tree" is on :)

ben was asking if he's working on fixing it to where mb-tree and b-pyramid can be used together.

[benwaggoner]

ben was asking if he's working on fixing it to where mb-tree and b-pyramid can be used together.
...and giving a nod to it being quite tricky, since once you've got adaptive b-pyramid patterns, you don't even know frame is referencing which at first, which would make having mbtree be used in making b-pyramid decisions rather complex.

Hopefully the current mode makes decisions optimally enough that mbtree could be used after those decisions are locked down, and so decode order would already be known.

[yesgrey]

Is mb-tree still conflicting with b-pyramids in r1271? If so, and if they're both enabled in the same line, does mb-tree override b-pyramid or the other way around?
MB-tree overrides B-pyramid.
Even if I enable b-pyramid after the preset (that enables mb-tree by default)?
I did not knew about this and only after finishing the encoding I noticed a warning about it...
Here is the command line used:
x264 --preset slow --tune grain --crf 18.0 --level 4.1 --b-pyramid --ref 4 --aud
and the warning: [warning]: b-pyramid + mb-tree is not supported

So, can I assume that the b-pyramid enabling was ignored?

Thanks.

[Snowknight26]

Right.

[yesgrey]

Great.
I need to look carefully at any warnings in my next encodes... this time I got look.;)

[Chengbin]

One question suddenly hit me today.

DS, on what source did you get a 70% SSIM improvement on?

[Dark Shikari]

One question suddenly hit me today.

DS, on what source did you get a 70% SSIM improvement on?touhou

[benwaggoner]

touhou
After the first time I encoded from Touhou, I did a whiteboard pitch for a similar approach :). That source has such an intense combination of high-motion high-frequency and low-motion low-frequency regions that it utterly begs for some kind of motion-adaptive differential quantization.

It's nice to see that it's more generally applicable. I was able to do something similiar in PEP by setting QP manually per region of the frame, but that's not very scalable for content with edits.

[Chengbin]

I'm just curious, what part of mbtree conflicts with b-pyramid?

[IgorC]

One question suddenly hit me today.

DS, on what source did you get a 70% SSIM improvement on?

The answer is on the 2d page.

I'm just curious, what part of mbtree conflicts with b-pyramid?
The answer is on the 19th page.

[IgorC]

After the first time I encoded from Touhou, I did a whiteboard pitch for a similar approach :). That source has such an intense combination of high-motion high-frequency and low-motion low-frequency regions that it utterly begs for some kind of motion-adaptive differential quantization.

It's nice to see that it's more generally applicable. I was able to do something similiar in PEP by setting QP manually per region of the frame, but that's not very scalable for content with edits.
That's it!
In my humble opinion 'motion-adaptive differential quantization' is more informative,intuitive and easier to understand what actually this algorithm does. If I woulnd't read original post then I wouldn't get even a remote idea what is actually 'Macroblock tree ratecontrol'.

[Dark Shikari]

That's it!
In my humble opinion 'motion-adaptive differential quantization' is more informative,intuitive and easier to understand what actually this algorithm does. If I woulnd't read original post then I wouldn't get even a remote idea what is actually 'Macroblock tree ratecontrol'.But it's not correct either.

Motion-adaptive differential quantization was already tried years ago in x264 and it didn't work, so it wasn't committed.

[benwaggoner]

That's it!
In my humble opinion 'motion-adaptive differential quantization' is more informative,intuitive and easier to understand what actually this algorithm does. If I woulnd't read original post then I wouldn't get even a remote idea what is actually 'Macroblock tree ratecontrol'.
Well, I'll let DS decide if that's a fair description of how it works. My whiteboard meandering was more VC-1 centric, and focused on back-propogation of rate distortion optimization based on how improving quality in earlier reference macroblocks would reduce the number of bits required to get a good match in later motion vectors.

But I never thought it through in nearly the implementable detail that DS obvious has had to. I spent two years as a banking software maintenance engineer, and haven't been able to write code since :).

[IgorC]

But it's not correct either.

Motion-adaptive differential quantization was already tried years ago in x264 and it didn't work, so it wasn't committed.
I'm not an expert of signal theory neither know how actually mbtree is implemented. However can you explain a little bit more?
What would be mbtree in terms of signal processing theory if it's not already in those?

Thus instead of lowering quality in high-complexity scenes (like x264 currently does), it'll only lower quality on the complex part of the scene, while for example a static background will remain high-quality. It also has many other more subtle effects, some potentially negative, most probably not.
It sounds like adaptive quantization based on motion analysis.
More probably give a name of 'differential' quantization (DQ) wasn't appropriate here. Pretty sure I'm wrong but DQ quantize the differences so it has something to do with motion estimation, isn't it?

But seems like it's not the way how mbtree was implemented.

The only conclusion is that it's pretty dangerous to give names as I actually do. XD

[benwaggoner]

Pretty sure I'm wrong but DQ quantize the differences so it has something to do with motion estimation, isn't it?
Differential Quantization ("DQuant") simply means that the quantization parameter varies over the blocks in a frame. The default mode of codecs historically has been to use the same QP for a whole frame, and then do rate control by varying QP between frames. There's plenty of older codecs that don't support DQuant on a bitstream level.

[akupenguin]

"Motion-adaptive differential quantization" sounds like it describes some adaptation based on current motion. MB-tree is based on how well inter prediction works (which is only indirectly related to the amount of motion), and measures it over the next 40 frames (or however much you tell it to analyze).

[IgorC]

Differential Quantization ("DQuant") simply means that the quantization parameter varies over the blocks in a frame.
Isn't it adaptive quantization on macroblock level? http://mewiki.project357.com/wiki/X264_Settings

http://www.engineer.tamuk.edu/SPark/chap6.pdf


The default mode of codecs historically has been to use the same QP for a whole frame, and then do rate control by varying QP between frames. There's plenty of older codecs that don't support DQuant on a bitstream level.
Like divX ASP encoder.

"Motion-adaptive differential quantization" sounds like it describes some adaptation based on current motion. MB-tree is based on how well inter prediction works (which is only indirectly related to the amount of motion), and measures it over the next 40 frames (or however much you tell it to analyze).
thank you for clarifying.

[Redsandro]

What does it actually do?

It tracks the propagation of information from future blocks to past blocks across motion vectors. It could be described as localizing qcomp to act on individual blocks instead of whole scenes. Thus instead of lowering quality in high-complexity scenes (like x264 currently does), it'll only lower quality on the complex part of the scene, while for example a static background will remain high-quality. It also has many other more subtle effects, some potentially negative, most probably not.

I am obviously a bit less technical than most in this topic, but can I ask you to tickle my curiosity by explaining why this is necessary? I always thought that that's what a 2 pass encode is for.

[Astrophizz]

Whereas a 2-pass would alter the quality based on whole frames, macroblock tree ratecontrol allows variable quality within a frame.

[Redsandro]

Ah, thanks for the clarification. Is the result also MP4 specification complient so I can put it on BD and it plays in my HDTV?
Do you know when this patch was committed? Because I can use the improved quality, but I also need to use Jeeb's patched build (1183) for a tweak (I forgot the name) that makes the avc stream Blu-Ray complient, because standard x264 apparently does not. At least back in the day when I was figuring out what to use.