Does this encoding size make sense?

[jriker1]

I am playing with ffmpeg for re-encoding HEVC HDR10 4k content. Been doing it with Premiere but loosing the HDR10 content when re-encoding. So I run this:

ffmpeg.exe -<INPUT_FILE> -c:v libx265 -x265-params level=51:hdr10=1:hdr-opt=1:high-tier=1:repeat-headers=1:colorprim=bt2020:transfer=smpte2084:colormatrix=bt2020nc:master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50):max-cll=349,86:crf=16:chromaloc=2:no-sao=1:info=0 -preset slower -pix_fmt yuv420p10le -sn -an <OUTPUT.HEVC>

So the source file is 71GB. So I set no max or min bitrate values in the output and let it fly with CRF of 16. The resulting output file is 14GB. Is this expected? I'm used to doing constant bitrate thru Premiere for other stuff to maintain a known approx size with good quality so this more random sized thing is new to me.

Not sure the bitrate as obviously it changes a lot and in VLC not sure how to interpret the "input" vs the "content" bitrate at any given time.

[Boulder]

CRF does variable bitrate encoding and you never know the final size beforehand. It also depends entirely on the content itself. Nevertheless, that size looks quite normal.

[Blue_MiSfit]

Keep in mind lower CRF is generally needed for HDR content to keep similar quality. I'd go 2-4 steps lower than you'd normally go. Ultimately you need to review the content and make sure the output looks good enough for you.

[benwaggoner]

Why are you using High Tier? Main10 Level 5.1 allows for 40 Mbps in vbv-maxrate and vbv-bufsize, which should be plenty for a reencode.

I generally prefer to use at least --preset slower for HDR. I sometimes get some odd chroma artifacts with rdLevel=4 of HDR 4K encoding with grain. I imagine due to rdLevel 3/4's use of chroma residual instead of RDO prediction.

When luma contrast is low, I'll sometimes see the chroma of an object left behind when an object moves.

[jriker1]

Thanks for the replies. With looking at the content, I historically have hit constant bitrates that things looked good but probably also used more bits than needed. Always been 1080p content. With things I just wanted to keep I did constant 8,000kbps and with things I really liked I used 10,000kbps. Good or bad, who knows. And that was with WMV HD.

With HDR content it's all new to me and was going to do like 15Mbps for standard stuff at 17.5Mbps for stuff I like like. Not sure how well I can visualize good or not since I don't have a physical monitor that can view it with as HDR content. Is looking at it on a wall TV the way to look? Could I go back and forth between the two videos on my TV, probably not easily and know if there are differences since they aren't side by side so wanted to just find an encoding CRF that is clean. So then I find out that I can't use any of my "higher cost" rendering tools and maintain the full HDR10 info I switched to ffmpeg, which technically doesn't have a CBR option so here I am.

[benwaggoner]

Thanks for the replies. With looking at the content, I historically have hit constant bitrates that things looked good but probably also used more bits than needed. Always been 1080p content. With things I just wanted to keep I did constant 8,000kbps and with things I really liked I used 10,000kbps. Good or bad, who knows. And that was with WMV HD.
I was at Microsoft working on digital media 2005-2012. Interesting times.

Anyway, WMV HD didn't have a quality VBR mode like x265's CRF. "Quality" mode was just fixed QP. The only real choices were CBR or 2-pass VBR.

With x265, CRF allows for a capped VBR that is better tuned to deliver real-world quality at reasonable bitrate. If you're archiving stuff you want to look good but not be super big, it's the mode you want.

With HDR content it's all new to me and was going to do like 15Mbps for standard stuff at 17.5Mbps for stuff I like like. Not sure how well I can visualize good or not since I don't have a physical monitor that can view it with as HDR content. Is looking at it on a wall TV the way to look? Could I go back and forth between the two videos on my TV, probably not easily and know if there are differences since they aren't side by side so wanted to just find an encoding CRF that is clean. So then I find out that I can't use any of my "higher cost" rendering tools and maintain the full HDR10 info I switched to ffmpeg, which technically doesn't have a CBR option so here I am.
CBR is so 90's. The old saw is that you get constant bitrate by varying quality, and consistent quality by varying bitrate. People really don't do CBR for files or discs anymore, just for live streaming.

Also, making backup encodes of content you can't watch is probably premature ;).

If you have a semi-recent GPU and Windows 10, you should be able to plug the GPU into the TV and have it act as a HDR monitor (hand-waving around a lot of caveats).

[Boulder]

What I did when determining a good enough CRF level was that I encoded two or three rather static scenes at different CRFs and compared those on the TV, sitting a little closer than I normally do. I started from the level where I knew there would be visible artifacts and encoded a couple of samples coming down one notch at a time. When I found out a value where the artifacts seemed to disappear, I started using one notch lower than that for a little headroom. Hence it's been mostly CRF 18 for SDR at 720p and CRF 14 for HDR at 1440p or 1080p. Sometimes I use 19 and 15, if the source is very noisy and bitrates shoot through the roof.

[asarian]

CRF does variable bitrate encoding and you never know the final size beforehand. It also depends entirely on the content itself. Nevertheless, that size looks quite normal.

Yeah. I recall asking the same question a few days ago. :) CRF 10 worked out wonderfully for me, with my denoised The Fifth Element.

[jriker1]

Yeah. I recall asking the same question a few days ago. :) CRF 10 worked out wonderfully for me, with my denoised The Fifth Element.

I'm currently at CRF 16 for "whatever" movies and CRF 13 for ones I really like. That said, I stopped denoising unfortunately as when you have HDR content was told denoising will alter the video where the HDR metadata won't be valid for the final media.

[benwaggoner]

I'm currently at CRF 16 for "whatever" movies and CRF 13 for ones I really like. That said, I stopped denoising unfortunately as when you have HDR content was told denoising will alter the video where the HDR metadata won't be valid for the final media.
I wouldn't worry about that overmuch. Most TVs ignore the static metadata anyway. And the same metadata is supposed to be use for all output streams for a given source, even a 400x224 or something, despite the low pass filter averaging out small highlights and stars.

[benwaggoner]

Yeah. I recall asking the same question a few days ago. :) CRF 10 worked out wonderfully for me, with my denoised The Fifth Element.
Could you tell the difference between --crf 10 and --crf 16? 10 is well below the threshold of "more bits look the same" in all the testing I've done.

[jriker1]

Got a new one. So I have a 4k Bluray that I'm converting and with the below settings ends up with 44.6 mb/s encoding rate. Guessing with CRF that's an average? File nets out to 32GB for an hour and a half movie. What am I missing?

ffmpeg.exe -i <input file> -c:v libx265 -x265-params level=51:hdr10=1:hdr-opt=1:high-tier=1:repeat-headers=1:colorprim=bt2020:transfer=smpte2084:colormatrix=bt2020nc:master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50):max-cll=1000,228:crf=16:chromaloc=2:no-sao=1:info=0:range=limited -preset slower -pix_fmt yuv420p10le -sn -an "<output file>.hevc"

[RanmaCanada]

Got a new one. So I have a 4k Bluray that I'm converting and with the below settings ends up with 44.6 mb/s encoding rate. Guessing with CRF that's an average? File nets out to 32GB for an hour and a half movie. What am I missing?

ffmpeg.exe -i <input file> -c:v libx265 -x265-params level=51:hdr10=1:hdr-opt=1:high-tier=1:repeat-headers=1:colorprim=bt2020:transfer=smpte2084:colormatrix=bt2020nc:master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50):max-cll=1000,228:crf=16:chromaloc=2:no-sao=1:info=0:range=limited -preset slower -pix_fmt yuv420p10le -sn -an "<output file>.hevc"
It depends on the movie. If it is a newer, shot on digital type movie, then that is rather large. If it's one that was originally shot on film and has been "remastered", that is perfectly fine. Film grain makes all the difference. Most movies these days are completely flat, unless the company creates noise to mimick grain.

[jriker1]

Thanks for the reply. This is the disk I have and am trying to get loaded into Emby digitally:

https://www.amazon.com/Coming-America-4K-UHD-Digital/dp/B08JB1XDNG#customerReviews

Thanks.

JR

[RanmaCanada]

Thanks for the reply. This is the disk I have and am trying to get loaded into Emby digitally:

https://www.amazon.com/Coming-America-4K-UHD-Digital/dp/B08JB1XDNG#customerReviews

Thanks.

JR

As it is an "older" movie (1988), yes it would have a lot of film grain so that size is to be expected. Grain is "noise" and x265 still can't handle it as well as x264 can, though it is much better than it used to be.

[jriker1]

Trying another old one and it's about a third of the way thru the video and is currently half the size of the source so expect it to be a third larger than the source when done and the source is HEVC x265. as well already. Looking at the source the video is encoded 47.6MB/s so I don't even want to guess what CRF 16 is encoding this thing at right now. Wish there was another way to encode this content and pass all the HDR10 metadata plus the other HDR formats metadata to the video as converted. With HEVC could probably encode a video with Premiere Pro at a constant bitrate of 8MB/s and look clean but would loose the HDR metadata if the TV uses it or not.

[RanmaCanada]

If you're so concerned about size, you could always just shrink them down to 1080 instead of keeping them at 4k. Old video at 4k is difficult at best, and the grain just makes more optimizing impossible without losing details. Look at what the denoising of the LOTR box sets did.

[jriker1]

If you're so concerned about size, you could always just shrink them down to 1080 instead of keeping them at 4k. Old video at 4k is difficult at best, and the grain just makes more optimizing impossible without losing details. Look at what the denoising of the LOTR box sets did.

I don't understand fully. Not to sound adversarial but do we think it's OK to take a 4k video that is 49GB in size and run it thru ffmpeg at 16 CRF and it comes out 74GB?

[VoodooFX]

I don't understand fully. Not to sound adversarial but do we think it's OK to take a 4k video that is 49GB in size and run it thru ffmpeg at 16 CRF and it comes out 74GB?
That means you need to increase CRF.
Btw, that "4k video that is 49GB" can be a bitstarved encode, so a hardly compressible video.

[RanmaCanada]

I don't understand fully. Not to sound adversarial but do we think it's OK to take a 4k video that is 49GB in size and run it thru ffmpeg at 16 CRF and it comes out 74GB?

That is perfectly fine if the movie has a LOT of grain. Alien for example, when encoded with x265 becomes larger due to the way x265 handles grain. What is the movie in question. I myself just remux older titles as the processing time is not worth it as I can not do a better job than the studio did. Movies today are extremely flat.

[benwaggoner]

Tuning around grain is important here. I don't recommend --tune grain if file size matters and grain isn't really bad; that turns off all kinds of psychovisual optimization and makes it almost a fixed-QP encode.

If I'm dealing with grain, I'll try things like --rskip 0 or 2, --hme, --nr-inter 150. --rd 6 seems to help quite a lot.