Methods to greatly decrease file size without increasing encode time

[dooom9]

Hello. Given the following x264 encoding profile, is there a way to make output filesize significantly smaller without increasing encode time? Decreasing encoding time is preferable, as well as maintaining a similar quality level.

program --level 4.1 --crf 20.0 --keyint infinite --min-keyint 1 --scenecut 60 --qpmin 10 --qpmax 51 --chroma-qp-offset -12 --vbv-bufsize 78125 --vbv-maxrate 62500 --nr 100 --psy-rd 2.00:2.05 --output "output" "input"

[Blue_MiSfit]

Increase CRF ;)

*rimshot*

In all seriousness, aside from simply reducing bitrate and hoping for the best, you don't have a lot of options. I'd suggest getting rid of most of your custom settings, they are not necessary unless you're doing something highly specific.

You might try bumping up --nr to a higher value. It's pretty fast...

[xooyoozoo]

Unless you're encoding some incredibly, bewilderingly esoteric material, getting rid of --chroma-qp-offset and making --psy-rd a bit more sane would help perceptual quality quite a bit.

[benwaggoner]

I'd probably start with a --tune appropriate to your content.

Higher --nr values can also significantly help reduce file size for noisy content. I've used up to --nr 750 on a SD encode of True Grit* and got a net perceptual quality improvement due to saving bits from encoding all those random changes.

*This was Paramount's enhanced version for Windows Phone 7.

[dooom9]

The following is the new encode profile.

program --level 4.1 --crf 20.0 --keyint infinite --min-keyint 1 --scenecut 60 --qpmin 10 --qpmax 51 --chroma-qp-offset -6 --vbv-bufsize 78125 --vbv-maxrate 62500 --nr 100 --output "output" "input"

The bitrate is 2853 Kbps and the quality, while slightly worse visually, is perfectly fine. The bitrate on the other hand is ridiculously low. A bitrate of at least 4000kbps is required. The goal is a low file size with a high bitrate. What can be changed to accomplish this?

[ChiDragon]

The nature of the universe? Laws of physics? Logic? Math?

Bitrate * length = filesize.

[paradoxical]

The goal is a low file size with a high bitrate. What can be changed to accomplish this?

Nothing. You've basically stated you want a goal that has two completely contradictory attributes. You do realize that size is directly proportional to the bitrate, right? It is impossible to have higher bitrate while also having a lower file size.

[benwaggoner]

Nothing. You've basically stated you want a goal that has two completely contradictory attributes. You do realize that size is directly proportional to the bitrate, right? It is impossible to have higher bitrate while also having a lower file size.
Maybe he meant high peak bitrate but low average bitrate?

Which would make sense for the maxed out vbv-maxrate and vbv-bufsize. Targeting a 4 Mbps encode I'd lower them a whole lot, because you'd be getting placebo bits if it actually used anything anywhere near those. Better to have a reasonable peak and hope maybe some bits go back into ABR.

For this weird case, I'd probably start with --nr 500 and go from there. The bigger the frame size, the less visual impact it has.

[ChiDragon]

Does that mean I should be lowering those values from the Blu-ray max when I do 3Mbps encodes of SD material to burn?

[benwaggoner]

Does that mean I should be lowering those values from the Blu-ray max when I do 3Mbps encodes of SD material to burn?
Yes, I normally would. I doubt x264 is using anywhere near those peaks with a 3 Mbps ABR, though. With that rough target, I'd probably use Level 4.0 with perhaps --vbv-maxrate 15000 and --vbv-bufsize 25000.

Why are you messing around with scenecut, psy-rd, and chroma qp offset? I wouldn't tweak those to get more efficient encoding, but only to tune encoding to some weird kind of source. They might help push bitrate down a bit at a given CRF, but you'd probably get better looking output at the same bitrate by turning them off and increasing your CRF a little.

I also question the use of infinite max GOP size if you ever want to do random access. You get a title with a seven minute long single shot, you could get a 10,000+ frame GOP, and trying to jump 6.5 min into that would require decoding thousands of frames before the one you want can be displayed.

Personally, if this is film and video style content, I'd do something simple like:

--level 4.0 --crf 20 --tune film --nr 350 --preset slower --vbv-maxrate 15000 --vbv-bufsize 25000 --keyint 480

Using a slower, higher quality --preset is going to have a bigger quality impact than the rest of your tuning. With a reasonable number of cores, you can easily wind up being bound by decode anyway; don't assume that slower encoding settings will actually slow down your encoding by that much. They just might make your video smaller and your room warmer :).

[ChiDragon]

I'm not OP, just thought I'd interject to find out that one answer. :P

[dooom9]

The encode settings for the following two files are the same (except for --threads and --lookahead_threads because the high-end computer supports more threads), so why is the bitrate for the video of File 1 3471 Kbps, while the bitrate for the video of File 2 is only 2820 Kbps?


MediaInfo for File 1 (encoded on high-end computer)
http://pastebin.com/PgDEqsuP


MediaInfo for File 2 (encoded on mainstream computer)
http://pastebin.com/KnE1gcqC



Note*
File 1 is encoded with x264 build r2245. File 2 is encoded with x264 build r2273. Also, the two files come from different source videos.

Your thoughts on the discrepancy?

[detmek]

The encode settings for the following two files are the same (except for --threads and --lookahead_threads because the high-end computer supports more threads), so why is the bitrate for the video of File 1 3471 Kbps, while the bitrate for the video of File 2 is only 2820 Kbps?


MediaInfo for File 1 (encoded on high-end computer)
http://pastebin.com/PgDEqsuP


MediaInfo for File 2 (encoded on mainstream computer)
http://pastebin.com/KnE1gcqC



Note*
File 1 is encoded with x264 build r2245. File 2 is encoded with x264 build r2273. Also, the two files come from different source videos.

Your thoughts on the discrepancy?
You answered your own question.

[JohnAStebbins]

Also, the two files come from different source videos.

And from your mediainfo report:

crf=18.0

A little less cryptically... this is your answer.

Different sources, when encoded using constant quality settings, will result in different bitrates.

[dooom9]

Thank you for your help. Is there any way to guarantee a certain bitrate, 4000 kbps for example, when using constant quality? File 1 (http://pastebin.com/PgDEqsuP) seems to have hit that bitrate almost exactly. Is there a method to reproducing this?

[Groucho2004]

Is there any way to guarantee a certain bitrate, 4000 kbps for example, when using constant quality?
You wouldn't ask this question had you understood the answers in this thread.
Once more:
Constant bitrate and constant quality are mutually exclusive.
For example:
You encode animation at a certain CRF value and it results in 2Mbps. Using the same settings on a movie that has a lot of grain can easily result in 10Mbps or more.

[dooom9]

You wouldn't ask this question had you understood the answers in this thread.
Once more:
Constant bitrate and constant quality are mutually exclusive.
For example:
You encode animation at a certain CRF value and it results in 2Mbps. Using the same settings on a movie that has a lot of grain an easily result in 10Mbps or more.

So how does the encoder of File 1 achieve 4000 Kbps overall bitrate almost exactly while using crf video and constant quality audio?

[Groucho2004]

So how does the encoder of File 1 achieve 4000 Kbps overall bitrate almost exactly while using crf video and constant quality audio?
Because that's the resulting bitrate based on the settings and source you used. What does the audio have to do with this?

[sneaker_ger]

So how does the encoder of File 1 achieve 4000 Kbps overall bitrate almost exactly while using crf video and constant quality audio?

Coincidence.

You can achieve constant quality within a single source at a predefined average bitrate using a 2pass encode:
x264 input -o output --bitrate 4000 --pass 1
x264 input -o output --bitrate 4000 --pass 2

If you do this with several sources they all will have an average bitrate of 4000 kbps, but the quality of the encodes will vary since different sources require different bitrates for the same quality (e.g. a grainy action movie vs. a drama).

[benwaggoner]

Thank you for your help. Is there any way to guarantee a certain bitrate, 4000 kbps for example, when using constant quality? File 1 (http://pastebin.com/PgDEqsuP) seems to have hit that bitrate almost exactly. Is there a method to reproducing this?
Do you mean you want a maximum of 4000 Kbps, but a minimum of whatever it takes to hit your CRF level?