Transcoding video for storage

[Tony_G]

Hey All,

I'd like to recover some of the space I have on my raid array from the video that I have saved. It seems that the recommendation for this is to transcode the video into another format with better compression. With that in mind, I installed handbrake and did a bit of a test on it.

Here is what I found:

Original video size - 3.03 GB

H.265

Render preset	GPU Encoding Size	CPU Encoding Size
Very Fast	1.8 GB	494 MB
Fast	1.84 GB	703 MB
High Quality	1.96 GB	1.12 GB
Super High Quality	1.96 GB	1.59 GB

GPU Encoding is an RTX 2060 and the difference in times seems to be about 3:1 faster for the GPU encoding. The resultant images don't seem very different at all.

CPU SHQ


GPU SHQ


CPU VF


GPU VF


I wondering if anyone has done this before and if you might have some insights into why the CPU encoding seems to be a smaller size that the GPU encoding.

Thoughts?

TonyG

[David Hess]

In my experience with X.264, GPU encoding yielded much worse quality than CPU encoding even at significantly lower compression ratios.  Given how much transcoding performance is available with multi-core CPUs now, I would only use GPU encoding for live streaming where the extra speed matters.

[tooki]

Software-based CPU encoding is almost universally superior in both quality and compression ratio. The only reason for doing video compression in a hardware compression engine (whether contained in the GPU, CPU, or another support chip) is to unburden the CPU, either to leave the CPU available for other tasks, or to reduce power consumption.

As for why this is so, my guess is that the hardware encoders are always a bit behind in the algorithms (since they can’t be updated after manufacture), whereas software encoders can be refined over time. And of course the complexity of a hardware encoder may be limited by transistor budget.

One of the key things to remember is that the standards for lossy compression do not specify how to encode, they only specify what format the data is in, and the decoders are very clearly defined. So as long as the output of the encoder is formatted correctly, how the encode is done is up to the implementer. As such, encoder implementations vary wildly. Hardware encoders (especially the ones in cameras, etc.) are often designed to enable real-time encoding, such that the time allowed for encoding is fixed. A software encoder can take extra time for complex scenes, allowing it to produce much better output. The intense image analysis done in modern encoders is why the encoding speed isn’t constant, with some segments taking much longer than others. h.265 uses far, far, far more complex analysis than h.264, which is why it takes so much longer to encode. Playback is more complex, but not by nearly as big a ratio.

[SiliconWizard]

As for why this is so, my guess is that the hardware encoders are always a bit behind in the algorithms (since they can’t be updated after manufacture), whereas software encoders can be refined over time. And of course the complexity of a hardware encoder may be limited by transistor budget.

Although I haven't worked on this directly so this is just a guess, I'm suspecting two potential main differences for the GPU versions: 1/ many compressions algorithms have different "levels" with various trade-offs, and the GPU implementations may not be using the best overall level for quality (to favor speed for instance, as a selling point to show how vastly faster GPUs are for this), 2/ GPU implementations may also use numbers with less precision, leading to more severe rounding errors.

[David Hess]

A software encoder can take extra time for complex scenes, allowing it to produce much better output. The intense image analysis done in modern encoders is why the encoding speed isn’t constant, with some segments taking much longer than others.

Software encoding on the CPU also allows for two pass encoding to a constant bitrate which is my preferred method.

[rdl]

I wasn't aware of any way to choose between GPU and GPU in Handbrake. Of course, I've been using an older version, 0.98 I think with x.264. One thing I'll point out is that using the options instead of presets gives you a lot of control over various encoding parameters and some of those can make a very big difference in speed and file size. Downside is that it can take a lot of time experimenting to find what works best for you.

[coppice]

In my experience with X.264, GPU encoding yielded much worse quality than CPU encoding even at significantly lower compression ratios.  Given how much transcoding performance is available with multi-core CPUs now, I would only use GPU encoding for live streaming where the extra speed matters.

That depends what GPU you are using. H.264 won't really parallelize well on a GPU, so they take some liberties with the arithmetic to get reasonable speed, which compromises the quality. However, some GPUs have specific H.264 accelerating hardware which should give similar results to a CPU software encoder.

[tooki]

In my experience with X.264, GPU encoding yielded much worse quality than CPU encoding even at significantly lower compression ratios.  Given how much transcoding performance is available with multi-core CPUs now, I would only use GPU encoding for live streaming where the extra speed matters.

That depends what GPU you are using. H.264 won't really parallelize well on a GPU, so they take some liberties with the arithmetic to get reasonable speed, which compromises the quality. However, some GPUs have specific H.264 accelerating hardware which should give similar results to a CPU software encoder.

Ummm, “specific h.264 accelerating hardware” is what everyone means when we say “GPU encoding”. We don’t mean running a GPU-based software encoder!

Anyhow, there’s absolutely no reason to assume a hardware h.264 encoder will be comparable to a CPU software-based one. As I and others have explained, it’s actually quite the contrary, that the hardware encoder is unlikely to match (never mind exceed) the quality of the software encoder.

Note also that many CPUs now also have hardware h.264/265 encoders, and as I mentioned, so do some other chips (for example, the T2 system controller chip in recent Macs not only handles security, SSD controlling, and the boot process, but also includes hardware video encoders). So a recent Mac with an AMD graphics card actually has at least three hardware video encoders to choose from: the Apple T2, the Intel Quick Sync in the CPU, and the one in the AMD GPU.

[coppice]

In my experience with X.264, GPU encoding yielded much worse quality than CPU encoding even at significantly lower compression ratios.  Given how much transcoding performance is available with multi-core CPUs now, I would only use GPU encoding for live streaming where the extra speed matters.

That depends what GPU you are using. H.264 won't really parallelize well on a GPU, so they take some liberties with the arithmetic to get reasonable speed, which compromises the quality. However, some GPUs have specific H.264 accelerating hardware which should give similar results to a CPU software encoder.

Ummm, “specific h.264 accelerating hardware” is what everyone means when we say “GPU encoding”. We don’t mean running a GPU-based software encoder!

Anyhow, there’s absolutely no reason to assume a hardware h.264 encoder will be comparable to a CPU software-based one. As I and others have explained, it’s actually quite the contrary, that the hardware encoder is unlikely to match (never mind exceed) the quality of the software encoder.

Note also that many CPUs now also have hardware h.264/265 encoders, and as I mentioned, so do some other chips (for example, the T2 system controller chip in recent Macs not only handles security, SSD controlling, and the boot process, but also includes hardware video encoders). So a recent Mac with an AMD graphics card actually has at least three hardware video encoders to choose from: the Apple T2, the Intel Quick Sync in the CPU, and the one in the AMD GPU.

From a quick check everything from Nvidia's Kepler generation forwards does some H.264 acceleration. I didn't realise it was so far back when we were having trouble with that. However, its only the later Maxwell parts that started accelerating H.265, so a lot of people will still have that accelerated in GPU code.

[tooki]

I don't think so. It's done in the CPU, not the GPU. Again, I don't think we're on the same page regarding terminology, nor on what the technology actually is.

[duak]

This may not be directly related to CPU vs GPU, but maybe it does.  I have a superficial understanding of how Codecs work and how they are applied to video.  Would it be fair to say that Codecs are black boxes that have precise specifications on inputs and outputs that have to be met right down to the bit level?  Or do they have an error band and as long as it isn't exceeded it's fine?  An analogy is the hp and TI calculator wars where there were differences in the nth places of the results from some operations because the designers used different algorithms and/or different implementations of the same algorithm.

Going one step further, I wonder if decoding generates artifacts that makes subseqent encoding with a different Codec less efficient or less accurate?  ie., some of the encoding bandwidth is taken up trying to deal with something that was introduced by the first Codec?

I've got a bunch of video data that I'd like to transcode and I've been using Handbrake to do it.  Are there any tools that can analyze a video file and give some quantitative measure of the losses incurred by a Codec? ie., effective bandwidth, distortion products, S/N ratio - things like that?  I've been just looking at the video and the transcoded file size but still haven't settled on a good quality factor.

One goofy thing that I don't always remember to set when using Handbrake is the frame rate - 30 Hz vs 29.97 Hz - leading to the sound stopping.  I know the color NTSC frame rate is 29.97 Hz but I sometimes forget to set this parameter correctly with some source material.

[coppice]

This may not be directly related to CPU vs GPU, but maybe it does.  I have a superficial understanding of how Codecs work and how they are applied to video.  Would it be fair to say that Codecs are black boxes that have precise specifications on inputs and outputs that have to be met right down to the bit level?  Or do they have an error band and as long as it isn't exceeded it's fine?

For most video codecs the decoder is strictly defined, and the encoder is loosely defined. This means an encoder developer knows exactly how the decoder should behave, but has considerable freedom to innovate better ways to encode.

[hans]

Exactly. A codec describes the storage format and rendering steps for lossy video data. A decoder can process the stored graphic entities and render a correct output. This step is relatively straight forward. The encoding step on the other hand has a much larger search space, and since it's lossy in nature, and has many tunables, algorithms and accuracy/speed/size trade-offs. Typically these "superfast" and "fast" presets will make many adjustments to these tunings to reduce the encoding time, but these generally also reduce the video quality and/or video size output (as you've shown in your test case). Then there may also be tuning profiles that operate better on for example cartoons, fairly static video or fast moving video.

For example, H265 can be far more efficient for videos with large frame sizes. H265 has introduced some larger video region sizes which can be described I believe, and hence is more effective for 1080p or 4K resolutions that has a greater probability of "low entropy" video zones. There was a time that x265 was not considered to be an interesting alternative to x264, but that was years ago. I think these days, the output quality is typically comparable for often half the file size. I would recommended choosing a quality setting right now, since it's not recommended to iterate the encoding for a video over and over again (e.g. video source with high bitrate > H265 "Super fast" > H265 "Fast'), etc. The encoding artifacts for any file are present, and you will likely not see much improvement (if not an increase of file size) if you decide to reencode it in the future.

I prefer H265 CPU encoding using Handbrake as well using the superfast preset with a constant-quality of 22 (variable bitrate allows static scenes, which have little entropy, to be encoded efficiently, while fast moving scenes with more entropy get their fair share of the "pie").
E.g. your very fast and fast benchmark yielded roughly 200MB saved on a file of 500 - 700MB, but I suspect that these settings may have taken 50% of 100% longer to complete. Comparing to the original size of 3GB, you've already gotten a massive fileshrink, so IMO there is little reason to squeeze the last 200MB out of it.

If you do choose to use x265 CPU encoding, I would recommended getting a CPU with modern AVX instructions I upgraded from an Ivy Bridge i5 3570k to a Ryzen 3900X, and saw up to 8x speed improvement in video encoding. Sure that Ryzen chip has 3x more cores and 6x the thread count, and many generations of IPC improvement, but also a far more modern vector instructions.
For example, the 2700X vs 3700X is about 33% faster in x265, while typical multi-threading benchmarks show "only" 15 - 20% speed improvement between these 2 chips.

[David Hess]

If you do choose to use x265 CPU encoding, I would recommended getting a CPU with modern AVX instructions I upgraded from an Ivy Bridge i5 3570k to a Ryzen 3900X, and saw up to 8x speed improvement in video encoding. Sure that Ryzen chip has 3x more cores and 6x the thread count, and many generations of IPC improvement, but also a far more modern vector instructions.
For example, the 2700X vs 3700X is about 33% faster in x265, while typical multi-threading benchmarks show "only" 15 - 20% speed improvement between these 2 chips.

Intel has supported AVX2 since 2014 so you would have to go far out of your way to find an Intel system which does not support it now.  Intel's Ivy Bridge processor was the last Core microarchitecture which did not support it so you just barely missed it back in 2012 or 2013.

Core for core Intel and AMD Ryzen are about equal now for x264 but Ryzen CPUs are more economical.

[coppice]

If you do choose to use x265 CPU encoding, I would recommended getting a CPU with modern AVX instructions I upgraded from an Ivy Bridge i5 3570k to a Ryzen 3900X, and saw up to 8x speed improvement in video encoding. Sure that Ryzen chip has 3x more cores and 6x the thread count, and many generations of IPC improvement, but also a far more modern vector instructions.
For example, the 2700X vs 3700X is about 33% faster in x265, while typical multi-threading benchmarks show "only" 15 - 20% speed improvement between these 2 chips.

Intel has supported AVX2 since 2014 so you would have to go far out of your way to find an Intel system which does not support it now.  Intel's Ivy Bridge processor was the last Core microarchitecture which did not support it so you just barely missed it back in 2012 or 2013.

Core for core Intel and AMD Ryzen are about equal now for x264 but Ryzen CPUs are more economical.

The Haswell generation introduced AVX2 in 2014, but the older non-AVX2 parts were in high volume production long after that. Maybe you change your computer every year, but even most business notebooks are only being changed every 4 to 5 years these days.

[David Hess]

The Haswell generation introduced AVX2 in 2014, but the older non-AVX2 parts were in high volume production long after that. Maybe you change your computer every year, but even most business notebooks are only being changed every 4 to 5 years these days.

Newegg still carries pre-Haswell processors and motherboards but I wonder what supports demand for them.  They are not significantly less expensive.

I change my computer about every 10 years.  My newest systems are a Phenom 940 which I bought and an i7-870 which was given to me.

[Tony_G]

Just to wrap this up (had to step away for a funeral, unfortunately) here is a look at how the CPU conversion from H.264 to H.265 worked on file sizes:



Thanks everyone for the responses.

TonyG