Detect and make hardware encoder default?

[vr8hub]

Is it possible to detect that a hardware encoder (e.g. vt_h264 on Mac) is available? If so, shouldn't it be the default encoder used, i.e. the one chosen if we just do "transcode-video somemovie.mkv"? IOW, if a hardware encoder is available, wouldn't it be better to have to override the command line to not use it rather than having to override to use it?

[vr8hub]

(Maybe this is better handled by a config file, which I believe is another issue already created here. But I would think a hardware encoder would be the best choice all the time. Of course, I don't know what I'm talking about, so that might be wrong :) )

[skj-dev]

In my case (iMac 5K late 2015), I find the software encoder does a better job. It's not a huge difference, but to my eye there's a little more color banding with the hardware encoder. I think part of the problem with defaulting to a hardware encoder is quality variation depending on the hardware.

Occasionally I still use the hardware encoder if I'm wanting a real fast encode for some reason. I have two aliases setup, tv and tvhw, where the latter gets passed the hardware encoder option, and the former doesn't (and now uses the --avbr option, which so far has been great).

Just my 2c. 😎

[lisamelton]

@vr8hub Thanks for filing this issue! It's a good question ripe for discussion. (Thanks @ttyS0 for already jumping in!)

But there are actually two parts to this issue:

1. Detecting which, if any, hardware video encoders are available.
2. Making a hardware video encoder the default instead of x264.

As (I think?) I mentioned in another issue, AFAIK, there's no way to detect which hardware video encoders are available other than parsing the --help text output from HandBrakeCLI. And that's not a robust solution. I did that stunt once to detect the default AAC audio encoder and I regret it.

But if anyone has a better idea on how to do this, I'm open to suggestion. (Or, better yet, a patch. :) )

OK, if we could detect what's available, then comes choosing. This presents two new problems:

1. Some platforms have more than one hardware video encoder available. And I don't mean just H.264 and HEVC variants. Which do you choose? Is Nvida hardware intrinsically better than Intel? Or vice versa? Have we done enough testing yet to make that call?
2. Many platforms don't have any hardware video encoder available. So we would have to stick with x264 and one of my ratecontrol systems. Which means significantly different behavior, both in terms of performance and quality, depending on which platform transcode-video is used.

Then there's the question of whether we should make a hardware video encoder the default. That involves an evaluation, again, about performance and quality.

In most cases, hardware is significantly faster than x264. But if you have a beefy multicore system, x264 can be just as fast or faster. And even if you don't have such a massive CPU configuration, using my --quick option for x264 can bring you much closer to parity. So hardware is not always a guaranteed win in terms of performance.

As to quality, after transcoding 730 movies and TV episodes from my own collection using the vt_h264 encoder, it's clear to me that while that encoder is much, much better than I expected, its results just aren't nearly as good as using x264 with any of my ratecontrol systems.

Color banding, which @ttyS0 mentioned, is a significant risk with the vt_h264 encoder. For example, passages from my Blu-ray rip of "Blade Runner 2049 (2017)" are almost unwatchable using it.

So, like @ttyS0, I'm sticking with my new --avbr option for x264. In fact, I'm more inclined to make that the default than any hardware video encoder. :)

I'll write more later after a trip.

[samhutchins]

To Don's point about systems with beefy CPUs: I have one such imbalanced system. My PC has an AMD Ryzen 1700X and an NVidia GTX 660. --abr --quick is faster for me than --encoder nvenc_h264, and higher quality too

[lisamelton]

@samhutchins Thanks! I couldn't remember the details of your system this morning so I'm glad you added that. :)

@vr8hub As to the issue of a config file to solve this problem for you, I don't think that's needed. Especially if you use a Unix-style shell like Bash or its kin. Just use the alias command. See:

https://en.wikipedia.org/wiki/Alias_%28command%29

And you can also create wrapper scripts for more complex configurations. Which is what I do. I must have 50 or more of these lying around. :) Just let me know, and I can write one for you.

[lisamelton]

@vr8hub BTW, I'm leaving this open to see if we get feedback from any of our other usual suspects around here. I'd be curious to hear not only thoughts about this feature but experiences with hardware encoders so far.

[khaosx]

I just finished a 30 movie test encode using a Quadro P2000 / nvenc to see what the state of encoding is, and after doing comparisons using my trusty Mk 1 eyeball, I'm not switching anytime in the near future. The speeds are amazing for both h265 and h264, but the quality suffers for it. I can't speak to Intel's HW, but for the foreseeable future, I'll be software encoding with --avbr --quick, and allowing the P2000 to handle transcoding in Plex.

[lisamelton]

@khaosx Thanks for the feedback! God willing Plex won't have to do any dynamic re-transcoding if you're already doing everything with --avbr --quick, which is exactly what I'm using now, too. (And I trust our Mk 1 eyeballs much more than PSNR comparisons. :) )

Also, what do you think about making --avbr the default ratecontrol system? Do you think it's good enough?

BTW, I'm testing a possible improvement to --avbr now. It's a subtle tweak of another internal x264 setting but it has the potential to further stabilize bitrate swings. If it pans out, I'll have a proposal up next week for you and our whole gang of nerds to try.

[khaosx]

@donmelton I assure you, Plex only transcodes for our mobile devices. Here in the bunker, it's all direct play :)

As far as making --avbr the default, I'm all for it. Based on what I've seen so far, I'm probably going to go back and re-encode all of the files I've done so far. I already had one thing I wanted to correct (let's just say you were right about lossless audio, and agree to never speak of it again), and the added difference in video quality is enough of a reason to go ahead and do it. So, yeah - I'm all for making it default.

[lisamelton]

@khaosx Having Plex use the hardware-based encoder for mobile devices is a great idea since the quality drop-off won't be nearly as noticeable on smaller screens. Clever!

And doesn't everyone re-transcode their entire video collection every month like I do? :)

The big question about making --avbr the default ratecontrol system is what should the behavior be if the user chooses the x265 encoder? Switch back to the special ratecontrol system? Or maybe constrained ABR with the --abr option? Hopefully @samhutchins can talk some sense into me about this.

[samhutchins]

@donmelton Doesn't --encoder x265 already do a slightly different thing to x264 when using the default ratecontrol system?

In any case, I'd think falling back to --abr makes more sense than falling back to the current default, because --abr has more in common with --avbr than the default (I think). Or perhaps we should all stick our heads in the sand and hope the problem goes away :-P

[lisamelton]

@samhutchins x265 used to do something different that x264 with the current default ratecontrol, but now they actually use the same options. Of course, those options are still not tuned for x265 which is why you're correct to recommend to others that they use --abr or --simple with x265.

And, yes, --abr has more in common than with --avbr since they're both based on the built-in ABR mode instead of CRF. More importantly, --abr with x265 doesn't have the same occasional hiccups that affect x264. So it's probably the best fallback.

But sticking our heads in the sand is an attractive option. :) I wonder how many or our users actually choose x265 as their encoder? I mean, even with your outrageous hardware, Sam, x265 is still probably slower than shit. I just don't see how x265 is a good choice for home transcoders.

[samhutchins]

@donmelton To be honest, I've never really used or tested x265. Trying it now on a Blu Ray rip and it's not realtime, averaging around 20fps. I have nothing that can play h.265 anyway

I suspect a surprising number of people use x265 for the space savings

Edit: and it seems like my box is nothing compared to what @khaosx has

[lisamelton]

@samhutchins I have nothing that can play HEVC either except my iMac and MacBook, so x265 is fairly useless to me.

Agree about the space savings as the big reason to use HEVC. That's exactly why the folks on a Slack channel I visit like it. But none of them use x265 anymore once I showed them how to access the hardware-based HEVC encoders. :)

Speaking of space savings, maybe we should consider shifting the default target bitrates lower if the user chooses a HEVC encoder?

Well, @khaosx may have better hardware than you, but both of you have better hardware than me. :)

[samhutchins]

@donmelton I think changing the default bitrates for HEVC would be a good idea, yeah. I think there's been a few issues opened here asking about why file sizes haven't changed when using x265 instead of x264

[khaosx]

@donmelton and @samhutchins It's the Quadro, I swear! Neither my server nor my Mac Pro can do x265 at a rate that doesn't make me want to perform acts of percussive maintenance. I see lots of people going on at great length on various forums about this debate, but from my own trials, I can only surmise that folks in favor of x265 either have a lot more patience than I do, or a lot more hardware. The space savings are significant, but the time costs and the client limitations are just awful.

Honestly, this is less of a stick our heads in the sand, and more of a "This is not what this tool excels at, at this time" situation. Don digs into this often enough that we're not going to be too surprised when h265 is viable, so why waste cycles on a solution that doesn't scratch the itch for 80% of folks (at this time)?

[samhutchins]

@khaosx Yeah, the speed of x265 is pretty damn painful. I'd rather spend a little extra on hard drives...

[lisamelton]

@samhutchins I'll open a proposal in the next week or so on new bitrate targets for HEVC then. I think making --target small the default for HEVC is the right starting point. At least that works really well with --abr and x265 or vt_h265 in my tests. We might want to wait on this if we really do decide to change the default ratecontrol for x264. Do it all at the same time.

@khaosx Yeah, the speed of x265 is just... cruel. And I haven't been able to come up with --quick implementation for it, although @vickash has taken a valiant crack at the problem in #238 to get the ball rolling.

I figure hard drives are cheap these days and storage on our mobile devices seems to double every 12 to 18 months. So HEVC is not essential for that reason.

The one advantage to HEVC is 10-bit encoders with high dynamic range (HDR) color. Dammit.

[khaosx]

@donmelton HDR is yummy, but since neither Plex nor Emby perform proper tonal mapping to down convert HDR to SDR, it's going to look like crap unless you direct play. Which requires a beefy client and good bandwidth, and hard burned subs. I have an nVidia Shield that will direct play pretty much anything, but that's the only box that will do it without me having to specifically target a platform. And even then, unless I burn subtitles into the video, the Shield becomes the only platform that won't trigger a transcode. Plex on AppleTV with subtitles is much better with the new player engine, but it's still buggy as hell.

That's the problem overall with x265. Every single solution has a gotcha - there's no solution with a direct path to success that doesn't involve retooling your whole chain from back-end to screen. I suspect that while @samhutchins is right about the number of people that use it for space savings, the Venn diagram of space misers and quality fiends isn't going to have a big convergence.

Meh, I'm rambling. My wife is in Brussels for two weeks and I'm minding the shop with all four kids so I may not be making a point here. I just don't think that x265 is a huge going concern for the majority of folks using the gem. I reserve the right to be incredibly wrong though.

[lisamelton]

@khaosx Oh, you're making a point all right! And making me LOL about it, too. :)

I suspect you're correct about that Venn diagram. It's a pity there's only one hardware encoder that does HEVC 10-bit HDR and it's only available on some platforms with direct access (as opposed to via VideoToolbox) to Intel Quick Sync Video. Dammit, again.

And you're definitely right about the current state of HEVC playback on various devices. This is why we can't have nice things. :)

[lisamelton]

@khaosx BTW, don't let the kids make you crazy for the next two weeks. Hide here online to maintain your sanity. :)

[klogg416]

I am late to this party, but think I can weigh in as someone who has dabbled, been patient, and abandoned x265 for the moment. The tl;dr is the new shiny is new and shiny, and there is a lot of appeal in improved quality for the same space requirements.

My desired goal of these scripts seems to vary from the more interactive community members as I am not really file size focused. I am trying to strike the best balance between size and quality. I rarely transcode audio, although I do rip to FLAC so I have options later. I often use --target big, and I often re-transcode smaller and stereo for iPad watching on planes, which is rare.

The promise of x265 is a decade of learning from x264 + a next generation codec. Their stated goal is better compression, and my ideal state is even closer to source for the current file size. More for the same, rather than the same for less. The transcode time is slow, painfully slow, but once I was confident that the quality out was good then it didn’t really matter, let it run and heat the basement until it completes.

However, as @donmelton has pointed out repeatedly, storage is cheap. With the encoder still immature and transcodes slow, I hit snooze on the new codec until performance improves. The quality solve for the few movies I want at maximum quality is a network share visible to kodi containing the original full fat rip. Plex and mobile devices only see a transcoded version. In time though I hope to be able to extract increasing quality from my ~6gb video files.

Also, it is fun to experiment and this is a better use of electricity than mining crypto. :-)

On Wed, Feb 13, 2019, at 3:50 PM, Don Melton wrote:

@khaosx https://github.com/khaosx BTW, don't let the kids make you crazy for the next two weeks. Hide here online to maintain your sanity. :)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/donmelton/video_transcoding/issues/253#issuecomment-463424118, or mute the thread https://github.com/notifications/unsubscribe-auth/AHAaMB8YfbgkO8VsN9gsQ1PplFoU1--Jks5vNKTNgaJpZM4a2aW4.

[lisamelton]

@klogg416 You really had me laughing out loud with that "mining crypto" comparison, Kyle. :)

So, have you been experimenting with hardware-based HEVC encoders?

My iMac can only do hardware-based H.264. Oddly, my MacBook has access to the HEVC version and it can encode at slightly faster than realtime. Still, it's a bit prone to color banding. But a much better solution to the sloth of x265 if you really want HEVC output.

BTW, I also like to watch my original rips via Kodi. I find Kodi handles them better than Plex since it won't ever surprise me by trying to dynamically transcode them.

[klogg416]

I have fiddled with hardware encode for years, and generally it was noticeably worse quality than software. The best summary I have heard for the diff between hw and sw is that the hardware is focused on real time or better speeds and will trade quality to achieve, software is focuses on quality. In that framing I am always trending software. Worse, the hardware based encoding is fixed in time, new improvements rarely can back port to old gear .

I have an Ivy Bridge i7, not a great vintage of QSV, a gen 1 Ryzen with good AVX but no GPU/ASIC encode block, and an RX 470 which includes the very decent VCE 3.4** engine. When you pushed the recent version with GPU support I definitely gave it a spin and it would fly along at about 70fps (!!!) for a while, let's call it 45-60 minutes of video time, then it would crater to less than 20fps for the duration. I couldn't see any indication of thermal throttling or physics based problems, spent a bunch of time testing, tracking, building an update to open an issue, but the culprit was almost certainly going to be Windows|AMD drivers|Some BS that isn't applicable to your sweet sweet macOS ecosystem. There aren't free PCIe slots in the i7 server to put the video card and test in Linux (see storage and HBAs are cheap). That's a long story to say, "I was excited, I tried it, weird problems I couldn't fix despite generous application of bourbon and google, and I wasn't confident that it was going to be better anyway."

Gave my head a shake and ran the Win equiv of rm -rf ~/wtf_hw_encode_test/* "Still prone to color banding" is the kind of sentence that keeps me favoring software and a world of constant improvements. I can't help but dabble, but the pull of the best quality is real.

**Bonus link for those following along with AMD GPUs, this page has a TON of great details about the VCE generations, features, and changes. Incredibly helpful if you are dabbling. https://github.com/obsproject/obs-amd-encoder/wiki/Hardware-Support

On Fri, Feb 15, 2019, at 10:52 AM, Don Melton wrote:

@klogg416 https://github.com/klogg416 You really had me laughing out loud with that "mining crypto" comparison, Kyle. :)

So, have you been experimenting with hardware-based HEVC encoders?

My iMac can only do hardware-based H.264. Oddly, my MacBook has access to the HEVC version and it can encode at slightly faster than realtime. Still, it's a prone to color banding. But a much better solution to the sloth of x265 if you really want HEVC output.

BTW, I also like to watch my original rips via Kodi. I find Kodi handles them better than Plex since it won't ever surprise me by trying to dynamically transcode them.

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

[klogg416]

Shoot, missed the secondary link. Notice on the right panel there is a little twistie that says "Pages 15," if you expand it there are detailed pages for each engine and a goldmine of technical info.

This is specific for my card, but there is an equivalent for each generation of VCE. https://github.com/obsproject/obs-amd-encoder/wiki/Hardware-VCE3.4

[lisamelton]

@klogg416 Yeah, that's a damn good summary of the differences.

One problem we have now, and a situation that will likely remain on macOS due to VideoToolbox, is that we don't have access to either the higher quality settings for those hardware encoders nor their alternate ratecontrol systems. Right now it's a one-flavor selection, likely ABR at a medium setting. Which explains the color banding. And that's not helping my appetite.

You have an interesting set of hardware, sir! Don't be surprised if I ping you to do some specific testing on at least one of those boxes sometime. :)

And, ack! That driver situation sounds awful. Although wouldn't it be something if you could solve problems like that with bourbon and Google. :) Just my way of saying that I admire your phrasing, sir!

And thanks for the links! If I ever do get around to creating us a Wiki, those would be handy to add to it.

[klogg416]

@donmelton Frustrating to hear that VideoToolbox abstracts the interaction model and hides some of options, I hadn’t known that. My understanding is that GPU drivers (ignoring the open versus blob challenges) on Linux are hit and miss for functionality too, hardware encode support might be a bridge too far if this project is to remain cross platform.

My hardware is at your disposal for experimentation and testing, as is the flavour of OS running on it so long as VMs are an option. Happy to help!

The roll-you-own-driver model has been the gift and the curse of Windows since the beginning. Everything is on the table, but you need to rely on component manufacturers to be good at drivers. I’ll never know what secret blackmail meterial Apple has over Intel to trust them to support their iGPUs, but experience shows that Microsoft’s dirt isn’t as compelling. 😬

[lisamelton]

@klogg416 Yeah, most of the options are hidden for all the hardware encoders with HandBrake and FFmpeg except direct Intel QSV on certain Windows (and possibly Linux?) configurations.

[klogg416]

@donmelton I was thinking about this last night and cranked through 6 iterations leveraging --encoder vce_h264 this morning. I don't know what specifically, but something in the mix of options transcode-video leverages basically breaks the speed gain from VCE 3.4 hardware encoding. See the fps and utilization differences between t-v and GUI output.

If it is interesting I can breakdown the commands fed to hbCLI and see specifically what causes the slowdown, but I am not sure it is relevant beyond knowing that my specific GPU isn't worth leveraging in 264 mode.

Method, options	avg fps	GPU Utilization	file size
t-v --encoder vce_h264 --avbr --target big	13.81	typically 12%, frequent spikes to 32%	526M
t-v --encoder vce_h264 --avbr	14.02	typically 12%, frequent spikes to 32%	398M
t-v --encoder vce_h264	13.34	typically 12%, frequent spikes to 32%	398M
t-v --simple --encoder vce_h264	15.94	typically 12%, frequent spikes to 32%	398M
GUI - profile: high	70.7	~86%	1.2G
GUI - profile: main	69.9	80-86%	1.2G
t-v --simple --encoder vce_h265	20.23	8-18%	528M
GUI - profile: main vce_h265	70.3	60-63%	1.1G

Edit: +2 vce_h265 options. Same story as vce_h264.

[lisamelton]

@klogg416 Thanks for doing all this testing! You rock, sir.

Just so you know, adding --avbr or --simple (or --abr) to any command line specifying a hardware encoder, e.g. --encoder vce_h264, has no effect at all. That's because my ratecontrol systems are not compatible with hardware encoders. (Although I certainly wish they were!)

But there is definitely something weird going on here. Probably with HandBrakeCLI itself. I don't see any variation like this on either of my Macs using vt_h264.

Have you tried just invoking HandBrakeCLI directly? Bypassing transcode-video completely?

[lisamelton]

@klogg416 BTW, I have seen performance variance using the vt_h264 hardware encoder, but not nearly by the amount you're seeing.

Usually that variance is no more than 10% and is heavily influenced by the speed of network I/O (because my original rips are accessed via Ethernet) and, to certain extent, the current load my CPU is under.

I've also noticed that the video format of my original rips has a huge impact on performance, no doubt because the baseline speed of the hardware encoder is so damn fast and video decoding is still done in software.

So, MPEG-2 sources are fastest, followed closely by H.264 sources, and VC-1 sources are almost twice as slow. This is another reason I hate VC-1 format. :)

[klogg416]

@donmelton Good to know that the quality variables are disregarded with vce_h264/5, that explains the file size consistency, while also providing a nice data point around how consistent the encoding fps is.

CPU consumption was single digit percentages, wasn't doing anything but watching the the CPU and GPU usage graphs while it worked through the sample files.

I hadn't factored in source format (VC-1) and video decode time, but at least in the above examples of variability it is all 1:1 with the same source file. I encode locally for this trying to remove bottle necks, 6tb spinner as source and a fancy NVMe 4x drive for output.

I just did a --dry-run of

transcode-video --dry-run --prefer-ac3 --encoder vce_h264 --chapters 2 "E:\video_raw\work\Galapagos (2006) BR\S01E01 Born of Fire.mkv" -o "S01E01_hbCLI_vce264.mkv"

which, after I cleaned up the folders and escape characters, converted to:

HandBrakeCLI --input="E:\video_raw\work\Galapagos (2006) BR\S01E01 Born of Fire.mkv" --output="C:\video_raw\vce_h264 test\S01E01_hbCLI_vce264.mkv" --markers --encoder=vce_h264 --crop=0:0:0:0 --auto-anamorphic --deinterlace --vb=6000 --audio=1 --aencoder=copy --chapters=2

Annoyingly, it worked! Here are the two comparison records:

Method, options	avg fps	GPU Utilization	file size
hbCLI --prefer-ac3 --encoder vce_h264	67.29	70-82%	416M
t-v --prefer-ac3 --encoder vce_h264	68.11	70-82%	416M

I reran a random one from this morning (transcode-video --simple --encoder vce_h264 --chapters 2 "E:\video_raw\work\Galapagos (2006) BR\S01E01 Born of Fire.mkv" -o "S01E01_tv_pm_vce264.mkv") and it is also cranking at 65+ fps now, no changes, not even a reboot. Basically the same stats as above, 70-80% util, etc.

Well, 1 change I suppose, I have a 3 year old sitting on me trying desperately to play "typing" and a terrible youtube video playing in the corner of nursery rhymes. Is "grabby toddler" the hardware encoding catalyst I need, regardless of what I deserve? This variability of "now it works, now it doesn't" is what lead to me taking the last data set and deleting it, skip the recycle bin thanks. Who knows, very weird. :-)

[lisamelton]

@klogg416 I would keep the kid on my lap then. :)

Go figure. I've had crap like this happen to me sometimes, too. How do these computers even work? Yes, I know, magnets.

[klogg416]

@donmelton Mine only use the finest crystals and pyramids. And top. men. #DisconnectedIncomparableReference

The vce_h265 is going faster too. The only think approaching a pattern that I see is it often works as expected in the terminal after leveraging hardware encode in the GUI version of HB. Maybe I have an initialization problem with the drivers or libraries. A problem for another day. Did I mention that I like the ever increasing quality of software encoding?

Top men.

[samhutchins]

One thing to bear in mind about hardware encoding with HandBrake is that a lot of the processing is still done on the CPU. I believe it's things like scaling, filtering, and possibly subtitle rendering.

[lisamelton]

@klogg416 I think you might be on to something with your "initialization problem" theory, i.e. some weird situation where you have to run the GUI app first. But scanning through the list of open HandBrake bugs, I don't see anything addressing this. Did you try checking online to see if anyone else was having this problem?

[lisamelton]

@vr8hub Just so you know, I am still seriously considering this proposal. Partly because it looks like the HandBrake team is vigorously pursuing even more hardware-based encoder support. The way they're going, they might even make it the default behavior.

Also, I think detection by parsing the --help output of HandBrakeCLI won't be as heinous as I originally thought.

The big question is what should the fallback behavior be when I can't detect a hardware-based encoder? Obviously using x264, but which ratecontrol system? I think --avbr and abr are much better candidates than the current default.

And I'll "cc" @samhutchins and @klogg416 to get their feedback on this reconsideration.

[lisamelton]

@vr8hub @samhutchins @klogg416 Here's a working patch which implements detection and setting the default encoder. However, it doesn't change the fallback ratecontrol system:

diff --git a/bin/transcode-video b/bin/transcode-video
index 6b19b18..abcda9e 100755
--- a/bin/transcode-video
+++ b/bin/transcode-video
@@ -863,7 +863,7 @@ HERE
         'input' => arg,
         'output' => resolve_output(media),
         'markers' => nil,
-        'encoder' => 'x264'
+        'encoder' => HandBrake.video_encoder
       }
       title = media.info[:title]
       handbrake_options['title'] = title.to_s unless title == 1
@@ -1000,7 +1000,7 @@ HERE
         bitrate = @target_bitrate
       end

-      encoder = @handbrake_options.fetch('encoder', 'x264')
+      encoder = @handbrake_options.fetch('encoder', handbrake_options['encoder'])

       if encoder =~ /_h26[45]$/ and not @handbrake_options.has_key? 'quality'
         handbrake_options['vb'] = bitrate.to_s
diff --git a/lib/video_transcoding/handbrake.rb b/lib/video_transcoding/handbrake.rb
index 9ea2a93..718e5c9 100644
--- a/lib/video_transcoding/handbrake.rb
+++ b/lib/video_transcoding/handbrake.rb
@@ -27,6 +27,23 @@ module VideoTranscoding
       Tool.use(COMMAND_NAME)
     end

+    def video_encoder
+      properties = Tool.properties(COMMAND_NAME)
+
+      unless properties.has_key? :video_encoder
+        if  help_text =~ /vt_h264/ or
+            help_text =~ /qsv_h264/ or
+            help_text =~ /nvenc_h264/ or
+            help_text =~ /vce_h264/
+          properties[:video_encoder] = $MATCH
+        else
+          properties[:video_encoder] = 'x264'
+        end
+      end
+
+      properties[:video_encoder]
+    end
+
     def aac_encoder
       properties = Tool.properties(COMMAND_NAME)

As you can see, the code tests for specific hardware encoders in a particular order and returns the first one in that order it can find.

[vr8hub]

@donmelton Hah, well, remember, this was a request from ignorance. :)

Given there's a proposal on the table to change the ratecontrol default to --avbr, I think it makes sense for that to be the fallback.

And the hardware encoder should probably only be the default if it provides as good or better output than --avbr, right?

[lisamelton]

@vr8hub Agreed on the fallback. Unfortunately, the hardware encoder doesn't provide good or better output than --avbr. Which is the problem with proceeding here.

[gingerbeardman]

I just found out about this, and my rMBP has vt_h264 which could have saved me... I don't want to think how long. 😢

For most of my use cases I'd happily trade size for speed. It would have been great if I'd have been notified by the system when I started using these tools that I could have saved so much time.

I'm seeing a difference of minutes rather than hours (10min vs 70min), hundreds/fps rather than tens/fps (250+ vs ~50). Amazing.

Thanks to all involved! Great work.