[Bug] Extreme image corruption when streaming at 60fps over USB

[christopher317]

Describe the bug
when streaming at 60fps over USB, very intense image corruption can be seen in the client preview.
( issue likely not unique to USB )

To Reproduce
follow the steps shown in #147
restart your switch to apply the changes
start streaming any game
observe a sharp drop in viewability when looking at the stream in the SysDVR client.

Expected behavior
a smooth stream free of artifacts is displayed

Setup information

• PC Os: Linux Mint 21.3
• Console firmware: 16.1.0
• Custom firmware name and version: Atmosphere 1.5.5
• SysDVR version: 6.1.0 ( 6.1.1 client )

Additional context
said image corruption isnt observed in recordings produced by the SysDVR client, demonstrated in attached video clips.

system_settings.ini, modified for 60fps streaming ( #147 ) and higher bitrate:
system_settings.ini.zip

expected result ( recording produced by the SysDVR client, compressed ):
expected.webm

actual result ( recording of stream shown to the user by the SysDVR client, compressed ):
actual.webm

[exelix11]

I think this has the same root cause as #91 and it's caused by the increased bitrate, can you try without that ?

[christopher317]

I think this has the same root cause as #91 and it's caused by the increased bitrate, can you try without that ?

the issue persists with the default bitrate of 5mbps ( i commented out the line that modifies the bitrate )
i found that enabling "uncap streaming framerate" almost completely removes the corruption when in motion but not nearly as well when static.
also, the corruption isn't nearly as bad in a static scene with the default of 5mbps but is still there.

[exelix11]

Ok yeah I forgot about uncapping the framerate, that takes care of half the problem.

The rest is definitely the issue I linked before, I guess I'll bump the capture buffer a little more or look into the possibility of making it dynamic.

Thing is as a sysmodule we don't have much space and the more I allocate to video capture the less is there for the system and other sysmodules, as of now sysdvr and ldnmitm are already partially incompatible so I'm not sure about increasing the capture memory even more. Increased bitrate will likely never be supported officially.

[christopher317]

I dont think the problem is the buffer being too small on the console
the clips I sent had the bitrate modified to 20mbps and the corruption is almost completely unnoticeable in the first video that was captured with the recording function built into the app. There is a tiny blip near the end at about 39 seconds that could be caused by the capture buffer being too small, but the rest of the video is pretty much artifact free despite the bitrate being 4x normal.

expected result ( recording produced by the SysDVR client, compressed ):
expected.webm

[exelix11]

My bad, from your previous post I thought that uncapping the framerate solved most of the glitches, can you make a new recording of how it looks now ?

I can't think of other possible causes, transfer speed bottleneck maybe ?
The recording that sysdvr produces is not re-encoded and contains the exact data received from the console, if that plays fine then it's a rendering/decoding issue (missed this important detail before).

I'll have to think how to debug this, I'll also try to reproduce your configuration. Just to be sure if you reset your system config to default does sysdvr work as expected?

[christopher317]

Just to be sure if you reset your system config to default does sysdvr work as expected?

yes, it works as expected with default client and system_settings.ini settings.

I'll also try to reproduce your configuration.

if i remember correctly, the settings i used were:
60 fps and 20mbps ( via system_settings.ini, im gonna use ~12mbps for now so the clipping feature is still somewhat useable )
i did not use uncap streaming framerate, but will now as it significantly reduces visual artifacts
and it probably doesn't matter but i set the recording location to a folder on another drive.
edit: im also using the DVR patches.