Disabling look-ahead does not disable adaptive b-frames on presets P6, P7 tune hq (NVENC H.264)

sandrix

Member
Hi! We are talking about NVENC H.264. I noticed that when selecting the P6 and P7 Tune HQ presets, the look-ahead and adaptive b-frames are enabled, whether look-ahead is enabled or not. This happens not only in OBS, but in FFmpeg, I checked it. Looks like it's provided by Nvidia.

I want to suggest adding a custom settings line to control encoder options for NVENC or fix the presets.
1674136697272.png

This is not the first time I've asked for this. For now I use NVENC via FFmpeg to control this setting.
The fact is that adaptive b-frames have a bad effect on quality at low bitrates, since p-frames may be encoded too frequently, which increases the bitrate requirements.

Also would like to control adaptive i-frames which don't work at all. This would be possible by adding a line with settings.

In any case, I want to report this. And yes, I know that you can use ffmpeg or streamfx, which I do, but that's not the point.

Presenting all the evidence (OBS 29.0)
P7 HQ look-ahead OFF
1674135137497.png


When you select preset P5 and below, everything works well, b-frames are encoded statically.
P5 HQ look-ahead OFF
1674135154156.png


Also you can switch to low latency setting for P6-P7
P7 LL look-ahead OFF
1674135252115.png


NVENC HEVC P7 HQ look-ahead OFF (H.265 is fine)
1674135943795.png
 

Attachments

  • 1674135132071.png
    1674135132071.png
    440.1 KB · Views: 136
Last edited:

energizerfellow

New Member
Defined configuration variables in a given NVENC P-level preset taking precedent over any user/application-defined settings appears to be hard-coded into the Nvidia GPU drivers themselves. This may even be an intentional by-design behavior by Nvidia and not a bug per se. If so, there's nothing applications like FFmpeg or OBS can do about it.

One workaround would be to use the lowest preset number that doesn't define the variable(s) you wish to adjust, then define the setting(s) you wish to manually set.
 

sandrix

Member
Defined configuration variables in a given NVENC P-level preset taking precedent over any user/application-defined settings appears to be hard-coded into the Nvidia GPU drivers themselves. This may even be an intentional by-design behavior by Nvidia and not a bug per se. If so, there's nothing applications like FFmpeg or OBS can do about it.

One workaround would be to use the lowest preset number that doesn't define the variable(s) you wish to adjust, then define the setting(s) you wish to manually set.
This was provided by the developers, but in OBS it used to be overridden by the settings, now it is not. If you specify -look-ahead 0, -tune hq in ffmpeg, the slow and hq presets will also use adaptive b frames. Prior to OBS 28, the HQ preset was used and we could control b_adapt with the look-ahead setting, now this does not work. As I wrote in discord, now look-ahead is misleading when using presets P6-P7. To override the parameter requires b_adapt=0

OBS 27.2.4 Preset Max.Q (HQ 2_pass)
1675932043532.png
 

energizerfellow

New Member
If you specify -look-ahead 0, -tune hq in ffmpeg, the slow and hq presets will also use adaptive b frames. Prior to OBS 28, the HQ preset was used and we could control b_adapt with the look-ahead setting, now this does not work. As I wrote in discord, now look-ahead is misleading when using presets P6-P7. To override the parameter requires b_adapt=0
Look for behavior changes with the standalone FFmpeg CLI tool outside OBS for versions 4.4 vs 5.0 vs 5.1 and see if these changes are reproduceable.
 

RytoEX

Forum Admin
Forum Moderator
Developer
Hi! We are talking about NVENC H.264. I noticed that when selecting the P6 and P7 Tune HQ presets, the look-ahead and adaptive b-frames are enabled, whether look-ahead is enabled or not. This happens not only in OBS, but in FFmpeg, I checked it. Looks like it's provided by Nvidia.

I want to suggest adding a custom settings line to control encoder options for NVENC or fix the presets.

The key point in your post is here:
This happens not only in OBS, but in FFmpeg, I checked it. Looks like it's provided by Nvidia.

As you have noticed, the code provided to FFmpeg came from NVIDIA, and was part of FFmpeg 4.4 (see this commit). Per the comment there:
Code:
/* If lookahead isn't set from CLI, use value from preset.
 * P6 & P7 presets may enable lookahead for better quality.
 * */

Even if you were to set rc_lookahead to 0 from CLI, P6 or P7 would enable lookahead.

As part of a series of updates to our code, we aligned our implementation with FFmpeg's in this commit to avoid diverging behavior between the available implementations, which was part of OBS Studio 27.0. The effects of this only became noticeable with OBS Studio 28.1 when we implemented the NVIDIA Video Codec SDK 10 Presets.

As has been noticed, using either P6 or P7 result in config->rcParams.enableLookahead, and therefore use_profile_lookahead and then lookahead, being true. After that, we use the Preset's specified lookaheadDepth. As explained earlier, this is currently aligned with FFmpeg's implementation. We are considering better ways to communicate the state of lookahead, but as always, we have a lot of items to work on and never enough hours in a day.
 

sandrix

Member
The key point in your post is here:


As you have noticed, the code provided to FFmpeg came from NVIDIA, and was part of FFmpeg 4.4 (see this commit). Per the comment there:
Code:
/* If lookahead isn't set from CLI, use value from preset.
 * P6 & P7 presets may enable lookahead for better quality.
 * */

Even if you were to set rc_lookahead to 0 from CLI, P6 or P7 would enable lookahead.

As part of a series of updates to our code, we aligned our implementation with FFmpeg's in this commit to avoid diverging behavior between the available implementations, which was part of OBS Studio 27.0. The effects of this only became noticeable with OBS Studio 28.1 when we implemented the NVIDIA Video Codec SDK 10 Presets.

As has been noticed, using either P6 or P7 result in config->rcParams.enableLookahead, and therefore use_profile_lookahead and then lookahead, being true. After that, we use the Preset's specified lookaheadDepth. As explained earlier, this is currently aligned with FFmpeg's implementation. We are considering better ways to communicate the state of lookahead, but as always, we have a lot of items to work on and never enough hours in a day.
Thanks for taking the time to clarify this. I don't see this as a major problem, it's just misleading users. It would be even better if it could be managed.
 
Top