MB-Tree

[egrimisu]

It is advantageous to use mb-tree when using crf, will it get a smaller file resulting the same video quality? i'm encoding an anime, Heidi remastered edition exaclty.

[nm]

It is advantageous to use mb-tree when using crf

Certainly!

will it get a smaller file resulting the same video quality?

Quality/bitrate should be better, but you may need to adjust CRF to get about the same quality or the same bitrate as previously.

[LoRd_MuldeR]

It is advantageous to use mb-tree when using crf, will it get a smaller file resulting the same video quality?

As nm already said, you should be able to get away with a lower bitrate for the "similar" visual quality, but you may have to re-adjust your CRF value for that.

Easiest method to compare "MB-Tree -vs- No MB-Tree" is making two encodes at the same target bitrate (2-Pass mode!) and then compare the results visually.

(Of course you must pick a "reasonable" target bitrate for such test. If the "No MB-Tree" encode looks great already, there isn't much to gain for MB-Tree)

i'm encoding an anime, Heidi remastered edition exaclty.

MB-Tree should be especially helpful for Anime. Look at this 67 kbps example:
http://x264.nl/developers/Dark_Shikari/Flash/lowbitrateanime.html

[egrimisu]

thanks guys.

[Firebird]

I was bored enough to reencode losslessmaikaze with latest build.

http://www.mediafire.com/?735o5zuu5kazysg

[egrimisu]

thanks. i got the ideea but it seems that even at good bitrate grains are washed out, when encoding with no-mbtree thinks look more transparent with the source.

[nm]

What settings are you using exactly in both cases?

[egrimisu]

--no-mbtree --qcomp 0.8 --aq-strength 0.7 --ipratio 1.1 --pbratio 1.1 --thread-input --level 4.1 --merange 64 --ref 16 --rc-lookahead 150 --fade-compensate 0.8 --deblock -2:-2 --no-dct-decimate --no-fast-pskip --keyint 240 --min-keyint 24

and

--qcomp 0.8 --aq-strength 0.7 --ipratio 1.1 --pbratio 1.1 --thread-input --level 4.1 --merange 64 --ref 16 --rc-lookahead 150 --fade-compensate 0.8 --deblock -2:-2 --no-dct-decimate --no-fast-pskip --keyint 240 --min-keyint 24

[LoRd_MuldeR]

--no-mbtree --qcomp 0.8 --aq-strength 0.7 --ipratio 1.1 --pbratio 1.1 --thread-input --level 4.1 --merange 64 --ref 16 --rc-lookahead 150 --fade-compensate 0.8 --deblock -2:-2 --no-dct-decimate --no-fast-pskip --keyint 240 --min-keyint 24

and

--qcomp 0.8 --aq-strength 0.7 --ipratio 1.1 --pbratio 1.1 --thread-input --level 4.1 --merange 64 --ref 16 --rc-lookahead 150 --fade-compensate 0.8 --deblock -2:-2 --no-dct-decimate --no-fast-pskip --keyint 240 --min-keyint 24

First of all "--no-fast-pskip" is a placebo option. See:
http://forum.doom9.org/showpost.php?p=1384029&postcount=7

Moreover "--qcomp" is something you shouldn't touch.

[egrimisu]

First of all "--no-fast-pskip" is a placebo option. See:
http://forum.doom9.org/showpost.php?p=1384029&postcount=7

Moreover "--qcomp" is something you shouldn't touch.

i saw you had a somkind of x264 parameters explaination manual on your web site that is down, could so send it to me, i would like to read more. It seems that i miss a lot of thing and i would be better reading more than disturbing people .

[LoRd_MuldeR]

i saw you had a somkind of x264 parameters explaination manual on your web site that is down, could so send it to me, i would like to read more.

Have a look here:
http://avidemux.org/admWiki/doku.php?id=tutorial:h.264

(I know that the article needs update)

[Sharktooth]

here's a list of commandline options to COMPLETELY replace yours:
--level 4.1 --preset veryslow --tune film --keyint 240 --min-keyint 24

or (if you're insane)

--level 4.1 --preset placebo --tune film --keyint 240 --min-keyint 24

if you're not satisfied by the grain retention try also --tune grain in place of --tune film

[egrimisu]

i'll give it a try see what's diferent , does the --tune film good for grainy animations?
the grain preset s good but eats a lot of bitrate that's why i'm avoiding it.

here's a list of commandline options to COMPLETELY replace yours:
--level 4.1 --preset veryslow --tune film --keyint 240 --min-keyint 24

or (if you're insane)

--level 4.1 --preset placebo --tune film --keyint 240 --min-keyint 24

if you're not satisfied by the grain retention try also --tune grain in place of --tune film

[nm]

the grain preset s good but eats a lot of bitrate that's why i'm avoiding it.
Always compare quality at the same bitrate or bitrate at the same quality!

[nurbs]

--min-keyint 24 is redundant, because if you set --keyint 240 it will be set to 24 automatically.

[LoRd_MuldeR]

Always compare quality at the same bitrate or bitrate at the same quality!

That plus: The "--tune grain" is for preserving grain at high bitrate encodes, where the complexity caused by random grain/noise dominates all the rest (that's why it lowers AQ strength, for example).

At medium to low bitrates you won't be able to preserve the grain, to begin with. So you'll be better off with "--tune film" in that case.

[egrimisu]

That plus: The "--tune grain" is for preserving grain at high bitrate encodes, where the complexity caused by random grain/noise dominates all the rest (that's why it lowers AQ strength, for example).

At medium to low bitrates you won't be able to preserve the grain, to begin with. So you'll be better off with "--tune film" in that case.

and what is a high bitrate for a dvd resolution film? >should 5000 be enough ?

[nm]

and what is a high bitrate for a dvd resolution film? >should 5000 be enough ?

Should be high enough for good grain retention.

[egrimisu]

That plus: The "--tune grain" is for preserving grain at high bitrate encodes, where the complexity caused by random grain/noise dominates all the rest (that's why it lowers AQ strength, for example).

At medium to low bitrates you won't be able to preserve the grain, to begin with. So you'll be better off with "--tune film" in that case.

i have noted that with mb-tree on the encode at the same bitrate as the no-mbtree one has lower quality in dark grainy areeas, even with crf 15.

[nm]

i have noted that with mb-tree on the encode at the same bitrate as the no-mbtree one has lower quality in dark grainy areeas, even with crf 15.

A sample clip (source and encoded video) might help with finding the cause.

[Didée]

From a naive point of view, this isn't a big surprise. MB-tree basically tracks detail through time. Something that "is there" for several frames ... is more important than something that's there for only one frame.

Grain, per quasi-definition, is "detail that changes every frame". So it's not difficult to imagine what MB-tree "thinks" about grain. And of course, in a dark scenery every unwanted deviation is much more obvious, since small changes have a big "relative" energy. As we all know from banding artifacts ... not very obvious in bright scenes, but a big pain in dark scenes.

[LoRd_MuldeR]

From a naive point of view, this isn't a big surprise. MB-tree basically tracks detail through time. Something that "is there" for several frames ... is more important than something that's there for only one frame.

...and therefore relying on frame-by-frame comparison too much might be misleading here. One should also judge the effect of MB-Tree in motion.

[egrimisu]

A sample clip (source and encoded video) might help with finding the cause.

i'm out of town , typing from my laptop, but as soon as i'm getting home tommrow i'll upload a sample. around 18:00 gmt+2

thanks.

[kolak]

...and therefore relying on frame-by-frame comparison too much might be misleading here. One should also judge the effect of MB-Tree in motion.

Not sure if this was caused by MB-Tree, but sometimes grainy backgrounds becames unstable- once other encoders make it just softer, x264 keeps sharpness, but makes noise loosing its shape and creates patches.

Andrew

[Brazil2]

i have noted that with mb-tree on the encode at the same bitrate as the no-mbtree one has lower quality in dark grainy areeas, even with crf 15.
Yes I agree and from my own experience I've stopped using MB-Tree with dark sources because it's making the resulting file darker than the original with the loss of many details. I usually encode movies, TV shows and sports (DVD's or DVB recordings) at CRF=18-22 Preset=slower and Tune=film.

[laserfan]

I've stopped using MB-Tree
Please, can someone explain in lay terms why mb-tree is Default? If some here are turning it OFF, for what reason(s) should it be left ON?

[sneaker_ger]

Because the x264 devs think that it will increase quality for the majority of sources and only hurt it in relatively few cases - simple as that.
And since it redistributes bits it will decrease quality in areas that are not considered important, so things like these are bound to happen unless someone finds a smarter way to redistribute them.

[kolak]

Blu-code quite well distributes bits over whole frame, so even background has relatively good quality- distribution is probably the best from all AVC encoders.


Andrew

[Didée]

Random idea, perhaps too naive and impractical, but ... what about making MB-tree luma dependent? Since the negative reports are mostly concerned with dark areas or scenes, wouldn't it be feasable to make MB-tree act more weakly (or even deactivate it) in areas with low luminosity?

[egrimisu]

I'd love that. at crf 17 i can't make diference between encode and source in light scenes. So probably is doing great job in light scenes.

Random idea, perhaps too naive and impractical, but ... what about making MB-tree luma dependent? Since the negative reports are mostly concerned with dark areas or scenes, wouldn't it be feasable to make MB-tree act more weakly (or even deactivate it) in areas with low luminosity?

[benwaggoner]

Yeah, back in the CRT days, gamma was perceptually uniform, so the difference between Y'=16 and Y'=17 was the same relative change as Y'=216 and Y'=217. Perceptual uniformity is a basic assumption of most codecs.

But LCDs are a very different underlying technology, with much less range of luma in the low values; there's generally quite a visible difference between Y'=16 and Y'=17. So a file that would look great on CRT can show all kinds of low-luma problems on a LCD. Luma-sensitive perceptual optimizations are required to make sure video quality on LCD is good.

[egrimisu]

"Luma-sensitive perceptual optimizations" and how can this be done?

[laserfan]

Please, can someone explain in lay terms why mb-tree is Default? If some here are turning it OFF, for what reason(s) should it be left ON?

Because the x264 devs think that it will increase quality for the majority of sources and only hurt it in relatively few cases - simple as that.
And since it redistributes bits it will decrease quality in areas that are not considered important, so things like these are bound to happen unless someone finds a smarter way to redistribute them.
Thank you, that's exactly what I was looking for! :)

[benwaggoner]

"Luma-sensitive perceptual optimizations" and how can this be done?
Back in the PEP VC-1 encoder for HD DVD/Blu-ray, we made differential quantization configurable by luma range, so that lower quants would be applied to low-luma blocks. It's pretty straightforward. Burned up a lot of bits, though; some frames had 30%+ of bits being spent in what was basically black.

Dithering is really important here as well, since sources often have banding in the Y'=16-25 range. Coming from 10-bit sources and applying a good dithering algorithm made a big difference. And if the noise is in a narrow range, just remapping Y'=17-18 to Y'=16 can help as well, as long as you don't get the "oily pools" effect.

Like most codec stuff, the idea itself was pretty straightforward, and the challenge was mainly in the implementation details.

Getting back to the topic, MB-Tree would be quite useful in cleaning up low luma, as it would provide an excellent heuristic for what low-luma detail is actually signal versus what's random noise.

This would be a lot easier if LCD displays had better signal processing, and/or if we had a real 10-bit pipe end-to-end.