Try the beta that was just posted (1.3.26) and let me know if that works better? I'm *pretty* sure the fix for AV1 performance will actually apply in this HEVC case, based on your streaming_log, but that's like... 96% sure, not 100%.

I updated to version (1.3.26), but unfortunately it didn't help. I uploaded a new log file.

Ugh. So, to elaborate a little on what your log shows (and why I hoped the .26 beta would fix it)...

In your logs, you can see that every second or so, there's a message about video overflow. What that means is that the codec is not actually *decoding* the video fast enough, so it falls further and further behind, and when eventually it's got 150ms of video its working on and saying "hey wait, I'm not done with that first part yet" eventually Steam Link says "okay, let's just get a new keyframe, reset the codec, and try again."

Now, that can happen in normal use -- sometimes there's a spike in network latency or whatever -- so the behavior of "we have too much data, reset to a new keyframe to catch us up" is intended. But that's a "oh, this might happen a few times across an entire gaming session" thing, not something that should be happening every second.

This is often a symptom of it trying to use a codec that claims to support low-latency video (e.g. speed of decoding), but which lacks hardware acceleration, so cannot actually decode as quickly as needed and falls behind.

Picking a codec like that could happen with the 1.3.25 build. So 1.3.26 will ignore any video codec that claims to support low-latency if it is not *also* hardware accelerated. I was *hoping* that was what was going wrong for you, but it doesn't appear to be the case.

If you feel at all comfortable with Android development tools, I'd be very curious to see a logcat output for when you start streaming. (Since there will probably be some log entries on the Android side external to the app itself, as the codec being used will likely be complaining about *why* it is falling behind.)

I added logcat.txt to Google Drive

Well, on the plus side, that's definitely using hardware encoding!

At this point, I guess I'm just not sure the codec in question can handle 120 fps on that hardware (or possibly your host machine can't handle encoding at that rate). So, next step I would try would be lowering the frame rate to 90 or 60 in the Streaming settings and see if that improves things.

Thanks a lot for the help!

I set the stream to 60 FPS and now everything works perfectly stable. I also tried 90 FPS, but the artifacts were still present, so it seems like my device just can’t keep up at higher frame rates.

60 FPS is perfectly fine for me, so I’ll stick with that.

Appreciate the assistance!

Glad it was a simple solution in the end!