x264 development

[Sagekilla]

IIRC, zones let you fine tune a number of different parameters for that specific area, but I think it's only specific options that are exposed in some portion of the code. I remember asking Dark Shikari about this at one point and he said you could do stuff like using different settings beyond rate control for specific zones, except I never really figured out how to do this.

If anyone actually knows how you would specify something like different AQ settings or <arbitrary setting name here> I'd appreciate if anyone would tell me

[check]

There's support to change some encoding settings on the fly, but it's not exposed via the CLI beyond the bitrate/qp option.

[Sagekilla]

Hm. Any chance that would ever be supported in the near future?

[Snowknight26]

[14:41:03] <Snowknight26> so what was it that you cant change in zones?
[14:41:12] <Dark_Shikari> psy-rd, which will be fixed in r10xx
[14:41:18] <Dark_Shikari> aq also
[14:41:46] <Dark_Shikari> aq can't be changed for some technical reasons: I could allow it but the timing would be very off (i.e. changing it at frame 50 might result in the change being delayed to 70)
[14:41:57] <Dark_Shikari> or I could try messing with zones to get that to wokr
[14:42:01] <Dark_Shikari> its possible, but would require effort

When I asked him if b-frames could be changed in zones, he replied 'why not', but its not clear whether he meant the number of b-frames or the adaptive b-frame decision method.

[kemuri-_9]

iirc, possible parameters that can be designated within zones would be in the x264_encoder_reconfig section, which currently has (looking at the code)

• reference frames
• bframe bias
• scenecut threshold
• use deblocking
• deblocking alpha & beta
• intra and inter luma partitions
• direct mode
• me method
• me range
• noise reduction
• subpel refinement
• trellis quantization
• chroma me
• dct decimate
• fast pskip
• mixed refs
• psy rd
• psy trellis
• 8x8 transform (if enabled to begin with)
• bframe pyramid (if enabled to begin with)

so it would be to overhaul the zone parser to handle these, as it seems it can already handle being able to do it within the code base.
and this would be fairly nontrivial with trying to come up with a intuitive scheme that is able to be parsed within code... with all the possible options and combinations of how it could be, might be why it hasn't been done yet.

[Dark Shikari]

Originally Posted by kemuri-_9

intra and inter luma partitions

fixed

[kemuri-_9]

ah thanks for pointing that out.

since people are speculating away on why these options can't be used within the zone option as is, what is the reason, if i may so ask?

[Dark Shikari]

Originally Posted by kemuri-_9

ah thanks for pointing that out.

since people are speculating away on why these options can't be used within the zone option as is, what is the reason, if i may so ask?

AQ is done in lookahead, so if I allowed AQ to be changed in zones, I would have to do one of the following:

1. Simply allow zones to be non-frame-accurate and potentially start/stop at locations up to dozens of frames off (for AQ, at least).
or
2. Restructure zones to also check the lookahead frames to see if any one of them is the start of an AQ zone.

I really don't want to do either. Also, Fallout 3 is awesome.

[kemuri-_9]

ha ha, i guess i wasn't specific enough:
i was referring as to why the current parameters within the x264_encoder_reconfig block are not able to be used with the current zone parser...

similarly, from what you just said, it does sound like AQ should not be reconfigurable to maintain zone determinism, i think people could live without having it reconfigurable.

ha ha fallout 3 eh, that does seem to be the current rave...

[Dark Shikari]

Originally Posted by kemuri-_9

ha ha, i guess i wasn't specific enough:
i was referring as to why the current parameters within the x264_encoder_reconfig block are not able to be used with the current zone parser.

They aren't? That would be news to me. Last I tried, it works fine.

[kemuri-_9]

ah...
it turns out i was misreading some of the code.

it didn't help that what can be used within the zone parser isn't specifically documented anywhere from what i can remember
(longhelp doesn't even mention anything outside of force QP and bitrate multiplier).
so i guess this compounded the misread.

so the proper zones would be
start_frame,end_frame,b=X,options
start_frame,end_frame,q=X,options
start_frame,end_frame,options

'options' being supported ones that were listed above in a option=value format if they take values or the name of the parameter if they don't ... i.e.
direct=none
nr=100
me=umh
merange=32
no-deblock
scenecut=60
no-fast-pskip
etc...

like
0,100,psy-rd=0.0:0.0,trellis=1,no-fast-pskip,me=dia

trying it out a bit now...
i seem to be getting a crash if me=t/esa is used in a zone when --me is < esa
would need to make a debug build to nail it down further...
is this a known issue?

[Dark Shikari]

Originally Posted by kemuri-_9

trying it out a bit now...
i seem to be getting a crash if me=t/esa is used in a zone when --me is < esa
would need to make a debug build to nail it down further...
is this a known issue?

Yes, TESA/ESA cannot be enabled unless the frames have the "integral" data allocated, so I'll add in code to ensure that you cannot enable them if they were off to begin with.

[crypto]

Originally Posted by Shinigami-Sama

zones?

also yes sane b-adapt 2 <= 5
even 5 is a bit much

I know that >3 b-frames have a performance hit with b-adapt 2. My idea is about automatically detecting fades. VC-1 encoders can do that and can even signal the fade to the decoder which results in smooth fades like butter.

[Dark Shikari]

Originally Posted by crypto

I know that >3 b-frames have a performance hit with b-adapt 2. My idea is about automatically detecting fades. VC-1 encoders can do that and can even signal the fade to the decoder which results in smooth fades like butter.

That's explicit weighted prediction, which x264 doesn't support [yet]. Patches welcome.

[crypto]

Originally Posted by Dark Shikari

That's explicit weighted prediction, which x264 doesn't support [yet]. Patches welcome.

Ok, I see.

About the zones, is that what's called segmented encoding in other encoders?

After the 2 pass encode is ready, the result is displayed and you can mark several segments for reencoding.

[Dark Shikari]

Originally Posted by crypto

After the 2 pass encode is ready, the result is displayed and you can mark several segments for reencoding.

Yes, it can be used for that purpose. No, I do not endorse the concept that companies can compensate for awfully-designed encoders by simply telling the user to fix every mistake their encoder made.

[crypto]

Originally Posted by Dark Shikari

Yes, it can be used for that purpose. No, I do not endorse the concept that companies can compensate for awfully-designed encoders by simply telling the user to fix every mistake their encoder made.

LOL, thanks for the explanation.

And even if it might sounded so, I am in no way criticizing the results of x264. I tried many encoders and x264 is my choice because of its superior results.

[Adub]

Wow, okay, so i just thought I would run some tests recently, and see if I should be one to jump on the psy trellis band wagon.

Okay, so I encoded the same source twice (Heroes Season 1 Episode 11, DVD NTSC R1) once with out psy trellis, once with. It was with MeGUI, and Sharktooth's unrestricted 1 pass const. quality Extra Q modded for psy rd = 0.7 and psy rd = 0.7, along with aq = 0.6 (I stay safe in my usage), and crf = 19.0. I compared the output quality, and yes psy trellis is just that much sharper, albeit with increased grain.

But then I looked at the file sizes:
WithOUT psy trellis = 445mb
With psy trellis = 581mb

Difference = 136mb or 30.561797752808988764044943820225% (edited) larger.

Is this right?! I didn't think that enabling psy trellis would suck up so much bitrate. Hell if I wanted a perfect encode, I would have used a higher crf, or even just done a two pass encode at 581 mb target file size.

DS, is this the expected behavior? Or is this because I used CRF?

[Dark Shikari]

Originally Posted by Merlin7777

But then I looked at the file sizes:
WithOUT psy trellis = 445mb
With psy trellis = 581mb

Yes, psy-trellis lowers the effective lambda, raising bitrate at the same QP.

Originally Posted by Merlin7777

Difference = 136mb or 76.592082616179001721170395869191% larger.

Might I suggest you check your math?

[DarkZell666]

You can't keep more details/grain and expect the filesize to be the same in quality-based mode, it's just not compatible by design.

Here's how I interpret it : Psy-Whatever enhances grain, but seems to leave the rest of the picture untouched, so the filesize simply goes up by the same amount. It's the bitrate-based modes' job to balance the other frequencies out, unlike in the case of AQ that was designed to balance the details out by itself.

Of course, the bitrate only goes up by the same amount as grain retained, so if the source is already clean enough, the bitrate won't go up as much ... but since there's no grain to keep in that case, why use psy in the first place ?

I suppose we could agree on a rule of thumb about psy+CRF, like "CRF 18 w/o psy = CRF 21 w/ psy" bitrate-wise ? (random numbers just to illustrate).

(Edit: lol, it took me half an hour to finish my post 'coz I kept being disturbed by my boss )