How to make sure that encoding uses GPU

HandBrake for Windows support
Forum rules
An Activity Log is required for support requests. Please read How-to get an activity log? for details on how and why this should be provided.
Number8
Novice
Posts: 64
Joined: Fri Dec 26, 2014 11:46 am

How to make sure that encoding uses GPU

Post by Number8 »

I'd like to know if Handbrake uses the GPU of the video card?
Windows 10 x64 - NVidia GeForce 950 - Handbrake 10.2.7286

Thank you
Nicolas
Woodstock
Veteran User
Posts: 4619
Joined: Tue Aug 27, 2013 6:39 am

Re: How to make sure that encoding uses GPU

Post by Woodstock »

If it isn't an Intel chipset with QSV, the GPU isn't going to be used for much in any case.

For QSV, you have to make sure your video drivers are up-to-date, and some systems must have a monitor plugged into the video port before the hardware is activated.
Number8
Novice
Posts: 64
Joined: Fri Dec 26, 2014 11:46 am

Re: How to make sure that encoding uses GPU

Post by Number8 »

Well this is what I was guessing, because after installing the video card, the QSV option disppeared. If there a way, to restore the QSV option with te video card installed?
Woodstock
Veteran User
Posts: 4619
Joined: Tue Aug 27, 2013 6:39 am

Re: How to make sure that encoding uses GPU

Post by Woodstock »

Try plugging a monitor in. The default in Windows is to not activate the QSV hardware without it being attached to something. There are ways to bypass that in Win7, but they don't work so well in Win10. Mine is plugged into a second monitor, because I needed the ATI card to talk to the 4K display.

It also helps to have the latest Intel display drivers for your hardware. Microsoft Windows Update will NOT offer to update them for you; you have to go to Intel and download/install them.

Be prepared for the reality that the blazing speed of QSV is paid for in larger file sizes. For my use, I stopped using QSV, because I'd rather have the 10% better compression and better quality of the software-only encode. I may someday decide to use the QSV hardware for "on the fly" transcoding as part of a video server, but not for day-to-day encoding.
Number8
Novice
Posts: 64
Joined: Fri Dec 26, 2014 11:46 am

Re: How to make sure that encoding uses GPU

Post by Number8 »

This is exactly my situation. I need the NVidia card to talk 4K to the projector. I wasn't aware that QSV is at the cost of image quality which is something I will not trade-off.
When you say Try plugging a monitor in, do you mean to the Mobo HDMI output or to the video card HDMI output? I currently have a monitor plugged to the video card. I seems that when the video card is installed the MOBO HDMI output is deactivated.
Be prepared for the reality that the blazing speed of QSV is paid for in larger file sizes
Do you mean that for larger file size the benefit of QSV decreases?

Intel drivers: in my case there is no Intel GPU, I'm running the latest Skylake processor with Z170 chipset. So, correct me if I'm wrong, there is no need for Intel drivers.
mduell
Veteran User
Posts: 8198
Joined: Sat Apr 21, 2007 8:54 pm

Re: How to make sure that encoding uses GPU

Post by mduell »

QSV isn't doesn't produce encodes with the efficiency that x264 can achieve. So you end up with larger files for the same quality.

If you want to use the GPU on your Skylake processor for video encoding, you need to install the Intel drivers.
Number8
Novice
Posts: 64
Joined: Fri Dec 26, 2014 11:46 am

Re: How to make sure that encoding uses GPU

Post by Number8 »

I made the update thanks for the tip. I did have a driver installed dated July, a recent beta release was available on Intel site.
Is H265 the codec to be used now, especially for BR?
Woodstock
Veteran User
Posts: 4619
Joined: Tue Aug 27, 2013 6:39 am

Re: How to make sure that encoding uses GPU

Post by Woodstock »

Some sort of monitor (or "monitor-like appliance") needs to be plugged into the motherboard video. Windows will then see the monitor, and turn the QSV hardware on. Companies sell plugs that fake a monitor's signals for stupid requirements like this.

The QSV-capable processors have the video circuitry on-chip - the motherboard simply provides an interface to it. It just has to be activated.

QSV is designed for speed, which makes it great when you need speed over size. Think things like video conferencing in real time, or recoding video for playback on remote devices at real-time speed. While it can achieve the same quality of output as the x264 software encoder, the file size is 5-10% larger. Sometimes more.

h265 encoding is relatively new to QSV. To make it work with Skylake, you'll need one of the latest "nightly builds".
Number8
Novice
Posts: 64
Joined: Fri Dec 26, 2014 11:46 am

Re: How to make sure that encoding uses GPU

Post by Number8 »

OK. But I was Under the impression that video card GPU would much faster than the Embedded GPU. So do you confirm that at this stage the video card GPU will not be used? Thank you
Woodstock
Veteran User
Posts: 4619
Joined: Tue Aug 27, 2013 6:39 am

Re: How to make sure that encoding uses GPU

Post by Woodstock »

If you're referring to the GPU on the nVidia card, it is not significantly faster than using the CPU. Others have said that enabling the GPU can help somewhat on scaling the video, but not encoding it after the scaling.

QSV is a special case. It isn't really using the GPU, it's using specialized-to-video-encoding hardware. It is amazingly fast... I've seen over 200 frames per second on 1080p video (CPU hovers around 25-30). But the trade-off in file size isn't viable for my usage, and I can queue up batch jobs to run for days if I need to, since I use MakeMKV to do the physical disk ripping.
gmb
Bright Spark User
Posts: 350
Joined: Thu Mar 28, 2013 12:49 pm

Re: How to make sure that encoding uses GPU

Post by gmb »

Woodstock wrote:If you're referring to the GPU on the nVidia card, it is not significantly faster than using the CPU.

It is much faster if you are using a Maxwell GPU and encoding software with NVENC support.
User avatar
s55
HandBrake Team
Posts: 10357
Joined: Sun Dec 24, 2006 1:05 pm

Re: How to make sure that encoding uses GPU

Post by s55 »

Just to clarify for people.

QuickSync, although it's on the same die, it's actually a dedicated ASIC. That means the GPU performance isn't relevant to the encode performance. AMD has VCE and Nvidia has NVENC. Both also have dedicated hardware.

So, everyone has moved on from GPU encoding now as it was a bust. We are now dealing with dedicated hardware encode / decode engines on chip. While these are getting pretty good these days, they are still not beating out x264 for file size and quality.

My opinion is that you want to encode x264 using as slow as a preset as you can tolerate (on the video tab) for archival content, and throw away content that you don't care as much about, QuickSync is probably a better choice.

Also note, x264 has a wide range on the encoding speed spectrum. At two extremes on my Intel 4770K, I've had it running at <1fps all the way up to just over 2000fps. (yes, two thousand but obviously massive penalties for doing that.).
gmb
Bright Spark User
Posts: 350
Joined: Thu Mar 28, 2013 12:49 pm

Re: How to make sure that encoding uses GPU

Post by gmb »

s55 wrote: Also note, x264 has a wide range on the encoding speed spectrum. At two extremes on my Intel 4770K, I've had it running at <1fps all the way up to just over 2000fps. (yes, two thousand but obviously massive penalties for doing that.).

On very fast x264 presets quality is worse than Quicksync.
User avatar
s55
HandBrake Team
Posts: 10357
Joined: Sun Dec 24, 2006 1:05 pm

Re: How to make sure that encoding uses GPU

Post by s55 »

Very Fast is where I typically find it tips one way or the other, but that wasn't the point. The point was there is a huge range in there from terrible to insane. QuickSync's range sits in the middle which makes a lot of sense given it's more consumer grade.
Number8
Novice
Posts: 64
Joined: Fri Dec 26, 2014 11:46 am

Re: How to make sure that encoding uses GPU

Post by Number8 »

This is a very interesting discussion, and I guess it comes regularly on the board. But I'm still puzzled. NVidia GPU features a dedicated piece of hardware aiming at H264/265 encoding/decoding. So the real question, does this piece of hardware provide the same level of quality and range of encoding spectrum? Is it able to provide the same quality level if needed? And is it faster than the embedded Skylake GPU?
gmb
Bright Spark User
Posts: 350
Joined: Thu Mar 28, 2013 12:49 pm

Re: How to make sure that encoding uses GPU

Post by gmb »

NVENC Encoding spectrum is more limited than Quicksync, for example there are no Target level options or something similar. To answer your question, no it can't match x264 encoding spectrum.

Encoding speed of my GTX 970 with NVENC 5.x isn't much different to my SKL GT2 @6700k h264, although I think with fastest Quicksync settings like TU7, 2 reference frames, Lookahead off speed of Quicksync should be higher.
mduell
Veteran User
Posts: 8198
Joined: Sat Apr 21, 2007 8:54 pm

Re: How to make sure that encoding uses GPU

Post by mduell »

Number8 wrote:This is a very interesting discussion, and I guess it comes regularly on the board. But I'm still puzzled. NVidia GPU features a dedicated piece of hardware aiming at H264/265 encoding/decoding. So the real question, does this piece of hardware provide the same level of quality and range of encoding spectrum? Is it able to provide the same quality level if needed? And is it faster than the embedded Skylake GPU?
It's too little too late, Intel was first to provide a workable solution and nV/AMD haven't even caught up yet alone provided a compelling reason to adopt.
Deleted User 11865

Re: How to make sure that encoding uses GPU

Post by Deleted User 11865 »

Who knows what VCE and NVENC will provide in the future, nothing is ever set in stone. But it does seem like QSV is currently the most versatile solution.

For now, HandBrake only supports Quick Sync Video, though we're of course open to supporting VCE and NVENC in the future (it would seem NVIDIA finally fixed some licensing issues with their latest SDK, BTW).

Another advantage of hardware-based solution that most people seem to overlook, is that it's more energy-efficient than CPU-based encoding (or than GPGPU-based encoding, for that matter). This is even more pronounced when everything is done via the GPU/ASIC (hardware-accelerated decoding, scaling, filtering and encoding) - where a factor of 10 times more efficient isn't unrealistic at all.
Number8
Novice
Posts: 64
Joined: Fri Dec 26, 2014 11:46 am

Re: How to make sure that encoding uses GPU

Post by Number8 »

Another advantage of hardware-based solution that most people seem to overlook, is that it's more energy-efficient than CPU-based encoding (or than GPGPU-based encoding, for that matter). This is even more pronounced when everything is done via the GPU/ASIC (hardware-accelerated decoding, scaling, filtering and encoding) - where a factor of 10 times more efficient isn't unrealistic at all.
This is indeed a very interesting comment. I do confirm there is quite a bit of heat generated during the encoding process. And I would'nt be surprised that the conversion process could be faster especially with the need to encode BR in H265. It would be nice to see Handbrake making that move if it is confirmed there is a real advantage.
I haven't made any tests with other solutions that claims to support Maxwell GPU. I may do some test in the future and I'll report results.
AlmightyFireFly
Posts: 3
Joined: Sun Mar 06, 2016 9:17 pm

Re: How to make sure that encoding uses GPU

Post by AlmightyFireFly »

I would just like to clarify for those who do not know. Both intel quick sync and NVidia nvenc use the same thirdparty encoding core. A technology bought from some one else. I currently own an intel i5 system with hd2000 integrated graphics and NVidia gtx 750 ti. Encoding using quick sync is faster than just basic x264, but still only 30fps. I felt that the quality was very good and couldn't tell the difference using the high profile preset on medium with deinterlacing and decombing turned off and preset on medium, tune on auto and level on 4.1. But in an effort to use the encoding built into my gtx 750, which handbrake currently has no support for, I tried a program called staxrip. Using staxrip with as close of settings as I can, I was able to achieve 110-150 fps. Which is way faster and still produces good video quality, but isn't completely comparable, because staxrip needs to compile and index before encoding which takes 10-20 min. But staxrip is no handbrake, and I would rather use handbrake. It is much simpler. My question is if handbrake will support nvenc anytime soon? It would make my process just a bit simpler.
Deleted User 11865

Re: How to make sure that encoding uses GPU

Post by Deleted User 11865 »

Encoding with QSV, even on Sandy Bridge hardware, should be a lot faster than that. Can you provide a log for your 30 fps encode?

I suspect the video decoder is the bottleneck in this case, though there's always "that other explanation we didn't think of", so we really need to see an encode log please.
AlmightyFireFly
Posts: 3
Joined: Sun Mar 06, 2016 9:17 pm

Re: How to make sure that encoding uses GPU

Post by AlmightyFireFly »

Here is what I have for the Intern. Note that is uses the full 1080 frame. So it will be a little slower, but it was about 24 fps if I remember right.

Code: Select all

HandBrake 0.10.5.0 - 64bit Version
OS: Microsoft Windows NT 6.2.9200.0 - 64bit
CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz
Ram: 16272 MB, 
GPU Information:
  Intel(R) HD Graphics - 9.17.10.4229
  AMD Radeon HD 7450 - 15.200.1045.0
Screen: 1296x769
Temp Dir: C:\Users\shear\AppData\Local\Temp\
Install Dir: C:\Program Files\Handbrake
Data Dir: C:\Users\shear\AppData\Roaming\HandBrake Team\HandBrake\0.10.5.0

-------------------------------------------

CLI Query:  -i "D:\video\backup\THE_INTERN" -t 20 --angle 1 -c 1-14 -o "C:\Users\shear\Videos\TheIntern.mp4"  -f mp4  -w 1918 --crop 0:0:2:0 --loose-anamorphic  --modulus 2 -e x264 -q 20 --cfr -a 1 -E copy:ac3 -6 none -R Auto -B 0 -D 0 --gain 0 --audio-fallback ac3 --subtitle scan --subtitle-forced=1 --markers="C:\Users\shear\AppData\Local\Temp\TheIntern-20-chapters.csv" --encoder-level="4.1"  --encoder-profile=high  --verbose=1

[23:43:50] hb_init: starting libhb thread
HandBrake 0.10.5 (2016021100) - MinGW x86_64 - https://handbrake.fr
4 CPUs detected
Opening D:\video\backup\THE_INTERN...
[23:43:50] CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz
[23:43:50]  - Intel microarchitecture Sandy Bridge
[23:43:50]  - logical processor count: 4
[23:43:50] OpenCL device #1: Advanced Micro Devices, Inc. Caicos
[23:43:50]  - OpenCL version: 1.2 AMD-APP (1800.5)
[23:43:50]  - driver version: 1800.5 (VM)
[23:43:50]  - device type:    GPU
[23:43:50]  - supported:      YES
[23:43:50] Intel Quick Sync Video support: yes
[23:43:50]  - Intel Media SDK hardware: API 1.4 (minimum: 1.3)
[23:43:50]  - H.264 encoder: yes
[23:43:50]     - preferred implementation: hardware (any)
[23:43:50]  - H.265 encoder: no
[23:43:50] hb_scan: path=D:\video\backup\THE_INTERN, title_index=20
[23:43:50] scan: BD has 23 title(s)
[23:43:50] bd: scanning title 20
[23:43:50] bd: playlist 00100.MPLS
[23:43:50] bd: duration is 02:01:31 (7291951 ms)
[23:43:50] bd: video id=0x1011, stream type=H.264, format 1080p
[23:43:50] bd: aspect = 1.77778
[23:43:50] bd: audio id=0x711100, lang=English (DTS), 3cc=eng
[23:43:50] bd: audio id=0x1100, lang=English (DTS-HD MA), 3cc=eng
[23:43:50] bd: audio id=0x1101, lang=English (AC3), 3cc=eng
[23:43:50] bd: audio id=0x1102, lang=Francais (AC3), 3cc=fra
[23:43:50] bd: audio id=0x1103, lang=Espanol (AC3), 3cc=spa
[23:43:50] bd: subtitle id=0x1200, lang=English, 3cc=eng
[23:43:50] bd: subtitle id=0x1201, lang=Francais, 3cc=fra
[23:43:50] bd: subtitle id=0x1202, lang=Espanol, 3cc=spa
[23:43:50] bd: chap 1 packet=768, 571153 ms
[23:43:50] bd: chap 2 packet=2043446784, 624206 ms
[23:43:50] bd: chap 3 packet=4320617856, 634592 ms
[23:43:50] bd: chap 4 packet=6650786880, 648481 ms
[23:43:50] bd: chap 5 packet=9050568768, 540248 ms
[23:43:50] bd: chap 6 packet=11027870976, 615364 ms
[23:43:50] bd: chap 7 packet=13324862400, 585001 ms
[23:43:50] bd: chap 8 packet=15472152000, 537411 ms
[23:43:50] bd: chap 9 packet=17494535616, 703452 ms
[23:43:50] bd: chap 10 packet=20160769728, 708582 ms
[23:43:50] bd: chap 11 packet=22685068800, 502710 ms
[23:43:50] bd: chap 12 packet=24520886208, 330788 ms
[23:43:50] bd: chap 13 packet=25754178048, 289706 ms
[23:43:50] bd: chap 14 packet=26591316672, 250 ms
[23:43:50] bd: title 20 has 14 chapters
[23:43:50] scan: decoding previews for title 20
[23:43:50] scan: title angle(s) 1
[23:43:50] scan: audio 0x711100: dca, rate=48000Hz, bitrate=1536000 English (DTS) (5.1 ch)
[23:43:50] scan: audio 0x1100: dca, rate=48000Hz, bitrate=1536000 English (DTS-HD MA) (5.1 ch)
[23:43:50] scan: audio 0x1101: ac3, rate=48000Hz, bitrate=640000 English (AC3) (5.1 ch)
[23:43:50] scan: audio 0x1102: ac3, rate=48000Hz, bitrate=640000 Francais (AC3) (5.1 ch)
[23:43:50] scan: audio 0x1103: ac3, rate=48000Hz, bitrate=640000 Espanol (AC3) (5.1 ch)
Scanning title 1 of 1, preview 1, 10.00 %
Scanning title 1 of 1, preview 3, 30.00 %
Scanning title 1 of 1, preview 5, 50.00 %
Scanning title 1 of 1, preview 7, 70.00 %
Scanning title 1 of 1, preview 9, 90.00 %[23:43:51] scan: 10 previews, 1920x1080, 23.976 fps, autocrop = 0/0/2/0, aspect 16:9, PAR 1:1
[23:43:51] stream: 6 good frames, 0 errors (0%)
Scanning title 1 of 1, preview 10, 100.00 %[23:43:51] libhb: scan thread found 1 valid title(s)
+ title 20:
  + playlist: 00100.MPLS
  + duration: 02:01:31
  + size: 1920x1080, pixel aspect: 1/1, display aspect: 1.78, 23.976 fps
  + autocrop: 0/0/2/0
  + support opencl: yes
  + support hwd: no
  + chapters:
    + 1: cells 0->0, 0 blocks, duration 00:09:31
    + 2: cells 0->0, 0 blocks, duration 00:10:24
    + 3: cells 0->0, 0 blocks, duration 00:10:35
    + 4: cells 0->0, 0 blocks, duration 00:10:48
    + 5: cells 0->0, 0 blocks, duration 00:09:00
    + 6: cells 0->0, 0 blocks, duration 00:10:15
    + 7: cells 0->0, 0 blocks, duration 00:09:45
    + 8: cells 0->0, 0 blocks, duration 00:08:57
    + 9: cells 0->0, 0 blocks, duration 00:11:43
    + 10: cells 0->0, 0 blocks, duration 00:11:49
    + 11: cells 0->0, 0 blocks, duration 00:08:23
    + 12: cells 0->0, 0 blocks, duration 00:05:31
    + 13: cells 0->0, 0 blocks, duration 00:04:50
    + 14: cells 0->0, 0 blocks, duration 00:00:00
  + audio tracks:
    + 1, English (DTS) (5.1 ch) (iso639-2: eng), 48000Hz, 1536000bps
    + 2, English (DTS-HD MA) (5.1 ch) (iso639-2: eng)
    + 3, English (AC3) (5.1 ch) (iso639-2: eng), 48000Hz, 640000bps
    + 4, Francais (AC3) (5.1 ch) (iso639-2: fra), 48000Hz, 640000bps
    + 5, Espanol (AC3) (5.1 ch) (iso639-2: spa), 48000Hz, 640000bps
  + subtitle tracks:
    + 1, English (iso639-2: eng) (Bitmap)(PGS)
    + 2, Francais (iso639-2: fra) (Bitmap)(PGS)
    + 3, Espanol (iso639-2: spa) (Bitmap)(PGS)
Reading chapter markers from file C:\Users\shear\AppData\Local\Temp\TheIntern-20-chapters.csv
AC3 Passthru requested and input codec is not compatible for track 1, using AC3 encoder
Subtitle Scan Enabled - enabling subtitles if found for foreign language segments
[23:43:51] 2 job(s) to process
[23:43:51] starting job
[23:43:51] sync: expecting 174832 video frames
[23:43:51] job configuration:
[23:43:51]  * source
[23:43:51]    + D:\video\backup\THE_INTERN
[23:43:51]    + title 20, chapter(s) 1 to 14
[23:43:51]  * destination
[23:43:51]    + C:\Users\shear\Videos\TheIntern.mp4
[23:43:51]    + container: MPEG-4 (libavformat)
[23:43:51]      + chapter markers
[23:43:51]  * video track
[23:43:51]    + decoder: h264
[23:43:51]      + bitrate 200 kbps
[23:43:51]    + filters
[23:43:51]      + Framerate Shaper (1:27000000:1126125)
[23:43:51]        + frame rate: 23.976 fps -> constant 23.976 fps
[23:43:51]      + Crop and Scale (1918:1080:0:0:2:0)
[23:43:51]        + source: 1920 * 1080, crop (0/0/2/0): 1918 * 1080, scale: 1918 * 1080
[23:43:51]    + loose anamorphic
[23:43:51]      + storage dimensions: 1918 * 1080, mod 2
[23:43:51]      + pixel aspect ratio: 1 / 1
[23:43:51]      + display dimensions: 1918 * 1080
[23:43:51]  * Foreign Audio Search: Passthrough, Forced Only
[23:43:51]    + subtitle, English (track 0, id 0x1200) Picture [PGS]
[23:49:28] reader: done. 2 scr changes
[23:49:28] work: average encoding speed for job is 0.000000 fps
[23:49:28] render: 0 frames output, 0 dropped and 0 duped for CFR/PFR
[23:49:28] render: lost time: 0 (0 frames)
[23:49:28] render: gained time: 0 (0 frames) (0 not accounted for)
[23:49:28] stream: 174832 good frames, 0 errors (0%)
[23:49:28] Subtitle track 0 (id 0x1200) 'English': 2601 hits (0 forced)
[23:49:28] No candidate detected during subtitle scan
[23:49:28] starting job
[23:49:28] work: mixdown not specified, track 1 setting mixdown 5.1 Channels
[23:49:28] work: bitrate not specified, track 1 setting bitrate 640 Kbps
[23:49:28] sync: expecting 174832 video frames
[23:49:28] job configuration:
[23:49:28]  * source
[23:49:28]    + D:\video\backup\THE_INTERN
[23:49:28]    + title 20, chapter(s) 1 to 14
[23:49:28]  * destination
[23:49:28]    + C:\Users\shear\Videos\TheIntern.mp4
[23:49:28]    + container: MPEG-4 (libavformat)
[23:49:28]      + chapter markers
[23:49:28]  * video track
[23:49:28]    + decoder: h264
[23:49:28]      + bitrate 200 kbps
[23:49:28]    + filters
[23:49:28]      + Framerate Shaper (1:27000000:1126125)
[23:49:28]        + frame rate: 23.976 fps -> constant 23.976 fps
[23:49:28]      + Crop and Scale (1918:1080:0:0:2:0)
[23:49:28]        + source: 1920 * 1080, crop (0/0/2/0): 1918 * 1080, scale: 1918 * 1080
[23:49:28]    + loose anamorphic
[23:49:28]      + storage dimensions: 1918 * 1080, mod 2
[23:49:28]      + pixel aspect ratio: 1 / 1
[23:49:28]      + display dimensions: 1918 * 1080
[23:49:28]    + encoder: H.264 (libx264)
[23:49:28]      + profile: high
[23:49:28]      + level:   4.1
[23:49:28]      + quality: 20.00 (RF)
[23:49:28]  * audio track 1
[23:49:28]    + decoder: English (DTS) (5.1 ch) (track 1, id 0x711100)
[23:49:28]      + bitrate: 1536 kbps, samplerate: 48000 Hz
[23:49:28]    + mixdown: 5.1 Channels
[23:49:28]    + encoder: AC3 (libavcodec)
[23:49:28]      + bitrate: 640 kbps, samplerate: 48000 Hz
[23:49:28] encx264: min-keyint: 24, keyint: 240
[23:49:28] encx264: encoding at constant RF 20.000000
[23:49:28] encx264: unparsed options: level=4.1:vbv-bufsize=78125:vbv-maxrate=62500
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
[23:49:28] reader: first SCR 1044806 id 0x1011 DTS 1044806
x264 [info]: profile High, level 4.1
[23:49:28] h264: "Chapter 1" (1) at frame 0 time 3754
[23:49:28] sync: first pts is 3754
[00:05:34] h264: "Chapter 2" (2) at frame 13694 time 51409138
[00:23:12] h264: "Chapter 3" (3) at frame 28660 time 107587761
[00:41:21] h264: "Chapter 4" (4) at frame 43875 time 164701067
[01:01:15] h264: "Chapter 5" (5) at frame 59423 time 223064372
[01:17:09] h264: "Chapter 6" (6) at frame 72376 time 271686696
[01:36:52] h264: "Chapter 7" (7) at frame 87130 time 327069523
[01:54:00] h264: "Chapter 8" (8) at frame 101156 time 379719621
[02:10:21] h264: "Chapter 9" (9) at frame 114041 time 428086689
[02:31:41] h264: "Chapter 10" (10) at frame 130907 time 491397437
[02:52:36] h264: "Chapter 11" (11) at frame 147896 time 555169896
[03:08:03] h264: "Chapter 12" (12) at frame 159949 time 600413844
[03:17:57] h264: "Chapter 13" (13) at frame 167880 time 630184836
[03:20:28] reader: done. 2 scr changes
[03:20:28] h264: "Chapter 14" (14) at frame 174823 time 656247122
[03:20:30] work: average encoding speed for job is 13.808764 fps
[03:20:30] sync: got 174832 frames, 174832 expected
[03:20:30] render: 174832 frames output, 0 dropped and 0 duped for CFR/PFR
[03:20:30] render: lost time: 0 (0 frames)
[03:20:30] render: gained time: 0 (0 frames) (0 not accounted for)
[03:20:30] h264-decoder done: 174832 frames, 0 decoder errors, 0 drops
x264 [info]: frame I:2163  Avg QP:17.78  size:250994
x264 [info]: frame P:81653 Avg QP:21.03  size: 61823
x264 [info]: frame B:91016 Avg QP:22.62  size: 23696
x264 [info]: consecutive B-frames: 10.8% 53.7% 17.1% 18.5%
x264 [info]: mb I  I16..4:  3.6% 86.0% 10.4%
x264 [info]: mb P  I16..4:  0.5%  5.3%  0.5%  P16..4: 49.8% 20.0% 11.5%  0.0%  0.0%    skip:12.5%
x264 [info]: mb B  I16..4:  0.0%  0.5%  0.0%  B16..8: 55.4%  5.1%  1.0%  direct: 2.7%  skip:35.3%  L0:43.2% L1:53.0% BI: 3.8%
x264 [info]: 8x8 transform intra:85.3% inter:74.4%
x264 [info]: coded y,uvDC,uvAC intra: 84.9% 86.8% 58.9% inter: 32.0% 40.7% 2.9%
x264 [info]: i16 v,h,dc,p: 36% 19%  5% 40%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 17% 12% 27%  6%  7%  8%  8%  7%  8%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 24% 17% 11%  6% 10%  9%  9%  7%  6%
x264 [info]: i8c dc,h,v,p: 58% 16% 19%  7%
x264 [info]: Weighted P-Frames: Y:0.7% UV:0.3%
x264 [info]: ref P L0: 63.5% 13.8% 15.9%  6.7%  0.0%
x264 [info]: ref B L0: 83.5% 15.3%  1.3%
x264 [info]: ref B L1: 95.5%  4.5%
x264 [info]: kb/s:8499.90
[03:20:30] dca-decoder done: 0 frames, 0 decoder errors, 0 drops
[03:20:30] mux: track 0, 174832 frames, 7747518600 bytes, 8499.85 kbps, fifo 2048
[03:20:30] mux: track 1, 227873 frames, 583354880 bytes, 640.00 kbps, fifo 2048
[03:20:30] stream: 174832 good frames, 0 errors (0%)
[03:20:30] libhb: work result = 0
Encode done!
HandBrake has exited.
Last edited by Anonymous on Tue Mar 08, 2016 12:37 pm, edited 1 time in total.
Reason: Logs in code blocks please
mduell
Veteran User
Posts: 8198
Joined: Sat Apr 21, 2007 8:54 pm

Re: How to make sure that encoding uses GPU

Post by mduell »

You picked x264, a software encoder. Pick qsv if you want ASIC encoding.
AlmightyFireFly
Posts: 3
Joined: Sun Mar 06, 2016 9:17 pm

Re: How to make sure that encoding uses GPU

Post by AlmightyFireFly »

So I went back and tried with the qsv enabled.. It locked up my computer and would not enable the intel and the NVidia drivers at the same time no matter what I tried. I ended up taking the NVidia card out so I could get the intel to work. Then without changing any other settings I was able to get it to work. I topped out at about 124fps... pretty quick, but the hdmi audio from the intel wouldn't work, even after driver updates. I went ahead and put I NVidia card back in. I do like how fast the qsv works, but gaming would be crap and it's not faster than my nvenc, just easier. Since handbrake is so good, I wish there was handbrake support for nvenc.
Number8
Novice
Posts: 64
Joined: Fri Dec 26, 2014 11:46 am

Re: How to make sure that encoding uses GPU

Post by Number8 »

On a brand new PC, i7/Skylake, M.2 disk, with a NVidia GTX 950, Win 10 Pro, I have no problem using x264 QSV or NVidia encoder (using Stax Rip in this later case).
I made a few tests with H265 as well using hw encoders (StaxRip): to long to do the processing, no real size gain. This is why I stick to HB/H264 which more convenient to use even if the automatic selection of audio tracks is not working very well.
Typical FPS > 320 with an ISO image stored on a NAS (1Gb/sec network). QP = 20, QSV best, H264 profile High/4.1, decomb = bob.

Would be great though to have H265 QSV support, just to carry some more tests
Post Reply