The "--zones" function and its accuracy (and limits)

[Masaru]

So I recently discovered that using --zones could probably solve some of the problems I've experienced when encoding a couple of unique videos I work on. And even if it wouldn't, I believe that the nature of function itself has a potential, and if used properly can most likely optimize the encoding results to some extent in most cases.

And I've been really looking forward to run some tests on that until, frankly, I read in some now-abandoned forum thread that you can't use --zones freely (the way you may wish to) as they're somehow I-frames connected. Is that true? I mean, can I use for instance a different bitrate factor for twelve frames only on my one hour video?

Also, even though no-mbtree is not listed as a command I can use with --zones on the x264 wiki (mewiki.project357.com/wiki/X264_Settings (http://mewiki.project357.com/wiki/X264_Settings)) it doesn't hung-up the encoder, but instead it gives some error on the second pass (no message on the first though):

x264 [warning]: lookaheadless mb-tree requires intra refresh or infinite keyint

Any way to work that around? And what's that lookaheadless mb-tree really? I thought mb-tree was all about looking ahead.

Thanks in advance.

[nibus]

Sorry to dig up an old thread, but does x264 now support enabling or disabling mbtree through zones?

[MasterNobody]

Sorry to dig up an old thread, but does x264 now support enabling or disabling mbtree through zones?
No, it doesn't support this.

[nibus]

No, it doesn't support this.

Thanks. My main gripe with mbtree is it under-allocates bitrate on dark scenes. I'll have to rely on crf and psy instead.