Are there any downsides to using a hardware encoder?

[damorrison]

Hi,

This isn't an issue, more a question.

I've been experimenting with the hardware encoding options without really knowing what the benefits and downsides might be. Other than a much greater speed boost, the only real difference I see is a slightly larger output file than if I'd used software to do the transcode.

So my ignorant question is, what does the hardware encoder do to your carefully considered encoding parameters? Does it honour them all, (in which case why is the file size larger), or does it throw some of them away and then makes its own decisions?

PS: I just installed a new NVidia 1070 graphics card with the nvenc-h264/h265 hardware encoders, and I get close on 225 fps out of it doing software-based h264 (Intel i5), and 1150 fps using hardware hs64! On hardware h265, it's around 700 fps! (source is only 854x480 though). Amazing speed boosts.

Lastly, when looking at the GPU performance when transcoding, it shows that the GPU is doing the transcode, but not the decode - are you aware of a way to make handbrake-cli do that too? (On Windows, inside Task Manager, it shows two separate graphs for encoding and decoding).

[samhutchins]

The quality of the transcode will be different, and in some cases worse. @donmelton will be able to give good example of when it's worse.

When using hardware encoders, none of Don's ratecontrol systems are used. They're specifically for x264. Hardware encoders tend not to have many knobs to tweak, and most are an ABR system that targets the given bitrate. They also tend to have 2 or 3 quality or speed profiles. Intel QuickSync also has a constant quality mode, similar to crf in x264. Again, I suspect Don will be able to give a lot more information on how to use that

I believe HandBrake can use Intel QuickSync for decode using --enable-qsv-decoding. To use that with transcode-video you'd need to add -H enable-qsv-decoding, but I'm not aware of a way to make Handbrake use nvenc for decode

[khaosx]

@damorrison We've all played around with this one at some point, to varying degrees of success. I went back and looked at some recent conversations and the phrase "prone to color banding" seems to crop up a number of times.

The speeds are absolutely fantastic and I am constantly tempted to bring it to bear on my library but, for me, the quality tradeoff is unacceptable. I see artifacting and banding constantly, especially with high-gain scenes (my personal favorite is the opening chapter to the first Guardians of the Galaxy. The scene where a young Starlord drops to his knees in a field at night, and then is illuminated by Yandu's starship is a good test case.

Are you running this on Linux? I know that a lot of tools have trouble right now with nvdec on Linux. ffmpeg just recently got upgraded to use the decoder. Plex cannot without a bunch of work arounds, and I think handbrake is in the same boat.

Also, on Windows, I know there is some sort of voodoo going on where you're locked to a certain number of things happening on nVidia hardware at the same time, at least on consumer cards. I don't run my media environment on Windows, so I haven't paid close attention to it, but it's worth looking into.

[khaosx]

@damorrison We talk about hardware encoding a lot in #253. You might pick up some tidbits there.

[lisamelton]

@damorrison I think the always-helpful @samhutchins and @khaosx (thanks, guys!) have already answered all your questions thoroughly, but I'll toss in my two cents now that I've almost finished my morning coffee... :)

I've been experimenting with the hardware encoding options without really knowing what the benefits and downsides might be. Other than a much greater speed boost, the only real difference I see is a slightly larger output file than if I'd used software to do the transcode.

Using hardware-based encoders for transcoding provides two main benefits, the first of which you've already discovered. That benefit being much faster performance compared to software-based encoders like x264 and especially x265.

The second benefit is consistency of quality. That's not to imply high quality, just that it's consistent. :)

For most inputs, the output from hardware-based encoders looks perfectly acceptable. However, these encoders are unfortunately prone to color banding when transcoding some gradients and to blockiness when transcoding some high-noise inputs.

Examples of the color banding problem can be seen throughout a transcoding of the Blu-ray rip of "Blade Runner 2049 (2017)" and the beginning of "Guardians of the Galaxy (2014)."

Examples of the blockiness problem can be seen throughout a transcoding of the Blu-ray rip of "Saving Private Ryan (1998)" and "Aliens (1986)."

So my ignorant question is, what does the hardware encoder do to your carefully considered encoding parameters? Does it honour them all, (in which case why is the file size larger), or does it throw some of them away and then makes its own decisions?

As Sam explained, hardware-based encoders ignore my ratecontrol systems and only honor the target bitrate.

The hardware-based encoders have their own ratecontrol systems with the default being an ABR system similar in behavior to my own --abr option.

And for all the hardware-based encoders except those with names prefixed by "qsv_" available on some Windows and Linux platforms, the default ratecontrol system is all you can access. And that default is not configurable either, other than to change the target bitrate.

PS: I just installed a new NVidia 1070 graphics card with the nvenc-h264/h265 hardware encoders, and I get close on 225 fps out of it doing software-based h264 (Intel i5), and 1150 fps using hardware hs64! On hardware h265, it's around 700 fps! (source is only 854x480 though). Amazing speed boosts.

Congratulations! That speed is certainly enticing. :) And you should consider re-doing your entire collections with it and just go back to one of my software-based ratecontrol systems when you don't like the results.

Lastly, when looking at the GPU performance when transcoding, it shows that the GPU is doing the transcode, but not the decode - are you aware of a way to make handbrake-cli do that too? (On Windows, inside Task Manager, it shows two separate graphs for encoding and decoding).

As Sam mentioned, your can use the --enable-qsv-decoding option. But keep in mind that it's only available on some Windows and Linux platforms.

OK, if we answered your questions sufficiently, can we close this issue?

[damorrison]

Yes please close that’s good information

I guess my main question was does it do the don thing or its own thing, and as it does it’s own thing it’s not for me

I did see a huge banding issue in one of the h265 transcodes i tried earlier in the first 10-15 seconds too. So non!

On Fri, 8 Mar 2019 at 17:10, Don Melton notifications@github.com wrote:

@damorrison https://github.com/damorrison I think the always-helpful @samhutchins https://github.com/samhutchins and @khaosx https://github.com/khaosx (thanks, guys!) have already answered all your questions thoroughly, but I'll toss in my two cents now that I've almost finished my morning coffee... :)

I've been experimenting with the hardware encoding options without really knowing what the benefits and downsides might be. Other than a much greater speed boost, the only real difference I see is a slightly larger output file than if I'd used software to do the transcode.

Using hardware-based encoders for transcoding provides two main benefits, the first of which you've already discovered. That benefit being much faster performance compared to software-based encoders like x264 and especially x265.

The second benefit is consistency of quality. That's not to imply high quality, just that it's consistent. :)

For most inputs, the output from hardware-based encoders looks perfectly acceptable. However, these encoders are unfortunately prone to color banding when transcoding some gradients and to blockiness when transcoding some high-noise inputs.

Examples of the color banding problem can be seen throughout a transcoding of the Blu-ray rip of "Blade Runner 2049 (2017)" and the beginning of "Guardians of the Galaxy (2014)."

Examples of the blockiness problem can be seen throughout a transcoding of the Blu-ray rip of "Saving Private Ryan (1998)" and "Aliens (1986)."

So my ignorant question is, what does the hardware encoder do to your carefully considered encoding parameters? Does it honour them all, (in which case why is the file size larger), or does it throw some of them away and then makes its own decisions?

As Sam explained, hardware-based encoders ignore my ratecontrol systems and only honor the target bitrate.

The hardware-based encoders have their own ratecontrol systems with the default being an ABR system similar in behavior to my own --abr option.

And for all the hardware-based encoders except those with names prefixed by "qsv_" available on some Windows and Linux platforms, the default ratecontrol system is all you can access. And that default is not configurable either, other than to change the target bitrate.

PS: I just installed a new NVidia 1070 graphics card with the nvenc-h264/h265 hardware encoders, and I get close on 225 fps out of it doing software-based h264 (Intel i5), and 1150 fps using hardware hs64! On hardware h265, it's around 700 fps! (source is only 854x480 though). Amazing speed boosts.

Congratulations! That speed is certainly enticing. :) And you should consider re-doing your entire collections with it and just go back to one of my software-based ratecontrol systems when you don't like the results.

Lastly, when looking at the GPU performance when transcoding, it shows that the GPU is doing the transcode, but not the decode - are you aware of a way to make handbrake-cli do that too? (On Windows, inside Task Manager, it shows two separate graphs for encoding and decoding).

As Sam mentioned, your can use the --enable-qsv-decoding option. But keep in mind that it's only available on some Windows and Linux platforms.

OK, if we answered your questions sufficiently, can we close this issue?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/donmelton/video_transcoding/issues/269#issuecomment-471003518, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYJDZCYPPKTPVELTAHlX7c0tktACuutks5vUplxgaJpZM4bla0e .

-- Kind regards, Dave

[lisamelton]

@damorrison Yeah, the color banding problem is a deal breaker for most of us.