Transitioning from x265 to Turing quality-based encoding

[easy2Bcheesy]

Hi everyone,

Has anyone managed to crack quality-based HEVC encoding on Turing? Here's how I produce content:

1. Edit in Adobe Premiere - 3840x2160 at 59.94fps
2. Export a ProRes intermediate
3. Use Handbrake to create x264/x265 encodes. I use CRF 18 with x264 an CRF 20 with x265, usually on medium preset

When editing at 1080p, I tend to export straight from Premiere using Voukoder, but this seems to be cripplingly slow at 4K.

Anyway, on point three, I could really benefit from transitioning from x265 to NvEnc, even if there is some file bloat. However, QP-based encoding even at QP24/25 seems to produce file sizes equivalent to x264, so I'm wondering if anyone has successfully made this transition.

With 4K content, editing workstations can be locked up for hours, while Turing blasts through 4K at 60fps. I can stand to take a hit on file size to a certain extent if we get this enormous time saving! Is there such a thing as a free - or free-ish - lunch?

[foxyshadis]

I know in ffmpeg you manually twiddle a few values:

  -spatial_aq        <boolean>    E..V...... set to 1 to enable Spatial AQ (default false)
  -temporal_aq       <boolean>    E..V...... set to 1 to enable Temporal AQ (default false)
  -zerolatency       <boolean>    E..V...... Set 1 to indicate zero latency operation (no reordering delay) (default false)
  -nonref_p          <boolean>    E..V...... Set this to 1 to enable automatic insertion of non-reference P-frames (default false)
  -strict_gop        <boolean>    E..V...... Set 1 to minimize GOP-to-GOP rate fluctuations (default false)
  -aq-strength       <int>        E..V...... When Spatial AQ is enabled, this field is used to specify AQ strength. AQ strength scale is from 1 (low) - 15 (aggressive) (from 1 to 15) (default 8)
  -cq                <float>      E..V...... Set target quality level (0 to 51, 0 means automatic) for constant quality mode in VBR rate control (from 0 to 51) (default 0)
  -aud               <boolean>    E..V...... Use access unit delimiters (default false)
  -bluray-compat     <boolean>    E..V...... Bluray compatibility workarounds (default false)
  -init_qpP          <int>        E..V...... Initial QP value for P frame (from -1 to 51) (default -1)
  -init_qpB          <int>        E..V...... Initial QP value for B frame (from -1 to 51) (default -1)
  -init_qpI          <int>        E..V...... Initial QP value for I frame (from -1 to 51) (default -1)
  -qp                <int>        E..V...... Constant quantization parameter rate control method (from -1 to 51) (default -1)
  -weighted_pred     <int>        E..V...... Set 1 to enable weighted prediction (from 0 to 1) (default 0)
  -b_ref_mode        <int>        E..V...... Use B frames as references (from 0 to 2) (default disabled)
     disabled        0            E..V...... B frames will not be used for reference
     each            1            E..V...... Each B frame will be used for reference
     middle          2            E..V...... Only (number of B frames)/2 will be used for reference
  -dpb_size          <int>        E..V...... Specifies the DPB size used for encoding (0 means automatic) (from 0 to INT_MAX) (default 0)

But nvidia is very opaque on what the hq vs fast profiles actually mean. I suppose I should make a mini-app to see what features get returned when setting the profile, at least as of this driver version.

[excellentswordfight]

With NVEncC64 maybe start out with something like this for 2160p

 --codec h265 --preset quality --profile main10 --level 5.1 --vbrhq 0 --vbr-quality 0 --aq --aq-temporal --lookahead 32 --colormatrix bt709 --colorprim bt709 --transfer bt709

Play with the vbr-quality value until you find appropriate file size.

[Sharc]

Quality based encoding with NVEncC:
--vbrhq 0 --vbr-quality x
(set x for the quality level, e.g. 20)

Quality based encoding with ffmpeg:
-b:v 0k -cq x
(x defines the quality level, e.g. 20. Important to set -b:v 0k)

[easy2Bcheesy]

Interesting results from NVEncC64 but dealing with command lines is a massive pain for me and will be difficult to roll out to my team - are there any GUIs that can do the job?

I can't seem to get these settings working in Handbrake and while the settings have visibility in Staxrip, I can't seem to change them with custom command lines :/

[Taurus]

and while the settings have visibility in Staxrip, I can't seem to change them with custom command lines :/

On the last page of the NVEncC options (Other) is a field where you can do your custom settings.
I dont know if this will override the main settings of the Gui.
Never tested this.
When you are ready with your tweaking build a template with your desired settings and voila...
ready for use .

[easy2Bcheesy]

Thanks for this, I'm still having issues with GUI support here but even with NvEncC64 command lines, I've got to say that Turing gets nowhere near to x265 quality in my tests based on challenging video game footage, even with a 20 per cent file size increase. It's a ton blurrier. Maybe it's the content I'm using, I'll do some further tests.

[RanmaCanada]

Originally Posted by easy2Bcheesy

Thanks for this, I'm still having issues with GUI support here but even with NvEncC64 command lines, I've got to say that Turing gets nowhere near to x265 quality in my tests based on challenging video game footage, even with a 20 per cent file size increase. It's a ton blurrier. Maybe it's the content I'm using, I'll do some further tests.

No as hardware encoding still can't beat software, at least at consumer level. It will take at least another generation before hardware ASICS can catch up to software. People are hoping that with AV1, that the hardware encoders will match the software right out of the gate.

[foxyshadis]

Originally Posted by RanmaCanada

No as hardware encoding still can't beat software, at least at consumer level. It will take at least another generation before hardware ASICS can catch up to software. People are hoping that with AV1, that the hardware encoders will match the software right out of the gate.

It's not so much the hardware as the fact that they won't let anything run at less than realtime, either 30fps or 60fps at any frame size, depending on the card, because that's 99% use case. As beefy as Turing is, there's only so much you can do in that budget.

Getting in contact with Nvidia directly and talking to an engineer, maybe obtaining some kind of NDA'd SDK that unlocks slower offline encoding, is probably the only way to get any better quality out of it.

[Sharc]

Originally Posted by easy2Bcheesy

I've got to say that Turing gets nowhere near to x265 quality in my tests based on challenging video game footage, even with a 20 per cent file size increase. It's a ton blurrier. Maybe it's the content I'm using, I'll do some further tests.

And, for a fair(er) quality comparison one should actually use an ultrafast preset with x265 rather than medium or slow.

[benwaggoner]

Originally Posted by Sharc

And, for a fair(er) quality comparison one should actually use an ultrafast preset with x265 rather than medium or slow.

Yeah. Comparing efficiency @ performance is really the key here, if the goal is to determine the optimal quality possible at a given perf.

Although HW GPU encoders often get used for video game recording, as performance gets a lot better moving encoding off the CPU on systems without that many cores. And obviously memory bandwidth hit is better not having to copy the rendered frames back to main memory. Different use scenarios can have very different performance parameters even on the same hardware.