How to make sure that encoding uses GPU
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.
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.
How to make sure that encoding uses GPU
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
Windows 10 x64 - NVidia GeForce 950 - Handbrake 10.2.7286
Thank you
Nicolas
Re: How to make sure that encoding uses GPU
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.
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.
Re: How to make sure that encoding uses GPU
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?
Re: How to make sure that encoding uses GPU
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.
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.
Re: How to make sure that encoding uses GPU
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.
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.
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.
Do you mean that for larger file size the benefit of QSV decreases?Be prepared for the reality that the blazing speed of QSV is paid for in larger file sizes
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.
Re: How to make sure that encoding uses GPU
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.
If you want to use the GPU on your Skylake processor for video encoding, you need to install the Intel drivers.
Re: How to make sure that encoding uses GPU
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?
Is H265 the codec to be used now, especially for BR?
Re: How to make sure that encoding uses GPU
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".
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".
Re: How to make sure that encoding uses GPU
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
Re: How to make sure that encoding uses GPU
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.
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.
Re: How to make sure that encoding uses GPU
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.
Re: How to make sure that encoding uses GPU
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.).
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.).
Re: How to make sure that encoding uses GPU
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.
Re: How to make sure that encoding uses GPU
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.
Re: How to make sure that encoding uses GPU
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?
Re: How to make sure that encoding uses GPU
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.
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.
Re: How to make sure that encoding uses 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.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?
Re: How to make sure that encoding uses GPU
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.
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.
Re: How to make sure that encoding uses GPU
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.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.
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.
-
- Posts: 3
- Joined: Sun Mar 06, 2016 9:17 pm
Re: How to make sure that encoding uses GPU
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.
Re: How to make sure that encoding uses GPU
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.
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.
-
- Posts: 3
- Joined: Sun Mar 06, 2016 9:17 pm
Re: How to make sure that encoding uses GPU
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
Reason: Logs in code blocks please
Re: How to make sure that encoding uses GPU
You picked x264, a software encoder. Pick qsv if you want ASIC encoding.
-
- Posts: 3
- Joined: Sun Mar 06, 2016 9:17 pm
Re: How to make sure that encoding uses GPU
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.
Re: How to make sure that encoding uses GPU
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
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