Using zones with x264, possible?

[DNL]

Hello,

I'm wondering if it's possible to use zones with the x264 codec? When using XviD is always lower the bitrate of the credits to save some for the rest of the movie. Is it possible to do the same with x264?

Best regards,
DNL

[Dark Shikari]

--zones parameter.

Though credits already use nearly no bits, so I'm not sure how much there is to be gained. AQ also helps move away bits from credits due to their natural very high contrast.

[DNL]

In order to use these filters I'll have to add '-aq-mode <frame.number>' and... what's the command for zone parameters? :)

[roozhou]

A similar question. When encoding some animes which end with rolling credits, x264 seems to waste too much bit(about 300% average bitrate there). I am using 2-pass --qp mode with AQ turned off. What settings should i use besides raising qp to reduce bitrate in credit parts?

[Dark Shikari]

In order to use these filters I'll have to add '-aq-mode <frame.number>' and... what's the command for zone parameters? :)AQ is on by default. Zones work like --zones QP,Framestart,Frameend I think.
A similar question. When encoding some animes which end with rolling credits, x264 seems to waste too much bit(about 300% average bitrate there). I am using 2-pass --qp mode with AQ turned off. What settings should i use besides raising qp to reduce bitrate in credit parts?That's because anime uses so little bitrate (generally) that anything remotely complex tends to use a lot more than average bitrate. This can be handled with zones, or you can be like the fancy fansubbers and use ordered chapters.

[Selur]

btw. would be cool if one could enforce an IDR-frame on zone start (thinking about chapterpoints)

[desta]

Though credits already use nearly no bits, so I'm not sure how much there is to be gained.
I've often found it to be quite the opposite, with the credits getting unreasonably low quantizers in comparison to the rest of the movie.

[toytown]

I always use zones on my credits. Not long ago i encoded superman returns and MI3 from HD, but forgot to add zones to the MI3 encode. Anyways on superman returns i see a bitrate of 0.1Mbit -0.4Mbit a second during credits, on MI3 i see an average of 4Mbit-8Mbit. Maybe not a fair compassionment as they are 2 different movies and will have a different video, but the credits are typical white on black on both.

EDIT - I just tried a few of my SD encodes and found that during credits the bitrate was avg 1.5Mbit on most credits, with the occasional jump to 4-5Mbit for sections of the credits (in both cases white on black text). So i would definetely advise the use of zones for credits. For my SD encodes they have mostly been done with CRF18 and AQ, for my HD encodes i used the DXVA-HD-HQ profile but with a specific bitrate

[Dark Shikari]

I've often found it to be quite the opposite, with the credits getting unreasonably low quantizers in comparison to the rest of the movie.Low quantizers != lots of bits.

If you look at the stream itself, its likely that the black background gets a very low quantizer (but takes nearly no bits) while the text gets a very high quantizer.

[Selur]

low quantizer = good detail preservation => if there are much details this equals higher bitrate, but if there is a low amount of details even low quantizer create a low bitrate.

[desta]

Though credits already use nearly no bits, so I'm not sure how much there is to be gained.
I've often found it to be quite the opposite, with the credits getting unreasonably low quantizers in comparison to the rest of the movie.
Low quantizers != lots of bits.
Hence me calling them unreasonable for credits.


If you look at the stream itself, its likely that the black background gets a very low quantizer (but takes nearly no bits) while the text gets a very high quantizer.
Hence the use of zones. Setting a higher fixed q gives virtually the same visual result, but saves bits - nice for 2 pass where they can be redistributed. Every bit counts, as they say. It's not a complaint about x264.

[lexor]

Low quantizers != lots of bits.Hence me calling them unreasonable for credits.

Something that doesn't give high bitrate is unreasonable for credits? I'm confused.

[desta]

If, or rather when, I encode a movie without setting zones for the credits, they end up unreasonably large for what they are, using a bitrate which they don't really justify (and could be put to better use elsewhere). When I encode a movie with a fixed q on the credits, they drop quite significantly in size (in comparison to those without), whilst being visually pretty much the same, but now the bits they didn't use are distributed somewhere that can gain from it.

I tend to do a 2 pass encode of a movie, first with no zones, then I go through the resulting stream seeing what got what and where. I then do the encode again with zones to make certain areas more or less important.

[toytown]

When I encode a movie with a fixed q on the credits, they drop quite significantly in size (in comparison to those without), whilst being visually pretty much the same

Yep i get the same, the difference in white on black credits is very hard to tell even though the bitrate on them has been reduced from 6Mbit to 0.3Mbit in some cases, perhaps its because i dont look so hard but in motion there is appears to be little difference.

Of course credits which still have video behind them really do suffer from the lack of bandwidth and depending on the content, i decide to use a lot higher weight on the zone for these.

[Avenger007]

Would a specialized algorithm for handling credits help as opposed to *blindly* increasing quantizers? Of course there would need to be some special calling syntax for using the algorithm only in the zone.
By saying 'blindly' I'm guessing the generic algorithm can't really tell the difference between credits and high contrasts animation or something like that.

[akupenguin]

Yes it's possible to efficiently code scrolling credits (no background) using a special algorithm, but it really deserves to be an avisynth filter.
In particular, the filter would do:
* whole frame motion estimation (not block-based), i.e. pan detection
* merge the whole credit into a single tall image plus an mv per frame
* denoise by averaging all the input frames that contain a given pixel
* threshold the background to exactly black
* round the per-frame mv to qpel
* extract individual frames back out, using h264's subpel interpolation algo
Then any naive encoding should be fine, though you save a few bits on the mvs if you code the one mv in the first mb rather than waiting for a block that actually contains motion. Lots of B-frames are good for the reordering, though you don't need the bidir part.

... or you could just go for OCR+SSA.

[Dark Shikari]

Yes it's possible to efficiently code scrolling credits (no background) using a special algorithm, but it really deserves to be an avisynth filter.
In particular, the filter would do:
* whole frame motion estimation (not block-based), i.e. pan detection
* merge the whole credit into a single tall image plus an mv per frame
* denoise by averaging all the input frames that contain a given pixel
* threshold the background to exactly black
* round the per-frame mv to qpel
* extract individual frames back out, using h264's subpel interpolation algo
Then any naive encoding should be fine, though you save a few bits on the mvs if you code the one mv in the first mb rather than waiting for a block that actually contains motion. Lots of B-frames are good for the reordering, though you don't need the bidir part.Of course, given how fancy the credits in modern movies are, such a filter would not be very useful. See "300," etc.

[stax76]

Using qp 40 instead of crf 22 saves 10-30 MB for SD encodes, MeGUI has first class credits support, StaxRip has a customizable menu using a command engine and macros enabling it to add a credits feature, how to do it described here (http://forum.doom9.org/showthread.php?p=1130248#post1130248). A credits feature is not a bad idea so I'll much likely add first class support too.