CRF using to little bits..

[TEB]

hi. Im trying to do some test encodes for our streaming solution and i have some problems getting x264 to use enough bits in CRF mode..

Any comments?

ffmpeg -i source.mp4 -pix_fmt yuv420p -codec:v libx264 -x264opts rc-lookahead=50:keyint=100:min-keyint=50:crf=24 -profile high -level 4.1 -preset slow -maxrate 7M -bufsize 14M -force_key_frames "expr:eq(mod(n,50),0)" -c:a copy -y AiB_HQ_3.mp4

Goal, ca. 7mbps avg bitrate
2 sec gop
forced idr at each gop start, and i-frames on each scene change
ive tried crf20-26.. im getting 3-4mbps on avg...

Any comments?
Or should i use 2 pass ABR instead?

[StainlessS]

According to MeGUI, for CRF,

Default = 23.
Recommended = 18->26.
Very Good = 19-> 21.5.
Absolutely perfect = 16.
Generally higher resolution coding can get away with higher crf (lower bitrate) values.

Above a certain rate (clip dependent), any additional bitrate will likely be just extra stuffing/padding to make up the bitrate, ie ornamental.

[zub35]

If you use crf, it is to increase the speed you can use direct=spatial
if crf≤18 - no-mbtree, deblock -3:-3
if crf≤16 - no-mbtree, no-deblock, no-psy (otherwise, these options degrade quality)

[nevcairiel]

CRF bitrates can vary quite a bit depending on the content you encode (and of course the resolution). At some point you'll just "need" to lower the CRF value further and further, if x264 just doesn't have any more bits to spend at a given crf level.

[TEB]

CRF bitrates can vary quite a bit depending on the content you encode (and of course the resolution). At some point you'll just "need" to lower the CRF value further and further, if x264 just doesn't have any more bits to spend at a given crf level.

That whats worries me, as all my sources are 1080p25, but the complexity varies.. and i need to make 1 profile for em all..
What about ABR 2 pass at a fixed avg bitrate instead?

The target platform is Mpeg Dash ISO (ABR)

[MasterNobody]

That whats worries me, as all my sources are 1080p25, but the complexity varies.. and i need to make 1 profile for em all..
What about ABR 2 pass at a fixed avg bitrate instead?

The target platform is Mpeg Dash ISO (ABR)
If you need fixed target bitrate than of course you should use 2pass VBR and not CRF.

[TEB]

If you need fixed target bitrate than of course you should use 2pass VBR and not CRF.

Not fully correct.. if u look at my initial ffmpeg string, im restricting it through VBV max and buf options...

[nevcairiel]

That whats worries me, as all my sources are 1080p25, but the complexity varies.. and i need to make 1 profile for em all..

But why are you worried if the quality is good? Some simple sources inherently compress better, like animation, is it a bad thing if it doesn't use the full bitrate available?

[MasterNobody]

There is difference between vbv-maxrate (upper constraint) and average target bitrate, isn't it? If you need average target bitrate than you should use 2pass VBR. btw VBV should also work better in 2pass.

P.S. If you really don't need average target bitrate but only constraints than what nevcairiel said above.

[Blue_MiSfit]

You sure you want CRF for MPEG DASH? Generally with DASH / HLS / Smooth / HDS / other adaptive HTTP streaming formats you want multiple bitrates that are either CBR or capped VBR so the player can dynamically switch between them predictably. CRF will have highly variable bitrate, so it's tough to hit bitrate targets.

Best practice for a 1080p encode would be to make 5-10 different encodes, each at a different bitrate (and with some different resolutions, too), and include them all in your DASH manifest. This way you can handle fluctuations in available bandwidth.

Generally, for target bitrate, set maxrate to ~1.1-1.5x bitrate, and bufsize to ~2x bitrate. 2-4 second GOPs are ideal. If you do end up going with multiple layers it's usually a lot simpler to use fixed GOP as well.

[TEB]

one has to seperate LIVE and VOD (offline)
For Live capped VBR or CBR with a fixed gop size adhering to the Dash implementation is the preferred way..
For VOD and from a packager point of view, predictability in gopsize is the key consern, hence we lock it at 2 sec. (50frames (25x2) (forcing each gop start with a IDR frame as well as scenecut detected need for an iframe or 2 within the gop)
Ive tinkered with CBR vs. 2pass Avg Bitrate vs. different CRF values with and without VBV buffer size lock and it seems that 2pass AVG bitrate gives the best SSIM/PSNR results compared to the pro-res source.

My current ffmpeg setup:

ffmpeg -i source.mp4 -pix_fmt yuv420p -codec:v libx264 -x264opts rc-lookahead=50:keyint=100:min-keyint=50 -profile high -level 4.1 -preset slow -b:v 1M -force_key_frames "expr:eq(mod(n,50),0)" -c:a copy -pass 1 -y test1.ts >nul &&
ffmpeg -i source.mp4 -pix_fmt yuv420p -codec:v libx264 -x264opts rc-lookahead=50:keyint=100:min-keyint=50 -profile high -level 4.1 -preset slow -b:v 1M -force_key_frames "expr:eq(mod(n,50),0)" -c:a copy -pass 2 -y output.ts

[OvejaNegra]

if crf≤18 - no-mbtree, deblock -3:-3
if crf≤16 - no-mbtree, no-deblock, no-psy (otherwise, these options degrade quality)


why not mbtree or psy?
how do they degrade quality
Put and example please


no deblock? i always understood and the x264 authors say
that the deblock is part of the standard and it should never
be disabled. Lowering it was a better practice (if you dont want it).

thanks