Closed LuisB79 closed 2 weeks ago
I think I narrowed down the problem to the presence of Padding OBUs. It seems like Qualcomm did not test their decoder with AV1 bitstreams containing padding OBUs (common for CBR encoding, but not otherwise).
We don't have control of padding OBUs for all encoders (notably not FFmpeg NVENC or VAAPI), but we might be able to strip them off after each encoded frame.
I think I narrowed down the problem to the presence of Padding OBUs. It seems like Qualcomm did not test their decoder with AV1 bitstreams containing padding OBUs (common for CBR encoding, but not otherwise).
We don't have control of padding OBUs for all encoders (notably not FFmpeg NVENC or VAAPI), but we might be able to strip them off after each encoded frame.
Does padding obus are also present when a stream is created in the windows app?, because i can decode the stream on the android client when the stream is created in windows, i was thinking that maybe it was something with a color space mismatch, or something nvenc specific, also i noticed that in line 344 of nvenc.cpp theres a ? sign and the android logs said something along the lines of "[v4lav1DL_26] ? is not a supported pixel format!"
Does padding obus are also present when a stream is created in the windows app?
No, because our standalone NVENC implementation used on Windows disables padding OBUs. The bitstream produced in both cases is completely valid, but Qualcomm's decoder does not properly implement the AV1 specification and fails to decode a valid bitstream if it contains padding OBUs.
I confirmed the issue was only the padding OBUs by patching FFmpeg to avoid setting NV_ENC_CONFIG_AV1::enableBitstreamPadding = 1
. This was enough to enable my Fold 6 to decode the stream successfully.
Does padding obus are also present when a stream is created in the windows app?
No, because our standalone NVENC implementation used on Windows disables padding OBUs. The bitstream produced in both cases is completely valid, but Qualcomm's decoder does not properly implement the AV1 specification and fails to decode a valid bitstream if it contains padding OBUs.
I confirmed the issue was only the padding OBUs by patching FFmpeg to avoid setting
NV_ENC_CONFIG_AV1::enableBitstreamPadding = 1
. This was enough to enable my Fold 6 to decode the stream successfully.
Great!, should i add something to the sunshine.conf file? or will a new version of sunshine be released to take into account OBUs on qualcom devices?
Also, is it possible to make a bugreport to qualcom or samsung?
Great!, should i add something to the sunshine.conf file?
There's no config option for this. It will be fixed in a future release.
Is there an existing issue for this?
Is your issue described in the documentation?
Is your issue present in the latest beta/pre-release?
This issue is present in the latest pre-release
Describe the Bug
Sunshine on arch produces an AV1 stream that it's not able to be decoded on a snapdragon 8 gen 3 soc, no matter what resolution is set or what framerate is set
Expected Behavior
Sunshine on arch producing an AV1 stream that's able to decode on snapdragon 8 gen 3 soc.
Additional Context
I installed as per the documentation instructions, this is not the aur package. On windows the stream is being produced by nvenc and it's able to be decoded on the same hardware One noticeable difference is that in windows there's a message saying "NvEnc: created encoder AV1 p1 two-pass rfi", where as in linux there isn't one
Settings on arch X11 NVFBC as capture NVENC as encoder
Client moonlight-android running on a zfold 6 Client works fine with h265 or h264
related: https://github.com/moonlight-stream/moonlight-android/issues/1434
Host Operating System
Linux
Operating System Version
Arch
Architecture
amd64/x86_64
Sunshine commit or version
Version v2024.1025.12635
Package
Linux - LizardByte/pacman-repo
GPU Type
Nvidia
GPU Model
4080 mobile
GPU Driver/Mesa Version
565.57.01
Capture Method
NvFBC (Linux)
Config
Apps
No response
Relevant log output