NVEncC by rigaya - NVIDIA GPU encoding

[flying2ndsky]

Your crop values are incorrect - if your source video is 1280x720 , then you cannot crop 1280 pixels from the right (you're left with "zero" ). It works on a 1920x1080 mkv source with those values . The syntax is --crop left,top,right,bottom

THANKS, it's cleared. no problem for me with qsvencc' cropping or nvencc' cropping in now. I understood that cropping option usage in qsvencc or nvencc, 'cause i was already advised from rigaya.

[Selur]

btw. did anyone use the relatively new vbr2 option and post some comments about it?

[poisondeathray]

Some preliminary impressions on --vbr2 :

It makes small difference quality wise, but slows it down considerably. --vbr is about 1.5-1.6x faster on some SD tests. On some tests, some sections were actually noticably worse. I probably wouldn't use it as-is

--aq was introduced also - that does make an impact on quality. The net effect/redistribution looks very similar to the original haali AQ. There is no strenght control yet, but I would say it's beneficial for most generic cases. It also slows it down considerably, slightly more than --vbr2, --vbr is about 1.55-1.65x faster on the SD tests

Combining --vbr2 and --aq2 , --vbr alone is about 2.1-2.3x faster on the SD tests

[flying2ndsky]

Some preliminary impressions on --vbr2 :

It makes small difference quality wise, but slows it down considerably. --vbr is about 1.5-1.6x faster on some SD tests. On some tests, some sections were actually noticably worse. I probably wouldn't use it as-is

--aq was introduced also - that does make an impact on quality. The net effect/redistribution looks very similar to the original haali AQ. There is no strenght control yet, but I would say it's beneficial for most generic cases. It also slows it down considerably, slightly more than --vbr2, --vbr is about 1.55-1.65x faster on the SD tests

Combining --vbr2 and --aq2 , --vbr alone is about 2.1-2.3x faster on the SD tests

it's similar to my thought about that new options, i.e. --vbr2, & --aq.
the encoding time was about x2.5 longer than usual in my usage of the nvencc.
but sorry to say, resulting quality improvement really did not be seen to me.

[sophisticles]

I'm sorry to say but most consumer H/W encoders continue to be a disappointment and I can't help but wonder if it's not the hardware but rather the software that coded to use it. NVIDIA, from the moment the first hardware encoding chip was included in it's video cards, back with the 750ti they should have taken the time to code and release an encoder that FULLY exploits ALL the features of the new hardware.

Instead they released only the SDK and then when people asked about it on the NVIDIA forums they were told that it was up to individual developers to write the code to use their hardware. To me that mentality makes no sense and unfortunately AMD and Intel have done similar things with their hardware encoders.

On a related note, I recently had a chance to briefly try out a Haswell based chip, one of the Pentiums, the G3258 I think it was, and was not impressed with the overall quality or speed. The hardware deinterlacer in fact was very poor, even yadif, even in bob mode, which surprised me and even the Intel IVTC deinterlacer wasn't all that great, which is really shocking because in theory all it's doing is keeping the progressive frames and dropping the interlaced ones, so there should be no quality issues.

Maybe Skylake is better, I would love to try it;s HEVC and VP8 hardware encoding.

[Selur]

iirc. NVEnc like previous encoders from NVIDIA doesn't use the GPU, it uses a dedicated encoder chip so there is no 'FULLY exploits ALL the features of the new hardware'

btw.: --aq is a software feature, so it's not done by encoder chip or the gpu

even the Intel IVTC deinterlacer wasn't all that great, which is really shocking because in theory all it's doing is keeping the progressive frames and dropping the interlaced ones,

dropping the interlaced frames,... what? IVTC normally is a 3:2 pulldown, no dropping frames,...

[sophisticles]

iirc. NVEnc like previous encoders from NVIDIA doesn't use the GPU, it uses a dedicated encoder chip so there is no 'FULLY exploits ALL the features of the new hardware'

btw.: --aq is a software feature, so it's not done by encoder chip or the gpu

I know it's a dedicated chip but that chip supports certain "features", for lack of a better word, and you still need to write the code that utilizes said features, for instance B frames or reference frames, just because it's a dedicated chip it doesn't mean that you don't have to write code to make use of said abilities.

As for aq being a software feature, that may well be the case but there is still a certain way of writing the code to make it work with the hardware encoding that the chip does, it's not like you can just grab the code from x264 or x265 and use that aq, it needs to interact a certain way.

dropping the interlaced frames,... what? IVTC normally is a 3:2 pulldown, no dropping frames,...

You can call it anything you want, but my understanding is that a 3:2 telecined video stream, basically has 3 progressive frames followed by 2 interlaced frames, rinse repeat, this is the way it works, no? If so then I always assumed that when you IVTC, which is referred to as removing pulldown that what basically happens is the interlaced frames are discarded, thrown away and you are now left with only the progressive frames, which naturally changes the frame rate from 29.97fps to 23.fps.

Is this not what happens?

[sneaker]

3 progressive frames + 2 interlaced frames = 5 frames

Throw away 2, keep 3:
29.97 * 3/5 = 17.98

In other words: no, that is not what is happening.

[sophisticles]

So then how does it work?

[hello_hello]

So then how does it work?

For the common 2:3 pulldown method, the first frame consists of two fields, the second frame is "stretched" over three fields (by repeating a field), the third frame consists of two fields (which end up split between frames), the fourth frame is "stretched" over three fields (by repeating a field), and so on... eight fields are stretched over ten and four frames are stretched over five. For IVTC, ideally the duplicate fields would be removed and the remaining fields would be re-combined for progressive frames again.

My understanding of the IVTC process, at least when it comes to Avisynth plugins, is they combine the top and bottom fields of the current frame and also the top field of the next frame with the bottom field of the current frame, those two frames are checked for combing and the frame with the least combing becomes the output frame. That process is repeated for each frame and should result in the two repeated fields being discarded, leaving five progressive frames where one in every five is a duplicate, and it can then be removed.

How IVTC is done by hardware I don't really know but it wouldn't be as simple as throwing away interlaced frames, because there's two "dirty frames" in every five and you can only drop one for 23.976fps. Checking for repeating fields and removing them would give you 23.976 once the remaining fields are combined into frames again but that'd possibly rely on a regular 2:3 pattern to work well. Maybe hardware ITVC removes duplicate fields and de-interlaces the new "progressive" frames if combing is detected, or maybe it'd generally rely on a steady 2:3 pattern to work properly. Or the proper flags being present in the video steam etc. Someone else may know.

[stranno]

CBR is not working properly for me. I cant get a fixed framerate like x264 does.

[poisondeathray]

CBR is not working properly for me. I cant get a fixed framerate like x264 does.

Can you clarify - CBR or CFR ?

bitrate or framerate ?

It doesn't do true CBR, neither does x264

[stranno]

CBR is not working properly for me. I cant get a fixed framerate like x264 does.

Can you clarify - CBR or CFR ?

bitrate or framerate ?

It doesn't do true CBR, neither does x264

CBR, i'm using Lord_Mulder's Simple x264 Launcher.

Using x264's --bitrate parameter i always get fixed framerate.

[Selur]

@MaverickTse: If you come in contact with rigaya it would be nice if you could ask him if there was a way to allow hdr signaling.
(Pascal GP10x support HEVC 10bit so if NVEncC would allow HDR signaling one could use such cards for HDR encoding.)

Cu Selur

[ezcapper]

@MaverickTse: If you come in contact with rigaya it would be nice if you could ask him if there was a way to allow hdr signaling.
(Pascal GP10x support HEVC 10bit so if NVEncC would allow HDR signaling one could use such cards for HDR encoding.)

Cu Selur

It is not possible, the SDK does not support it:

https://github.com/rigaya/NVEnc/issues/1

Hopefully it will be available when the gtx 20xx cards come out

[Selur]

Sad news, but thanks! (didn't know there was a github for NEnc )

[easyfab]

Could someone with a nvidia card ( pascal if possible ) encode this file at 5 mbits ( AVC and HEVC ) and upload the files

source : https://forum.videohelp.com/attachments/31105-1428466828/SVT_1080p50.mkv

I'd like to compare with AMD and intel Hardware encoder. Here AMD and intel : https://forum.videohelp.com/threads/380081-AMD-Polaris-%28Radeon-RX-4xx%29-H265-Encodin...=1#post2471858

[MaverickTse]

Sad news, but thanks! (didn't know there was a github for NEnc )

I didn't know rigaya has some GitHub repo with content either...
then you guys can directly file ISSUE and PULL REQUEST to him

[hydra3333]

Just wondering if there's a guide to building nvencc from the git source at https://github.com/rigaya/NVEnc ?
Nearly got it to build with vs2017 however there appear to be at least one dependency like libavutil where it isn't explained what to do.
https://github.com/rigaya/NVEnc/issues/7
Thanks

[MaverickTse]

libavutil is part of FFmpeg
that means you need to build FFmpeg first, or get the DEV files from zeranoe site, set the appropriate include path...then build

a PITA

[hydra3333]

Thanks !
Will give it a try.

[hydra3333]

For a Newbie, building rigaya's absolutely fantastic nvencc from git is harder than it looks at first glance, and then there's combining it with visual studio 2017 community with opencl 8.0 too.

Info on getting the environment and dependencies sorted so far is at https://github.com/rigaya/NVEnc/issues/7

I'm not yet convinced I can actually build a static nvencc successfully with the latest versions of dependencies such as cuda 8.0, latest ffmpeg, latest vapoursynth (not installed) and avisynth. Oh well.

[MaverickTse]

For a Newbie, building rigaya's absolutely fantastic nvencc from git is harder than it looks at first glance, and then there's combining it with visual studio 2017 community with opencl 8.0 too.

Info on getting the environment and dependencies sorted so far is at https://github.com/rigaya/NVEnc/issues/7

I'm not yet convinced I can actually build a static nvencc successfully with the latest versions of dependencies such as cuda 8.0, latest ffmpeg, latest vapoursynth (not installed) and avisynth. Oh well.

Building anything around FFmpeg is HARD, let alone the codes and tools are not all ready for the "latest".
NVEnc was not depending on FFmpeg until recent versions. I'm not sure which version, but if it was that hard, I would not have localized the NvEnc AviUtl plugin (around 1 year ago).

May i ask why would you like to build it yourself? just for the "latest and greatest"?

[hydra3333]

Building anything around FFmpeg is HARD, let alone the codes and tools are not all ready for the "latest".
NVEnc was not depending on FFmpeg until recent versions. I'm not sure which version, but if it was that hard, I would not have localized the NvEnc AviUtl plugin (around 1 year ago).

May i ask why would you like to build it yourself? just for the "latest and greatest"?

No probs. Another simple learning exercise for a newbie; I hope to retire in not that long and maybe wander back into a very-long-unused professional skill (programmer) as a hobby, and this is a superficial dabble with the prevailing toolset. Plus "latest and greatest" as you say. I found a license for win to use in a vm ...

[MaverickTse]

Building anything around FFmpeg is HARD, let alone the codes and tools are not all ready for the "latest".
NVEnc was not depending on FFmpeg until recent versions. I'm not sure which version, but if it was that hard, I would not have localized the NvEnc AviUtl plugin (around 1 year ago).

May i ask why would you like to build it yourself? just for the "latest and greatest"?

No probs. Another simple learning exercise for a newbie; I hope to retire in not that long and maybe wander back into a very-long-unused professional skill (programmer) as a hobby, and this is a superficial dabble with the prevailing toolset. Plus "latest and greatest" as you say.

then I'd suggest starting from something easier, such as building FFmpeg and maybe with some external libs.

building FFmpeg alone is not that difficult (on linux/msys2), but incorporating external stuff would be a challenge. Manageable, depending on what you included.

[hydra3333]

Thank you. Am currently having a play with that too based on others' fine work. Not all that successful at times, but that's a part of the learning process.

[tibor]

How do I get a message to rigaya? Latest 4.10 NVEnc using --bluray with 59.94 fps source, it clamps GOP to be 30 even though I specify --gop-len 60. Without --bluray it works correctly.

[MaverickTse]

How do I get a message to rigaya? Latest 4.10 NVEnc using --bluray with 59.94 fps source, it clamps GOP to be 30 even though I specify --gop-len 60. Without --bluray it works correctly.

Rigaya is now reachable on GiHub. For NVEnc, use the issue page:
https://github.com/rigaya/NVEnc/issues