quality when using hevc_videotoolbox

[Technofrikus]

When using the --hevc option on h264 content (I know, not ideal) I get much faster speeds (5-8x!) then with handbrake, because it uses the Apple VideotoolBox and therefore the integrated Intel Graphics. That is great! I want to convert my videofiles to save space, but not loose quality.

With standard settings it uses 8000kbps on my test file (1080p cartoon) which has a 5000kbps original bitrate (h264). So the size increases with standard settings, not useful in this case. When using 3500 kbps the size is fine, but the quality is much worse in fast moving scenes. Many blocks.

When using handbrake (constant quality) it is much (!) slower, but the final bitrate was 1700kbps with no (obvious) loss in quality.

Question: Is it to be expected that the quality of the h265 encode is worse with (Intel) Graphics Hardware acceleration using Apple VideoToolbox than with handbrake (using constant quality)?

[lisamelton]

@Technofrikus Transcoding HEVC to HEVC again is never a good idea if the original HEVC content contains HDR color information. This is because neither FFmpeg nor HandBrake will retain that HDR data.

And, frankly, if you already have a 1080p video at 5000 Kbps, why would you ever want to re-transcode it? This is just a waste of time.

Also realize that you will always degrade quality when transcoding. The question is by how much. The ratecontrol systems used by the other-transcode tool are designed to minimize that as I explain here:

https://github.com/donmelton/other_video_transcoding/wiki/Ratecontrol

Understanding ratecontrol

Ratecontrol is how a video encoder decides on the amount of bits to allocate for a specific frame. Most encoders have more than one ratecontrol system available. Selecting the best system and then properly configuring it is key to high-quality video transcoding.

The ratecontrol systems used by the other-transcode tool target a specific bitrate rather than a fixed quality level. This is because using a fixed quality level can result in output larger than its input or, worse, output too low in quality to be mistaken for that input.

It seems counterintuitive, but targeting a specific bitrate makes it much more likely that in those low-motion scenes where the eye can linger, that enough bits are allocated to prevent color banding. And color banding is actually much more noticeable than artifacts like blockiness in high-motion scenes.

Rather than limiting the maximum bitrate to the same value as the target, the other-transcode tool selects an average bitrate (ABR) ratecontrol system. This means that the encoder is allowed to adjust bitrate allocation to accomodate complexity and mitigate the risk of blockiness or other artifacts.

Hopefully that answers your question.

[Technofrikus]

Hei Don, thanks for the answer. I mistyped the first h264, sorry (edited now). I want to convert h264 to h265 since it saves around 40%-50% space.

Of course this will degrade the quality a little, but with high bitrate h264 as the source and enough bitrate for h265 this is usually nearly invisible to me and ok for the size benefit.

I understand that ABR is much better than CBR of course. But why it is better than constant quality is not obvious to me (even after reading your FAQ) since it is in my understanding basically the same as ABR with even more freedom to allocate more bitrate in demanding scenes. I had good results with Handbrake and constant quality (RF20.5), files are noticeably smaller than the source (high bitrate h264 for me) and still had a good quality. But you made your research, I dont need to know in detail. And your usecase is different (BR as source).

I investigated further and the quality seems to depend heavily on the encoder (GPU vs software). When using the Apple VideoToolbox vs the software encoder (--x265) with the same bitrate (2500kbps) the software encoder is significantly slower (although still about twice as fast as Handbrake) but creates much better quality. The GPU-encoded quality is really blocky, the software-encoded is totally fine. So, this answers my question :) Sadly no GPU-encoding for me, although much faster, the quality is not useable in my opinion.

[lisamelton]

@Technofrikus OK, it seems like your question has been answered so I'll close this issue now.