About fades in x264

[sirt]

Hello,

I am not sure if this message should be posted there but I leave moderators the decision to move it if necessary.

This message is primarly adressed to Dark Shikari but any help would be welcomed :

Someone asked how to "improve fades" in another forum and you replied this :

"
1. Change if( h->param.analyse.i_weighted_pred == X264_WEIGHTP_FAKE && weights[0].weightfn ) to if(weights[0].weightfn ) in encoder/slicetype.c

2. float log2_ratio = x264_log2(intra_cost + propagate_cost) - x264_log2(intra_cost) + weightdelta;

Multiply weightdelta here by a number larger than 1 if change 1) isn't enough.

This will allocate more bits to fades."

So I was wondering if you had another sugestions like this regarding fades and videos featuring a lot of transitions like that one for example :

http://www.youtube.com/watch?v=qFJ3VKnwmJw&ob=av2e

Check the 4 seconds at the beginning, such video is full of transitions like this (alternating several scenes with black fades)

[sirt]

Dark Shikari I asked you for having a look at this thread, so do you have a suggestion ?

[sneaker_ger]

You might be interested in JEEB's patched builds:
http://x264.fushizen.eu/

--fade-compensate <float> Allocate more bits to fades [0.0]
Approximate sane range: 0.0 - 1.0 (requires mb-tree)

[sirt]

Thanks for your reply. What build would you recommand in this case ?

[sneaker_ger]

They come in the same variants as the vanilla builds from x264.nl. :confused:

[sirt]

Unfortuantel I didn't get what you say. What do you mean by "vanilla builds" ? Actually, I am right there : https://github.com/jeeb/x264_L-SMASH/tags ; do you mean I should just get one or another packs from them and compile them ?

[sneaker_ger]

There are pre-compiled builds directly on the page that I linked to. 64bit/32bit in 8bit/10bit variants.

[sirt]

In fact I am there https://github.com/jeeb/x264_L-SMASH/tags and if I download this for example https://github.com/jeeb/x264_L-SMASH/zipball/r2200 I get a source code that has perhaps been modified. Is that what you advise me to download and recompile myself ? There http://x264.fushizen.eu/ you can get the .exe compiled by JEEB.

[Selur]

just wondering: Why isn't this patch part of the normal x264 tree? are there known 'problems' with it that prevent a merge to the git master branch?

[sneaker_ger]

In fact I am there https://github.com/jeeb/x264_L-SMASH/tags and if I download this for example https://github.com/jeeb/x264_L-SMASH/zipball/r2200 I get a source code that has perhaps been modified. Is that what you advise me to download and recompile myself ? There http://x264.fushizen.eu/ you can get the .exe compiled by JEEB.

You asked for a build, so I figured you wanted one of those builds. The one's on that site are already patched, so you don't need to compile them yourself.

[sirt]

I got you. In fact I was asking for patches that I could compile myself or/and a few advise for the youtube video linked below. But if I get one of those source codes uplaoded by JEEB and compile them myself it would be same than downloading the corresponding .exe I guess.

[pepelugil]

just wondering: Why isn't this patch part of the normal x264 tree? are there known 'problems' with it that prevent a merge to the git master branch?

I have exactly the same question... If this patch improves quality, why is it not commited in "normal" x264?

[Dark Shikari]

Because it's a hack, it doesn't work very well (in my experience it doesn't really solve the problem), we don't know what value to use, and it doesn't work very consistently.

e.g. using a high enough value to fix one fade often led to a staggering number of bits being wasted on another that didn't need it.

[Selur]

Ah, okay, thanks for clearing up that there are known 'problems' with it. :)