[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.

[eduardoibarra960]

I've got the same issue, I found the issue to be tied to the platform the Client run on.

This error occurrs on Android TV both on 32 bits OS (Build-in GoogleTV on Hisense TV and Amazon FireTV Cube 3rd gen) tested with a build I found here, also on a Lenovo Legion Go running latest Windows 11, the three devices were tested on WiFi and Ethernet (Router is a WiFi 7 TP-Link GE800)

Only device working properly is a Samsung Galaxy S23 Ultra with the latest apk release, it works perfectly even with the slower 2.4Ghz signal without delay nor corruption

[exelix11]

With version 6.2 i added more error reporting to better debug this issue, while it's not a fix it should exclude some errors on the console side. They are part of verbose logging that can be enabled from the settings, on windows you can add --debug log to the commandline.

[exelix11]

Another update on this: a user on discord solved a similar issue by changing the video decoder using the option in the advanced settings, this might be relevant on less powerful hardware.

[Sky7734]

This is always been a problem across many versions at default settings regardless of game with my device. Over USB it's smooth and artifact free when in motion, but starts to glitch when there is little motion on screen. Over LAN it looks like the video initially showed as the bad example all the time. Enabling uncap streaming framerate does help but changing the codec and such either results in no stream or the same result. If I need to provide more information I'd be happy to provide whatever necessary.

[exelix11]

There has been a number of causes documented for this issue. Imo the real answer is that 60fps is not supported because sysdvr was not developed for it in mind, most notably:

• The problem you describe in USB mode is probably #91 and it happens when the keyframes are too big for the current image capture buffer. You can confirm this by running sysdvr client with the --debug log option, it should show an error whenever we drop a packet and how much memory would have been needed.
• The problem over network is probably because our socket buffers are too small to provide a fluid stream with the TCP overhead. For this i don't currently have a way to reliably debug it.

To fix them we'd need to increase the size of both buffers and that would increase the memory usage of the sysmodule, given also the new limitations on memory of 21.0 i don't think that's desirable for most users.