FFMPEG HEVC/H.265 settings help

[kevindd992002]

My media library is composed of all H264-compressed movies and tv show files. I'm planning on using FFMPEG to convert everything to H265 but have a couple of concerns in doing so.


1. What is the difference between intra (main10-intra) and non-intra profiles (main10) in H265? Are there any other H265 video profiles that are available with FFMPEG?

2. For bit depth, 8bit, 10bit, or 12bit? I'm reading that 12bit is overkill and 10bit is actually very good for HDR. Is this accurate and should I go for 10bit?
3. For chroma subsampling, 4:2:0, 4:2:2, or 4:4:4? I'm reading that for movies and tv shows where you watch a couple of feet away from the TV, 4:2:0 is more than enough. 4:4:4 is almost only used when either using your TV as a PC monitor or using it with console games with a lot of texts. How about 4:2:2, where is it mostly used?
4. What is the equivalent H265 CRF for H264 CRF of 18?
5. Do you recommend using VAAPI HW encoding for this use case? I know SW encoding is almost always better (in terms of quality) than HW encoding, but HW encoding is just super faster than SW encoding.



Thanks for the help!

[abolibibelot]

Don't do dat.

I don't know much yet about the intricacies of the H265 format, but what you intend to do seems rather pointless, as you will either lose quality (and at least for now compatibility with most hardware players) or actually increase the size of said library, which definitely defeats the purpose. Because "the equivalent H265 CRF for H264 CRF of 18", whatever it is, is probably not going to shrink the size of the current files which are probably compressed with much more bitrate constrained settings (equivalent to x264 CRF 23 or more — by the way, "H.264" is the generic name of the format, x264 is a particular open-source implementation, so the CRF scale in question applies to x264, not H.264). Also, I may be mistaken, but I don't see the point of going from 8bit 4:2:0 (which are most likely the current parameters for all those videos) to higher values, which are meant to preserve a certain level of quality and detail, but can't re-generate something that's already been lost in compression.

[kevindd992002]

Don't do dat.

I don't know much yet about the intricacies of the H265 format, but what you intend to do seems rather pointless, as you will either lose quality (and at least for now compatibility with most hardware players) or actually increase the size of said library, which definitely defeats the purpose. Because "the equivalent H265 CRF for H264 CRF of 18", whatever it is, is probably not going to shrink the size of the current files which are probably compressed with much more bitrate constrained settings (equivalent to x264 CRF 23 or more — by the way, "H.264" is the generic name of the format, x264 is a particular open-source implementation, so the CRF scale in question applies to x264, not H.264). Also, I may be mistaken, but I don't see the point of going from 8bit 4:2:0 (which are most likely the current parameters for all those videos) to higher values, which are meant to preserve a certain level of quality and detail, but can't re-generate something that's already been lost in compression.

I should've given you a background of how I come up with my media files. As soon as I download a media file from the Internet, it gets converted to mp4 (h264 format, crf 20, high profile) using the sickbeard_mp4_automator script. I did already try converting one media file from h264 crf 20 to h265 crf 23 and had around 70% file size savings with a lower bitrate file.


Thanks for the explanation regarding the difference between h.264 and x264. I guess I was confused because you can put both h264 and x264 as a filter value for the video-codec in that script. Do you have any idea why?



But I get what you're saying. I'm practically compressing an already-compressed file that I get from the Internet twice if I decide to convert everything to H265. So loss on top of loss on top of loss. As for doing 8bit to 10bit conversion, when would it be beneficial? Just during the first conversion of the mkv to mp4?

[kevindd992002]

Also, for audio channel bitrate would 256 Kbps be enough? Or can I go full 320 Kbps?

[abolibibelot]

I should've given you a background of how I come up with my media files. As soon as I download a media file from the Internet, it gets converted to mp4 (h264 format, crf 20, high profile) using the sickbeard_mp4_automator script. I did already try converting one media file from h264 crf 20 to h265 crf 23 and had around 70% file size savings with a lower bitrate file.

I haven't tried encoding in H.265 yet and don't know what CRF 23 represents in terms of quality preservation, but unless the files downloaded (through legal means of course ! *cough*) are very high quality to begin with, like blu-ray disc ISOs or passthrough MKV remuxes, there's little point in converting from a lossy format to another slighly more efficient lossy format. The difference in efficiency, i.e. ability to retain a decent visual quality at lower bitrates, is far less than between MPEG2 and Xvid for instance ; it made sense to convert MPEG2 DVDs to Xvid AVIs because the compression could reach a factor 5, or more with a reduced resolution (and back then when it was the norm on teh Internetz the storage space was scarce and expensive). Between H.264 and H.265, from what I've read the difference is about 30%, which is an impressive improvement at that point, considering how efficient H.264 already was, but from a practical standpoint it's too small to justify a systematic conversion just for the sake of saving a few gigabytes (or even hundreds of gigabytes – you may end up spending more in electricity alone to do those conversions than the cost of a brand new hard drive large enough to contain ten times the total amount of space thus saved !).

Thanks for the explanation regarding the difference between h.264 and x264. I guess I was confused because you can put both h264 and x264 as a filter value for the video-codec in that script. Do you have any idea why?

Not Sure. In this case it must mean the same thing, as x264 is the only open-source H.264 encoder I know of. But there are other, non open-source (commercial) H.264 encoders, like MainConcept for instance, used by many non linear editors.

Also, for audio channel bitrate would 256 Kbps be enough? Or can I go full 320 Kbps?

Depends what the source is, 256kbps is plenty enough for stereo audio, for 5.1 or more channels a higher bitrate is usually required to preserve a good quality. Constant bitrate encoding is less efficient / optimized than setting a quality level and letting the encoder allocate bitrate as required for each source.