CRF vs Bitrate

[tyee]

All the following may eventually be BS but time will tell.

I'm sure we all know that if we want to know the final size, use 2pass bitrate mode, and to get constant quality use CRF mode, but like, me lots of us would like to know the final size or average bitrate of a crf encode before actually doing it.
Many years ago I made a little gui to mathematically try to find the crf to use for a final size using empirical data. I did abandon it after I found it wasn't as accurate as I had hoped. It's still on the site here somewhere but that's history.

Yesterday after a little discussion with someone, I remembered something that popped into my mind recently which I never pursued, about how to find a better method to do this. I tried it yesterday and today for 2 backups and it actually worked. Here's the theory -

2pass mode works because the 1st pass analyses the video and knows where the complex/not so complex scenes are so the 2nd pass can do it's job and give us our desired final size. CRF mode is only 1pass so it can't know what's coming up way ahead in the video so we get variable bitrate/constant quality for the whole video. But what I want is to choose a CRF to get an average bitrate for the whole video of my choosing. So if CRF can't see ahead, I sure can, and I can give it some help. How can I see.....Bitrate Viewer of course. What I have done is to load the source video into BV, let it scan and find the average bitrate of the full video. If you see the typical peaks/valleys of bitrate variations this method seems to work. If you see a flat line, like for constant bitrate, forget this method.

OK, we now see the average bitrate of the whole video, which is too high. Now find around a 10 minute section where the average bitrate of the whole video is equal to (graphically overlaps) the average video bitrate in this 10 minute section. You can turn on the display of average bitrate for whole video and it will be a green line. You can see the accumulated average bitrate anywhere by looking at the gray line. Where these overlap, encode this 10 minute section using avisynth "Trim" command. Try various CRF values until you get the average bitrate you want for the whole video. Basically what we are doing is finding a section of varying bitrate/complexity which has an average equal to the total movie average and pulling it down to our desired lower bitrate. Once found, encode the whole movie with this CRF value and it should turn out to have the same average value as this 10 minute section. So far it's worked for me on two movies.

It's an interesting concept, I don't know if it's been mentioned before on the forum but I would like others to try.

To show the average bitrate line in Bitrate Viewer hold down the Ctrl, Shift and Alt keys and left click in the window. This also shows max and min bitrate lines also.

To find a 10 minute section, use the zoom function, hold Ctrl and Shift, then left click multiple times in the window.

To scroll the window looking for the 10 minute section hold Ctrl and drag the scroller in the bottom of the window.

I'm including a screenshot showing the 10 minute area I encoded which shows how the gray line (avg bitrate) nearly overlaps the total movie avg bitrate (green line).

Does my theory make sense?? Remember this is not nearly as accurate as 2pass but it's close enough for me since I store on hard drives.

[Dark Shikari]

A common method for this is to just randomly select small chunks of the video (e.g. a few dozen 10-second segments), encode them with a given CRF, and generalize from there. You could even calculate a statistical uncertainty based on the number of segments you chose.

[tyee]

True, I have done that with "SelectRangeEvery" in the past but eventually abandoned it for me. The complexity it is choosing throughout the whole video is totally random. This method tries to select only an area that is very close to the average bitrate of the whole video so the complexity is known. Does that make sense?

[Dark Shikari]

Your method won't work if the source was CBR (e.g. broadcast TV), heavily VBV-constrained (e.g. DVD), and so on. It also assumes the input was already compressed by an encoder very similar to x264, which is very often not true.

By probability, randomness is a pretty good way of getting a sample (most scientific studies to some degree or another rely on this).

[osgZach]

My take on this issue, and maybe it is not ideal or comes with its own problems, has been to enforce a maximum bitrate limit using the VBV settings.

My rationale has been, if you're using 2-pass to get a specific file size, but you're concerned about "wasted bits" on videos which can compress better then just use a bitrate calculator to find a solid bitrate that generates a maximum filesize for a video (duration) you are comfortable with. Then cap the maximum bitrate with VBV. So if you get a video that compresses great, then CRF will do its magic and the file size will be pretty small. For less compressible sources it just rides up closer to or at the limit.

It's not completely win/win, because I am assuming there are concerns about starving a video of bitrate it needs to hit that CRF quality rating in the first place. But its faster than 2-pass which works for me.

So far results have been fairly good on the tests I've been doing.

--profile high10 --level 4.0 --vbv-bufsize 12500 --vbv-maxrate 12500 --open-gop --b-adapt 2 --trellis 2 --me umh --subme 9

took Jurassic park from 22.14GB (muxed) to 10.15GB, and it looks very good during playback.

Took about 3h:8m across 4 networked machines. Actually going to raise the bitrate cap to 14.5Mbps and see how much of a difference I notice. So far I'm pretty happy with it though and if it looks good on my Monitor I know it will look fine on the TV.

[sneaker_ger]

Originally Posted by osgZach

and maybe it is not ideal

The understatement of the year. Limiting the bitrate locally (via vbv) can result in horrible artifacts and quality fluctuation.

[osgZach]

Still doesn't change my perceptual results. Maybe if I were trying to enforce some insanely low bitrate, but I'm not seeing that bear out so far.

edit: and yes I do see/am not denying artifacting, but I don't have super eyes to be picking out a couple "bad" frames in an action scene.

edit2:

Actually thinking on this some more... Have the devs every considered a feature, something like "on-the-fly" zones for CRF? The idea being people using zones probably tend to adjust values for credits, low action, and high action.

What if x264 took all the motion calculations it was doing, and applied used that to apply different CRF values to the video where scenes are meeting a certain threshold, as specified by user flags?

I know, I know, that sounds like what it does already - and zones are used for more than simply changing bitrate, but for this usage case it might be neat. Instead of having write out a bunch of zones what if it were much simpler:

--CRF 19:22:20:18

(Purely arbitrary complexity examples for examples sake)
The very first X would be a global CRF value that applies to anything it can't decide on.

Then Low Motion Complexity (almost or completely static dialogue scenes, or very slow pans), Medium (typical background behavior, traffic, groups of people, passersby), and High (fast paced action scenes with tons of motion).

Well. I love proposing stupid ideas anyway so there it is.

[benwaggoner]

I am somewhat baffled as to the point of this.

Just this week, using real-world sources for identical format and an identical x264 command line, there was a 3x variance in the final ABR.

I've also seen plenty of sources where the average bitrate AT halfway through the file went up or down 20% by the end of the file.

It seems that quite a few sections would have to be sampled to get a 95% confident +/- 5% estimate.

[tyee]

Just for interest's sake how does x264 in 2pass mode determine how to allocate bits during the 2nd pass if the source is encoded as CBR like DS said above. Obviously x264 can't use bitrate to determine complexity because it's CBR?

[Dark Shikari]

Originally Posted by tyee

Just for interest's sake how does x264 in 2pass mode determine how to allocate bits during the 2nd pass if the source is encoded as CBR like DS said above. Obviously x264 can't use bitrate to determine complexity because it's CBR?

x264 has no idea how the source is encoded; the video it gets is just raw frames. The second pass uses the first pass's statistics to figure out how to allocate bits.

[Sharc]

crf prediction using the method of snippets (of at least one GOP size each) is implemented as an option in jdobbs BD Rebuilder for example. By default a sample size of 1% is used. The predicted final crf which is reached after 5...8 estimation cycles hits the target size of the encode typically between 90% and 99%, with oversize (bad luck) happening very rarely. Increasing the sample size to 2% doesn't seem to improve the accuracy significanty, in my experience.

[benwaggoner]

Originally Posted by Sharc

crf prediction using the method of snippets (of at least one GOP size each) is implemented as an option in jdobbs BD Rebuilder for example. By default a sample size of 1% is used. The predicted final crf which is reached after 5...8 estimation cycles hits the target size of the encode typically between 90% and 99%, with oversize (bad luck) happening very rarely. Increasing the sample size to 2% doesn't seem to improve the accuracy significanty, in my experience.

By "5..8 estimation cycles" do you mean it's reencoding those 1% of content iteratively that many times to converge on a value that's got about a +/- 5% accuracy? I presume there's a -5% offset for headroom which is why it's not 95-105%. That seems pretty useful.

I imagine the goal here might be to cap maximum quality and maximum file size simultaneously. This could also be achieved by using CFR and specifying --vbv-maxrate and --vbv-buffer. But the maximum file size could well less than the desired --vbv-maxrate, for example in Blu-ray authoring.

It would be cool if x264 could allow --bitrate, --vbv-maxrate, and --crf to all be set at once, only allocating bits as would be compatible with all three constraints. So a file with CRF 16, bitrate 25000, and maxrate 40000 would be CRF 16 unless a higher CRF is required to keep ABR >=25000, and would never exceed a peak bitrate of 40000.

I can think of cases where I'd use all three parameters like that if I could!

[Asmodian]

That would cap quality lower than that allowed with maxrate 40000.

The point is to lower the target quality to keep below an average bitrate but not by simply clamping the bitrate of hard to compress scenes (getting very bad quality for them) while also avoiding the "wasting" of bits by going very high quality on easily compressed content which can happen when targeting an average bitrate.

A multi pass encode can accomplish this but would obviously take longer.

You can do a standard crf 16 encode with maxrate 40000 and if it is oversized do a two pass encode with bitrate 25000 and maxrate 40000. This allows you to get the smaller file out of crf 16 and average bitrate 25000 while also keeping quality constant throughout the file.

Can --crf & --pass 1 be used at the same time? This would keep it a max two pass encode process (though both slow passes). I believe a two pass encode is needed to get optimal quality when doing an average bitrate constrained encode anyway.

[benwaggoner]

Originally Posted by Asmodian

Can --crf & --pass 1 be used at the same time? This would keep it a max two pass encode process (though both slow passes). I believe a two pass encode is needed to get optimal quality when doing an average bitrate constrained encode anyway.

Nope, you can't get a .stats file out with a --crf encode, darn it.

I can understand why the devs thought it might not be needed, but being able to get the .stats for analysis purposes alone would have saved me dozens of hours in Excel in the past year !

x264 devs, if you turn this on I will contribute pretty and illuminating charts and tables to the community. Promise!

[Dark Shikari]

Originally Posted by benwaggoner

x264 devs, if you turn this on I will contribute pretty and illuminating charts and tables to the community. Promise!

It's already on, actually! Can I have my cookies?

[benwaggoner]

Originally Posted by Dark Shikari

It's already on, actually! Can I have my cookies?

I just had to do a -p 1? I feel like an idiot.

I suppose there's some flag that'll make the .stats file into XML format too ...

[Sharc]

Originally Posted by benwaggoner

By "5..8 estimation cycles" do you mean it's reencoding those 1% of content iteratively that many times to converge on a value that's got about a +/- 5% accuracy? I presume there's a -5% offset for headroom which is why it's not 95-105%. That seems pretty useful.

Yes, exactly.

I imagine the goal here might be to cap maximum quality and maximum file size simultaneously.

The goal is actually to save time compared to the usual 2-pass mode for obtaining a desired file size. The 5...8 cycles with 1% of the video are much faster than a full 1st pass - at the expense of accuracy of course.

This could also be achieved by using CFR and specifying --vbv-maxrate and --vbv-buffer. But the maximum file size could well less than the desired --vbv-maxrate, for example in Blu-ray authoring.

--vbv-maxrate and --vbv-buffer are specified anyway in this case to prevent bitrate peaks which would exceed the constraints of the target medium.

[ajp_anton]

Originally Posted by benwaggoner

I just had to do a -p 1? I feel like an idiot.

You might need --slow-firstpass too so -p 1 doesn't set those fast first pass settings.