Ultra low bitrate encoding suggestions?

[Blue_MiSfit]

Hello folks!

Any suggestions out there for tuning x265 for very low bitrates? The use case is the bottom layer of an ABR stack. I'm trying to do 360p at 160 Kbps.

Here are the hard requirements (because it's ABR)
*48 frame keyint and min-keyint
*no open GOP
*maxrate = 1.1x bitrate
*bufsize = 2x bitrate

I'm already using preset veryslow.

Sources are clean UHD ProRes.

I did find that forcing ctu to 16 improved quality a bit in really challenging scenes.

[Cary Knoop]

I am wondering if currently at such low bitrates x264 actually gives you a better result than x265 since x265 is a lot less optimized?
Can those stacks contain different codecs?

[Blue_MiSfit]

They can not. At least, not uniformly across all the devices I want compatibility with.

[TEB]

Howcome maxrate 1.1x ? Im working on the same project at work for a optimized ABR stack and we are going for 2x (IOS10 minimum base + android 5.1)

[Blue_MiSfit]

It's the bottom layer of the stack and is intended to be only an occasional filler when a bad network connection becomes REALLY bad. So, we do want it to be fairly CBR-ish.

[Tommy Carrot]

Turn off psy-rd and psy-rdoq. In my experience they can cause pretty bad artifacts at very low bitrate.

[Blue_MiSfit]

Good idea, I hadn't really considered that. I did try reducing their strengths, but I'll try that as well.

[TEB]

It's the bottom layer of the stack and is intended to be only an occasional filler when a bad network connection becomes REALLY bad. So, we do want it to be fairly CBR-ish.

Ah fair enough. Mind showing the ladder? Could be interessting to compare. Why no mixed ladder with HEVC? Packager limitation?

[Blue_MiSfit]

I can't share that, I don't think, but it's not far off from Apple's HLS authoring guidelines.

The mixed ladder approach would work just fine with HLS since Apple's HLS client is quite good, but definitely not with all clients we serve MPEG-DASH to. We prefer to control it and present an AVC SDR ladder, an HEVC SDR ladder, and an HEVC HDR10 ladder depending on device capabilities.

Curiously, Apple REQUIRES you to provide SDR if you provide HDR of any kind in a playlist, so that was a fun little curve ball.

[alex1399]

I've tried to (erroneously) downscale FHD video to 640x352, add eight lines of black bar on the down side, and playback in full screen.
Looks better, I don't know why.

[Emulgator]

A height of 352 px is divisible by 16, a height of 360 px is not.
Encoding the lower 8px band would mean blocksize of 8 and eat more bits per pixel.
So active picture area encoding into 40x22 full 16x16 blocks is more efficient.
Since the 8px black bar comes for almost free, these bits can now be spent where they improve remaining content.
Good find.

[benwaggoner]

I've not found any low bitrates where x265 can't beat x264.

Using --preset placebo might not be materially slower, if you are encoding a full ladder including higher resolutions at the same time.
HEVC is very efficient for non mod16 resolutions. I doubt that'll have a material impact (the extra 8 lines of 360 versus 352 are going to take way more bits than the non-mod16 overhead). If there is a sweet spot, it'd be optimal at Mod64!
I don't think turning off psychovisual optimizations entirely is a good idea, but strength might benefit from lower values
Turning off WPP might help a tiny bit, and low rez low bitrate should decode just fine without WPP, even with software decoders
For fixed GOP, you can throw in --radl 1 (there's a bug with higher values)
Two pass encoding can help
--bframes 16 can help a surprising degree. With everything so quantized source variance winds up converging a lot, and thus there are a lot more skip blocks happening, Thus more b-frames helps more than at higher bitrates.

[Blue_MiSfit]

Thanks, everyone!

[abaxas]

d:\ffmpeg2\ffmpeg -i input.mkv -c:v libx265 -crf 33 -preset slow
-x265-params qcomp=0.85:keyint=600:bframes=12:rc-lookahead=200:colorprim=bt709:transfer=bt709:colormatrix=bt709:aq-mode=1:psy-rd=0:psy-rdoq=0:rd=6:deblock=1,1:aq-strength=0:ref=6:qpmin=27:max-merge=5:subme=7:weightb=1
-y -c:a libopus -b:a 32k -vbr on -ac 1 -ar 24000 x265_33_aac_24000.mkv

I use crf 33 for 720p, 32 for 540p/480p and 31 for 360p, the rest is the same. All look fine on my 10 year old 28inch sony 720p screen so I need no better.

If you want even lower bitrates and there is little or few very dark scenes or lots of areas with black>high brightness areas you can decrease the qcomp.

Also, it's fine to use slower/veryslow presets for a a very small bump in perceived quality but that depends how many files you have to encode.

With the above settings the highest bitrate I've seen was ~2000kbps for video when encoding 720p/60 game footage.

NOTE: The psy-rd=0:psy-rdoq=0 section is non optional and any 'psy' appears to make matters much worse.

[benwaggoner]

Also, I generally recommend that --maxrate=the max bitrate based on Profile @ Level unless you need the GOPs to be really consistent in size. At the same ABR, a bigger VBV can improve quality significantly.

Using --crf can help super-easy parts of video save some more bits, although the lower the --maxrate, the less value of CRF. Still, for scrolling credits or titles, it can help.