Handbrake encoding Nvidia vs QSV

[arron9999]

Hi all,

Been reading a lot on the Forum so thought it was timed I joined. There is a lot of discussion on what is best and I'm stuck on what to do.

I have a whole Library of DVD/blu ray rips that are taking up a huge amount of space on my media server and im not able to increase capacity unless i replace the whole thing (is a pre built).

I have 2 machines that I can use to encode these a Ryzen 2600 with a GTX1080 and a intel Pentium G4560 with UHD610.

All my compressions are done with Handbrake a 20gb Bray can take 2-3 hours with x264 but only 20 mins with the GTX. QSV is somewhere in the middle if i pick the quality setting. The problem is the GTX files are huge compared the software and I have tried them on H265 also which reduces them but X264 is still smaller.

What would people suggest i use to to encode theses? They can be x265/h265 as all devices can either direct play or have hardware acceleration, its just too painful to do it via CPU. im not looking for the best quality or the smallest files but the middle ground if that's possible. If i have to change software to something else too im open to suggestions.

Thanks all

[jagabo]

If you want specific file sizes use bitrate based encoding. With quality based encoding (CRF, RF, QP) the encoder uses whatever bitrate is necessary to deliver the quality you request (different videos will require different bitrates). Quality values between different encoders are not the same. So you'll have to experiment with the encoders to find what's acceptable to you. For example CRF 20 in x264 is not the same as CRF 20 in x265. But within a particular encoder, lower CRF values deliver higher quality and larger files.

[stonesfan187]

I agree with jagabo. If you want specific file sizes, use bitrate-based encoding. I would recommend using x264 over NVENC or QSV as the quality will be better. I have a GTX1070 in my system which can use NVENC. But the quality of the encodes is always worse at the same bitrates as x264. NVENC is more useful for doing a fast encode where you don't care about file size or a little bit worse quality. I, myself, compress with BD Rebuilder to MKV, x264, 640kbps AC3 5.1 on CRF20 with the Default/High Quality setting (which I think uses Medium x264 speed) and am happy with the results. Then I stream all these to my Rokus with Emby running on my PC. You can use x265 which can produce smaller files than x264 at the same bitrates, but the tradeoff is longer encoding time.

[jagabo]

You can use x265 which can produce smaller files than x264 at the same bitrates

At the same bitrate the sizes will be equal. But the x265 video may be better quality.

[James Pous]

I used different programs in the last 5 years to convert different FullHD videos with x264, x265, NVEnc (Pascal, Maxwell,etc.) and Intel QuickSync (IvyBridge, Coffeelake).
Actually I would use h264 video format for best quality and small file size! x265 is a little bit better in quality and up to 25% in filesize, but very slow in encoding.

My personal recommandation:

Full HD Video (e.g. Bluray)

Video Bitrate: 4.000 kbit/s
Audio Bitrate: AAC 256kbit/s (for multi channel sound AC-3 format)

Conversion tool: Handbrake

Video codec: H.264
Bitrate: 4.000 kbit/s (6.000 kbit/s for very good results!)
Encoding: 2pass (fast first pass!)
Preset: slow
tuning: Film
Profile: high
Level: 4.0 (compatible with many devices: TV, smartphone, tablet, etc.)

With a fast computer you can encode a movie in realtime! 1 hour film = 1-2 hour(s) encoding

Try it with a small test video to compare the encoding speed and time.

---

Intel QuickSync and NVidia Geforce GTX 1060 or faster and do the encoding in realtime. 1 h movie = 1 h encoding with best (!) quality for a GPU encode.
The quality is lower and you see small differences, sometimes soft and blury textures. CPU encoding is much sharper at the same bitrate and quality settings.

For Nvidia Geforce Encoding you have to use StaxRip. It produces the best quality and filesize.
Handbrake does not have the important settings to produce high quality movies with Geforce GPUs!

For Encoding with Intel CPU (QuickSync) I prefer handbrake, but StaxRip does the same.
The basic settings of Handbrake does not get the maximum quality of your videos.

You need some further parameters to get the best results:
custom parameters for Intel Quicksync encoding: tu=1:la=1:la-depth=60:ref=8:trellis=3
These settings get the best results in my opinion.

[jagabo]

You need some further parameters to get the best results:
custom parameters for Intel Quicksync encoding: tu=1:la=1:la-depth=60:ref=8:trellis=3

What encoder are you using and how are you passing those parameters? I've been playing around with ffmpeg's hevc_qsv encoder but don't see how one passes encoder specific settings like that. I know -x264opts, -x264-params, and -x265-params accept colon separated strings like that. But I haven't found an equivalent for the h264_qsv or hevc_qsv encoders.

[James Pous]

[Attachment 56932 - Click to enlarge]

Here you can see my favorite settings for Intel QuickSync (QSV) encoding mit h264.
I use 8 ref frames, to increase compression (reduce filesize) and it produce more quality and a little bit sharper videos.

---

If you prefer h265 encoding with Intel QuickSync, you will need more time to encode, but you will get better video quality!
You can use my 'advanced Options' with H.265 (QSV), too!

Some newer Intel CPUs (Skylake) support h.265 coding with 10bit, but I am not sure If there is any TV or video player who play them!
This video format is a little bit sharper and show more details.

[jagabo]

Thanks for the reply. A while after I last wrote I figured you were using Handbrake.

https://handbrake.fr/docs/en/latest/technical/video-qsv.html

Of the settings you recommend, the hevc_qsv encoder appears support only tu (target usage, aka preset) and refs (reference frames), both of which I'm already using.

ffmpeg ... vcodec hevc_qsv -preset 1 -refs 8 ...

[sophisticles]

You need some further parameters to get the best results:
custom parameters for Intel Quicksync encoding: tu=1:la=1:la-depth=60:ref=8:trellis=3

What encoder are you using and how are you passing those parameters? I've been playing around with ffmpeg's hevc_qsv encoder but don't see how one passes encoder specific settings like that. I know -x264opts, -x264-params, and -x265-params accept colon separated strings like that. But I haven't found an equivalent for the h264_qsv or hevc_qsv encoders.

https://trac.ffmpeg.org/wiki/Hardware/QuickSync

ffmpeg -h encoder=hevc_qsv will give you a list of options, daisy chain options like this:

ffmpeg -hwaccel qsv -c:v h264_qsv -i input.mp4 -c:v h264_qsv -b:v 5M -preset veryslow -look_ahead 1 -look_ahead_depth 100 -adaptive_i 1 -adaptive_b 1 output.mp4

You get the idea.

[jagabo]

You need some further parameters to get the best results:
custom parameters for Intel Quicksync encoding: tu=1:la=1:la-depth=60:ref=8:trellis=3

What encoder are you using and how are you passing those parameters? I've been playing around with ffmpeg's hevc_qsv encoder but don't see how one passes encoder specific settings like that. I know -x264opts, -x264-params, and -x265-params accept colon separated strings like that. But I haven't found an equivalent for the h264_qsv or hevc_qsv encoders.

https://trac.ffmpeg.org/wiki/Hardware/QuickSync

ffmpeg -h encoder=hevc_qsv will give you a list of options, daisy chain options like this:

ffmpeg -hwaccel qsv -c:v h264_qsv -i input.mp4 -c:v h264_qsv -b:v 5M -preset veryslow -look_ahead 1 -look_ahead_depth 100 -adaptive_i 1 -adaptive_b 1 output.mp4

You get the idea.

Thank you. But I know about those options. I thought James Pous had found away to pass other options -- "ffmpeg -h encoder=hevc_qsv" doesn't show support for lookahead, trellis, etc.

hevc_qsv encoder AVOptions:
  -async_depth       <int>        E..V..... Maximum processing parallelism (from 1 to INT_MAX) (default 4)
  -avbr_accuracy     <int>        E..V..... Accuracy of the AVBR ratecontrol (from 0 to INT_MAX) (default 0)
  -avbr_convergence  <int>        E..V..... Convergence of the AVBR ratecontrol (from 0 to INT_MAX) (default 0)
  -preset            <int>        E..V..... (from 1 to 7) (default medium)
     veryfast                     E..V.....
     faster                       E..V.....
     fast                         E..V.....
     medium                       E..V.....
     slow                         E..V.....
     slower                       E..V.....
     veryslow                     E..V.....
  -rdo               <int>        E..V..... Enable rate distortion optimization (from -1 to 1) (default -1)
  -max_frame_size    <int>        E..V..... Maximum encoded frame size in bytes (from -1 to 65535) (default -1)
  -max_slice_size    <int>        E..V..... Maximum encoded slice size in bytes (from -1 to 65535) (default -1)
  -bitrate_limit     <int>        E..V..... Toggle bitrate limitations (from -1 to 1) (default -1)
  -mbbrc             <int>        E..V..... MB level bitrate control (from -1 to 1) (default -1)
  -extbrc            <int>        E..V..... Extended bitrate control (from -1 to 1) (default -1)
  -adaptive_i        <int>        E..V..... Adaptive I-frame placement (from -1 to 1) (default -1)
  -adaptive_b        <int>        E..V..... Adaptive B-frame placement (from -1 to 1) (default -1)
  -b_strategy        <int>        E..V..... Strategy to choose between I/P/B-frames (from -1 to 1) (default -1)
  -forced_idr        <boolean>    E..V..... Forcing I frames as IDR frames (default false)
  -low_power         <boolean>    E..V..... enable low power mode(experimental: many limitations by mfx version, BRC modes, etc.) (default false)
  -idr_interval      <int>        E..V..... Distance (in I-frames) between IDR frames (from -1 to INT_MAX) (default 0)
     begin_only                   E..V..... Output an IDR-frame only at the beginning of the stream
  -load_plugin       <int>        E..V..... A user plugin to load in an internal session (from 0 to 2) (default hevc_hw)
     none                         E..V.....
     hevc_sw                      E..V.....
     hevc_hw                      E..V.....
  -load_plugins      <string>     E..V..... A :-separate list of hexadecimal plugin UIDs to load in an internal session (default "")
  -profile           <int>        E..V..... (from 0 to INT_MAX) (default unknown)
     unknown                      E..V.....
     main                         E..V.....
     main10                       E..V.....
     mainsp                       E..V.....
  -gpb               <boolean>    E..V..... 1: GPB (generalized P/B frame); 0: regular P frame (default true)

I confess, I don't know what many of those do. And some of them don't make any difference visually, the exact same file size, etc. Do you have some secret sauce for improving quality/bitrate with hevc_qsv (10 bit)? I'm working with an i9 9900K.

[sophisticles]

You are correct, Intel HEVC does not support look ahead; though in all honesty even though Intel claims that this should be most people's starting place, I have trouble telling the difference.

For me, the 2 options, aside from using -preset veryslow, that seems to make a big difference, something that I can see, and you know I'm usually the guy that says he doesn't see a difference, is -extbrc 1 followed by --b_strategy 1.

Ffmpeg does not show all the available options via -h, here is a good guide from Intel:

https://software.intel.com/content/www/us/en/develop/articles/evolution-of-hardware-he...rocessors.html

https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/cloud-comput...hite-paper.pdf

https://ffmpeg.org/ffmpeg-codecs.html#QSV-encoders

Take note towards the bottom, Intel has repeatedly stated that CQP mode gives the best results by far, though it's also the hardest to use and the actually don't recommend casual users use it.

-i_qfactor 1.0 -i_qoffset -1.0 -b_qfactor 1.0 -b_qoffset 0.0 do make a difference, the qfactor work the same way ip and bp ratio work.

[jagabo]

Thanks for all that. I'll try them out.