-
-
Notifications
You must be signed in to change notification settings - Fork 989
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose more nvenc and nvprefs options #1798
Changes from all commits
ee6da57
962dd20
2d6d1bb
fd7fb3a
90ad87c
0435847
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -1045,6 +1045,59 @@ nvenc_twopass | |||||
|
||||||
nvenc_twopass = quarter_res | ||||||
|
||||||
nvenc_spatial_aq | ||||||
^^^^^^^^^^^^^^^^ | ||||||
|
||||||
**Description** | ||||||
Assign higher QP values to flat regions of the video. | ||||||
Recommended to enable when streaming at lower bitrates. | ||||||
|
||||||
.. Note:: This option only applies when using NVENC `encoder`_. | ||||||
|
||||||
**Choices** | ||||||
|
||||||
.. table:: | ||||||
:widths: auto | ||||||
|
||||||
========== =========== | ||||||
Value Description | ||||||
========== =========== | ||||||
disabled Don't enable Spatial AQ (faster) | ||||||
enabled Enable Spatial AQ (slower) | ||||||
========== =========== | ||||||
|
||||||
**Default** | ||||||
``disabled`` | ||||||
|
||||||
**Example** | ||||||
.. code-block:: text | ||||||
|
||||||
nvenc_spatial_aq = disabled | ||||||
|
||||||
nvenc_vbv_increase | ||||||
^^^^^^^^^^^^^^^^^^ | ||||||
|
||||||
**Description** | ||||||
Single-frame VBV/HRD percentage increase. | ||||||
By default sunshine uses single-frame VBV/HRD, which means any encoded video frame size is not expected to exceed requested bitrate divided by requested frame rate. | ||||||
Relaxing this restriction can be beneficial and act as low-latency variable bitrate, but may also lead to packet loss if the network doesn't have buffer headroom to handle bitrate spikes. | ||||||
Maximum accepted value is 400, which corresponds to 5x increased encoded video frame upper size limit. | ||||||
|
||||||
.. Note:: This option only applies when using NVENC `encoder`_. | ||||||
|
||||||
.. Warning:: Can lead to network packet loss. | ||||||
|
||||||
**Default** | ||||||
``0`` | ||||||
|
||||||
**Range** | ||||||
``0-400`` | ||||||
|
||||||
**Example** | ||||||
.. code-block:: text | ||||||
|
||||||
nvenc_vbv_increase = 0 | ||||||
|
||||||
nvenc_realtime_hags | ||||||
^^^^^^^^^^^^^^^^^^^ | ||||||
|
||||||
|
@@ -1077,6 +1130,96 @@ nvenc_realtime_hags | |||||
|
||||||
nvenc_realtime_hags = enabled | ||||||
|
||||||
nvenc_h264_hevc_ref_frames | ||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^ | ||||||
|
||||||
**Description** | ||||||
Default value for H.264 and HEVC reference frames in DPB (decoder picture buffer). | ||||||
Override default sunshine value in situations when moonlight doesn't request one explicitly. | ||||||
Higher values can provide larger pool for reference frame invalidation on unstable networks, but specific decoders may not handle it well depending on video resolution. | ||||||
|
||||||
.. Note:: This option only applies when using NVENC `encoder`_. | ||||||
|
||||||
.. Note:: Doesn't apply to AV1 since it uses predetermined value as part of specification. | ||||||
|
||||||
.. Warning:: Can lead to (or remedy) decoding artifacts. | ||||||
|
||||||
.. Caution:: Applies to Windows only. | ||||||
|
||||||
**Default** | ||||||
Variable is unset and sunshine will pick whatever it thinks is the best. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So the default is not 5? Generally, placeholders in the config ui match the default. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Current default is constant 5, but I can't guarantee it will stay as single constant value in the future and not change dynamically depending on let's say video resolution. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Okay, if it changes in the future to an auto mode this can be adjusted accordingly. For now, I think this should be There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
|
||||||
**Range** | ||||||
``1-15`` | ||||||
|
||||||
**Example** | ||||||
.. code-block:: text | ||||||
|
||||||
nvenc_h264_hevc_ref_frames = 5 | ||||||
|
||||||
nvenc_latency_over_power | ||||||
^^^^^^^^^^^^^^^^^^^^^^^^ | ||||||
|
||||||
**Description** | ||||||
Adaptive P-State algorithm which NVIDIA drivers employ doesn't work well with low latency streaming, so sunshine requests high power mode explicitly. | ||||||
|
||||||
.. Note:: This option only applies when using NVENC `encoder`_. | ||||||
|
||||||
.. Warning:: Disabling it is not recommended since this can lead to significantly increased encoding latency. | ||||||
|
||||||
.. Caution:: Applies to Windows only. | ||||||
|
||||||
**Choices** | ||||||
|
||||||
.. table:: | ||||||
:widths: auto | ||||||
|
||||||
========== =========== | ||||||
Value Description | ||||||
========== =========== | ||||||
disabled Sunshine doesn't change GPU power preferences (not recommended) | ||||||
enabled Sunshine requests high power mode explicitly | ||||||
========== =========== | ||||||
|
||||||
**Default** | ||||||
``enabled`` | ||||||
|
||||||
**Example** | ||||||
.. code-block:: text | ||||||
|
||||||
nvenc_latency_over_power = enabled | ||||||
|
||||||
nvenc_opengl_vulkan_on_dxgi | ||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ||||||
|
||||||
**Description** | ||||||
Sunshine can't capture fullscreen OpenGL and Vulkan programs at full frame rate unless they present on top of DXGI. | ||||||
This is system-wide setting that is reverted on sunshine program exit. | ||||||
|
||||||
.. Note:: This option only applies when using NVENC `encoder`_. | ||||||
|
||||||
.. Caution:: Applies to Windows only. | ||||||
|
||||||
**Choices** | ||||||
|
||||||
.. table:: | ||||||
:widths: auto | ||||||
|
||||||
========== =========== | ||||||
Value Description | ||||||
========== =========== | ||||||
disabled Sunshine leaves global Vulkan/OpenGL present method unchanged | ||||||
enabled Sunshine changes global Vulkan/OpenGL present method to "Prefer layered on DXGI Swapchain" | ||||||
========== =========== | ||||||
|
||||||
**Default** | ||||||
``enabled`` | ||||||
|
||||||
**Example** | ||||||
.. code-block:: text | ||||||
|
||||||
nvenc_opengl_vulkan_on_dxgi = enabled | ||||||
|
||||||
nvenc_h264_cavlc | ||||||
^^^^^^^^^^^^^^^^ | ||||||
|
||||||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure we should expose this option to users (at least in this fully-configurable form). The number of reference frames is limited by the codec specification and is resolution-dependent (as you mentioned below).
It would be easy for a user to end up in a situation where they specify a value here that works for 720p then later switch to 4K and wonder why things are totally broken, or they specify a value that works for HEVC but not H.264. The issues caused by getting it wrong are going to be really hard to diagnose both for us and for users, especially since it may only manifest with packet loss.
I think if we want to expose this option, we should do so in a way that only exposes a few known good options. For now, maybe we expose "Auto" (our current behavior) and "1". If we later decide to increase reference frames up to the codec maximum for each resolution, we can either change the behavior of "Auto" and explicitly add "5" as an option or add an option for "Maximum", depending on how the decoder compatibility looks in our testing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm back from the dead, somewhat. Sorry for leaving it to you to deal with.
Now to remember my reasoning behind this option, I think it went like this
As for packet loss, I don't think it can happen because of this option since it doesn't increase the amount of data sent over the network. Decoder artifacts on the other hand are fully expected, if it goes above the maximum supported codec profile level for given decoder hardware.
Maybe just use "RFI support on/off" server-side option, with the description of what it is and the memory overhead.
But ideally, this selection should be moved to the client side, since only that side has the information about the decoder and expected network stability. It's just easier to patch one server than 10 clients, even though it's not the "proper" solution. @cgutman I'm unable allocate time to patch every moonlight client, but can make quick sunshine PR if you're ok with it? This option can be useful right now for vm-to-vm looking glass and similar scenarios.
@ReenigneArcher Sorry for disappearing (this project was consistently eating up more time I was allocating to it, so I had to pull a hard stop), but can I have the discord access back so I'm aware of the recent developments? Pretty please with a cherry on top.