Quality of H.265 via Skylake QuickSync vs. regular CPU encoding

[superstition]

I have tested CPU encoding with an AMD FX 8 core and an Nvidia GTX 460. I've used Handbrake and Sorenson.

I used Babylon 5 film DVDs for the testing.

What I found is H.265 dramatically outperforming H.264 in terms of quality for MB. The final setting I was pleased with (Handbrake) was 17 quality and "very slow" setting. The problem is that very slow is extremely slow and takes over two days with the FX chip to encode a single DVD. The chip is not fully-loaded at all, unlike with H.264. Days to encode a single DVD is unfortunate but the quality boost over "slow" is noticeable as is the size difference. However, with the FX I would stick with the "slow" setting because it takes like 8 hours.

I assume this is because I have read that parallelization of video encoding and quality are opposing. The more quality you want the more serial the process is. This appears to be seen in the way H.265, as I recall, does load the processor heavily with a fast low-quality setting like "medium."

Another interesting thing I found is that H.264, at least with Handbrake, is heavily sensitive to temporal noise, in terms of bloating the file size. This makes it necessary to use noise filtering to keep the file size down. However, I tried various algorithms for that and quality was always noticeably lost. With H.265 I was surprised to see a lot of temporal noise (in some scenes of the Babylon 5 stuff) having minimal effect on file size. It's still annoying (the noise) but it's better to leave it in than it is to overly blur people's faces.

I also found that Nvidia's GPU encoding of H.264 was terrible although the encoding was fast. This suggests, again, the point that heavy parallelization means low quality. Maybe more recent Nvidia cards have improved quality but I am really not interested in H.264 at all because it's so much less effective than H.265 in terms of preserving quality at low file sizes. Why bother encoding at all if the file size is going to be so bloated?

The question I have is: Are there any reviews that show, clearly, the quality of Skylake's H.265 encoding versus something like Handbrake on "very slow"?

If it's just fast, but has mediocre quality and/or file size then I'll be disappointed. However, if it provides at least the "slow" quality of Handbrake with fast speed then it would be quite an improvement over 8 hours of encoding time for one DVD.

 

[Soulkeeper]

There is a quality/size loss due to threading. Although it is small enough to usually be within the margin of error when dealing with 1-8 threads from what i've noticed. I havn't experimented with QuickSync. I've only used CPU in a linux environment, but the same general ideas apply. When encoding/transcoding multiple files it's better to do 4 or 8 at once in single threaded mode than 1 with 4 or 8 threads.

 

[The Stilt]

Something is not right if HEVC encoding doesn´t fully utilize the CPU or encoding a DVD movie takes "days". On a FX-8K CPU you should reach at least real time encoding speed for DVD resolutions.

 

[escrow4]

Something is not right if HEVC encoding doesn´t fully utilize the CPU or encoding a DVD movie takes "days". On a FX-8K CPU you should reach at least real time encoding speed for DVD resolutions.

Not with x265. Its heavy to encode and heavy to decode. I'd avoid it for another year or two at least until it matures OP. x264 may be fatter but it works well. The Pi 2 say works fine with x264 but if you want all round x265 playback you basically want a desktop class Skylake CPU.

 

[The Stilt]

Not with x265. Its heavy to encode and heavy to decode. I'd avoid it for another year or two at least until it matures OP. x264 may be fatter but it works well. The Pi 2 say works fine with x264 but if you want all round x265 playback you basically want a desktop class Skylake CPU.

I know perfectly well that it is extremely heavy. I´ve converted tons of my Blu-Rays to HEVC for more convinient use.

Still a FX-8K CPU running at ~4GHz should be able to encode a DVD movie (720x576) at > 32fps with good settings (slow preset, CRF < 17). Using even slower presets or better motion search methods will slow it down, but no sane person would use them for a DVD movie anyway.

Regardless the settings, if encoding a DVD movie takes "days" then there is something very wrong going on.

I´ve never used Handbrake thou, as I find the combination of ffmpeg (libav) decoder and stand-alone x265 encode as a better combination.

 

[Charlie98]

There is a quality/size loss due to threading. Although it is small enough to usually be within the margin of error when dealing with 1-8 threads from what i've noticed. I havn't experimented with QuickSync. I've only used CPU in a linux environment, but the same general ideas apply. When encoding/transcoding multiple files it's better to do 4 or 8 at once in single threaded mode than 1 with 4 or 8 threads.

So what you are saying is a single-threaded transcode (I use Handbrake myself...) will render a better rip? Not larger or smaller... but better quality?

EDIT: Wow... 2 hours to transcode a full screen movie that took 13 minutes prior, with all 4 cores. D:

 

[someEEguy]

I have tested CPU encoding with an AMD FX 8 core and an Nvidia GTX 460. I've used Handbrake and Sorenson.

I used Babylon 5 film DVDs for the testing.

What I found is H.265 dramatically outperforming H.264 in terms of quality for MB. The final setting I was pleased with (Handbrake) was 17 quality and "very slow" setting. The problem is that very slow is extremely slow and takes over two days with the FX chip to encode a single DVD. The chip is not fully-loaded at all, unlike with H.264. Days to encode a single DVD is unfortunate but the quality boost over "slow" is noticeable as is the size difference. However, with the FX I would stick with the "slow" setting because it takes like 8 hours.

Are there enough jobs that you could split them up over multiple instances of Handbrake (until your processor is at/near full load)? If so that would make the overall process faster on your current hardware.

 

[SPBHM]

Not with x265. Its heavy to encode and heavy to decode. I'd avoid it for another year or two at least until it matures OP. x264 may be fatter but it works well. The Pi 2 say works fine with x264 but if you want all round x265 playback you basically want a desktop class Skylake CPU.

you will probably be fine with a lot less for DVD resolution, my t7200 (2ghz C2D) plays some 720P HEVCs quite fine

unless you are talking about 4K60 or something, in that case, just buy a GTX 950

for h264 Quicksync is not great at delivering best image quality per size, so I would assume h265 will also have better software encoders for that,

 

[Deders]

Have there been any quality test for quicksync since sandy bridge?

 

[mikk]

The question I have is: Are there any reviews that show, clearly, the quality of Skylake's H.265 encoding versus something like Handbrake on "very slow"?

Against x265 slow no chance in current state.

Have there been any quality test for quicksync since sandy bridge?

Yes, but not more than 1-2 useful tests are available and these are based on Haswell. Personally I don't need Quicksync tests, I test it on my own.

 

[Deders]

So you definitely can't get the best quality with Quicksync as of yet?

 

[superstition]

x264 may be fatter but it works well.

The quality vs. filesize was terrible for H.264 in comparison with H.265 in my Handbrake tests. I'd rather encode even at medium in H.265 then use H.264.

As for the extreme slowness of the very slow setting (days) and the slow setting (8 hours) I don't see how it could be anything wrong on my end. The only setting I had beyond stock was detelecine. 17 quality, main profile, and no resizing.

Still a FX-8K CPU running at ~4GHz should be able to encode a DVD movie (720x576) at > 32fps with good settings (slow preset, CRF < 17). Using even slower presets or better motion search methods will slow it down, but no sane person would use them for a DVD movie anyway.

Regardless the settings, if encoding a DVD movie takes "days" then there is something very wrong going on.

I´ve never used Handbrake thou, as I find the combination of ffmpeg (libav) decoder and stand-alone x265 encode as a better combination.

I noticed a quality increase as well as a size reduction from using very slow vs. slow. The encoding time, though, was too much.

 

[superstition]

Against x265 slow no chance in current state.

Good to know. Thanks.

Are there enough jobs that you could split them up over multiple instances of Handbrake (until your processor is at/near full load)? If so that would make the overall process faster on your current hardware.

Good idea. I hadn't thought of that.

 

[lopri]

Are we talking about 480p here?

 

[mikk]

So you definitely can't get the best quality with Quicksync as of yet?

HEVC encoding with Quicksync is in early state, bitrate mode are still in development and many features are missing, one of the most important is Lookahead for example which worked great for h264. But even with so many missing features HEVC looks promising for Intel. In most cases I've tried better than H264 already, but sometimes it clearly suffers from the missing Lookahead.

 

[cytg111]

But.. I thought HEVC was like one of the killer features of skylake?

 

[mikk]

You have to explain more. No idea what you mean.

 

[LoveMachine]

But.. I thought HEVC was like one of the killer features of skylake?

For decode/playback, yes, Skylake is much better than previous generations. But encoding (turning a raw source into HEVC) is a whole different ballgame.