Nvidia HEVC problems

[Urik]

Well, it scales but not linearly, I guess. These are Kb/s. It's a short 4k60 VFR clip, not much movement.


original          44071k

target          result
5000k          1676k
15000k          1907k
35000k          2061k
250000k          3738k

[Urik]

In other words: inserting the "Resample FPS" filter with a standard target FPS value should always(?) work around the problem.

Yes, just tried and confirmed. Tested on same 4k60 game clip and phone 4k30 clip. When adding the filter, in the value window, the framerate was initially fractional, like 60.12 or 30.02, so obviously I changed it to 60 and 30. I used CBR with target of 50Mb/s. The end files came with approx. 46Mb/s and 51Mb/s bitrates, which is about the same kind of +- variance I would normally get with VBR target (I guess there's also how ffprobe/mediainfo counts it)

[eumagga0x2a]

Thank you very much, the ball is in my park then, timebase != 1/fps messes up rate control.

[eumagga0x2a]

@Jiehfeng, @Urik, I've changed the way how time base is calculated in the core video encoder code mostly back to the state of affairs prior to [coreVideoEncoderFFmpeg] Use fraction to convert between microseconds and lav ticks, use timebase from FilterInfo instead of deriving it from frame increment to set context, remove redundant timebase-related part of presetContext().

Once fresh nightlies become available, please test and provide feedback whether the change helps with HEVC NVENC encoder and if it does, whether the present-based rate control becomes viable or only the usual CBR, CQ and VBR modes are functional (and whether 2-pass works).

Thanks a lot in advance.

[Urik]

Cool, will do.
Does that mean that h264_nvenc and hevc_nvenc behave in a slightly different way, since you mentioned before the Avidemux code is kind of similar for both? Since it wasn't affecting h264_nvenc.

I've got a few more questions, just of curiosity

1) why is GOP length limited to 250 for both encoders in Avidemux? Is there actual nvenc-related reason, or is it because 250 is one of common/default values for FFMPEG? I haven't found any info on what the max value can be for ffmpeg or nvenc, the max I tried myself was 300 (through ffmpeg)

2) -rc-lookahead, assuming it's undefined, it means the encoder decides itself which value to use (auto)?
3) in VBR mode, how is -buffsize set?

Personally, I've been following very rudimentary rules of having lookahead equal GOP length, max bitrate=target bitrate*1.5 and buffsize=max bitrate*2 just off what I've read online

[eumagga0x2a]

Oops. I see, dual-pass is currently completely fake both in H264 NVENC and HEVC NVENC encoder plugins (it is not setup as such at all), and when implemented, it doesn't work (the stats file is empty). rc-lookahead needs to be added.

Will try to fix all that ASAP.

[eumagga0x2a]

A brief status update: the H.264 NVENC part is mostly done, will start with the HEVC one shortly. Most options I add I cannot test on my equipment, so take some fun once the changes land and nightlies get refreshed for granted.

1) why is GOP length limited to 250 for both encoders in Avidemux? Is there actual nvenc-related reason, or is it because 250 is one of common/default values for FFMPEG?

No particular reason, maybe just personal preferences for seek granularity. 250 is indeed the default GOP size value FFmpeg sets for *_nvenc if the user doesn't ask for a different one. I've increased the limit to 1000 in my local codetree now.

2) -rc-lookahead, assuming it's undefined, it means the encoder decides itself which value to use (auto)?

Presumably lookahead (when supported) is completely disabled then. Unsure, though. BTW, maximum lookahead value supported by NVENC is 31 the number of consecutive B-frames subtracted.

3) in VBR mode, how is -buffsize set?

It is set to twice the average bitrate.

[Urik]

BTW, maximum lookahead value supported by NVENC is 31 the number of consecutive B-frames subtracted.

Interesting. I looked up some official Nvidia docs and indeed they mention it "can be up to 32". Many forum posts online specifically list 32 in ffmpeg syntax. Before I didn't even think to specifically look for nvenc lookahead info, thought it's the same as the one for x264 or whatever. Turns out there's plenty of interesting stuff in official Nvidia documentation I didn't care to read before.

[eumagga0x2a]

The setup of the both NVENC encoder plugins has been reworked now: [ffNvEnc] Fix numerous issues in encoder configuration, add more options, deduplicate code, only the H264 part tested so far and only on Linux.

[eumagga0x2a]

A fresh win64 nightly has been uploaded, please test.

https://avidemux.org/nightly/win64/

[Urik]

I've tried it and I'm a bit confused, is bitrate input field supposed to be available when RC Mode is set to Controlled by Preset? That applies to both HEVC and h264 nvenc options.
So with defaults being 5000 for HEVC and 10000 for h264, the output gets that exact bitrate, kind of like VBR/CBR mode. (I left preset at High Quality at all times but it doesn't seem to make a difference)

[eumagga0x2a]

is bitrate input field supposed to be available when RC Mode is set to Controlled by Preset?

Yes, it must be available. It was my error to disable it, I misunderstood the description of the corresponding option in *_nvenc encoders in libavcodec. Presets control the strategy how the encoder tries to achieve the goal, not the goal itself. The bitrate specifies the desired average bitrate then.

Have you checked whether lookahead works with your hardware? If enabled (and supported), it should result in keyframes being placed not simply at fixed intervals but depending on changes in picture content.

[Urik]

Have you checked whether lookahead works with your hardware?

I'll check soon, I've been caught up in reinstalling windows last couple days

If enabled (and supported), it should result in keyframes being placed not simply at fixed intervals but depending on changes in picture content.

Is that what it really does? I've been using it in ffmpeg and voukoder plugin, and I used to think that it just affects bitrate prediction in VBR/CQP modes.
Then, more recently, I read this in Nvidia's guide for OBS, where lookahead is just an on/off switch

This allows the encoder to dynamically select the number of B-Frames, between 0 and the number of B-Frames you specify.

So you're saying it affects scenecut? I thought that's controlled by -no-scenecut (in ffmpeg) alone, or it's different since Avidemux's dealing directly with nvenc?

[eumagga0x2a]

My graphics card doesn't support lookahead and keyframes are always placed at each keyint-th frame, no matter what the content and how detrimental the choice may be for compression. This means -no-scenecut has no effect as it tries to disable a feature which doesn't exist in the first place. In my understanding lookahead = 0 disables scenecut detection as well, but I may be easily wrong here as I cannot test myself.

Avidemux just wraps libavcodec *_nvenc encoders, it doesn't interact with NVENC directly.

[Urik]

It seems you are right, from what I tested. I used a short test clip with two definitive scene cuts. With lookahead at 0 there were no I-frames placed, then I tried lookahead of 31 and 10, and they were placed exactly where needed.
I tested both h264 and hevc, some were with VBR and some with just high preset + target rate. Maybe I tested CQP too, I don't remember.
I used to think that scene cuts were always on by default, or at least on "better" presets. With voukoder plugin (ffmpeg-based) and my ffmpeg scripts I just always used "slow" preset so I thought that makes the difference, because I had the auto I-frames. I guess this could've been just because I always specified lookahead.

Nvidia's Shadowplay screen recording software has no scenecut I-frames, GOP of 30 (at least for 60fps) and no B-frames. So, presumably they don't use lookahead then. Adobe added nvenc export into their software this year, and it's the same story there.

Just to clarify, when you say libavcodec, it's the same thing that's in FFMPEG, right?

One more thing, in Avidemux, for both encoders, in variable bitrate mode, Quality value entry field is now unlocked, which confused me again. Is it supposed to be this way? It has an effect even in VBR mode?