Sorry about external link on Gist, logs are pretty big, don't know better way. I can share them any other preferred way.

Ah, the Bravia... my nemesis.

Out of mild curiosity, if you go into the streaming settings and *disable* Low Latency Video, does it correct the issue? I'd bet you that the low-latency codec on the Bravia is falling behind after a sufficiently long time, and given that support for the low-latency video mode was only added around 1.3.20...

If that fixes it, we'll probably want to add some blacklisting to prevent that mode from being enabled on Bravia TVs... :|

J'ai le meme soucis que vous depuis la dernière mise a jour sur ma TV Sony bravia avant la dernière mise a jour tout étais parfait

Originally posted by Packetdancer:

Ah, the Bravia... my nemesis.

Out of mild curiosity, if you go into the streaming settings and *disable* Low Latency Video, does it correct the issue? I'd bet you that the low-latency codec on the Bravia is falling behind after a sufficiently long time, and given that support for the low-latency video mode was only added around 1.3.20...

If that fixes it, we'll probably want to add some blacklisting to prevent that mode from being enabled on Bravia TVs... :|

I installed version 1.3.31 to see what it was.
Are you referring to the "Low Latency Video" option? That option is available in version 1.3.31 but not in version 1.3.20. So that checks out.
However, I can't disable it. I can only set it to "Enabled" or "System Default." In either case, display latency is broken unless the decode pipeline is flushed by toggling the HW decode.

So, yeah, I suppose your bet is very much valid.

Originally posted by Fecalius de Pump:

However, I can't disable it. I can only set it to "Enabled" or "System Default." In either case, display latency is broken unless the decode pipeline is flushed by toggling the HW decode.

Anything that renegotiates the stream would work here, fwiw, because the stream gets torn down and recreated on renegotiation (since things like the colorspace, codec, etc. cannot always be changed for an active codec session). Toggling HW decode is just probably one of the fastest ways to do it.

As for what's happening on the Google TV, to elaborate slightly...

Prior that option being added, Steam Link's behavior was:

1. Ask for something that'll decode "video/<fmt>" ("video/hevc" or "video/av1" or whatever) and take whatever it gets
   
2. Try to enable low-latency support in that codec, by setting a bunch of various low-latency codec options we'd found

On many things (Amazon Fire TV devices being a notable offender here, ESPECIALLY the Cube 3rd Gen), doing that meant you got a high-quality codec with *extremely bad* latency. (Because it was meant for streaming, like, Prime Video.)

That wasn't great. So the changes made were:

1. If set to "System Default" still just take whatever the system gives you.
   
2. If set to "Enabled", walk through all available codecs for a given video format and find one that explicitly has the low-latency feature flagged.
   
3. In either case, try to enable low-latency support in that codec, by setting a bunch of the most common low-latency options. This included a couple of *new* low-latency bits we found, one of which was defined by Google.

My *hope* was that the "System Default" on the Streamer 4K might be a non-low-latency version of the codec (e.g. one that ignores the low-latency bits), but my *fear* (which your test pretty much confirms) is that the problem is instead that it gets bogged down when low-latency is enabled and runs for a long time... and that the low-latency mode is in fact keyed off of one of the new bits that gets set. So on 1.3.20 it wasn't using the low-latency mode of the codec, but in later ones it is.

Soooo, guess it's time for a third option for that setting, "Disabled", which skips setting those bits entirely.

Originally posted by Packetdancer:

Originally posted by Fecalius de Pump:

However, I can't disable it. I can only set it to "Enabled" or "System Default." In either case, display latency is broken unless the decode pipeline is flushed by toggling the HW decode.

Anything that renegotiates the stream would work here, fwiw, because the stream gets torn down and recreated on renegotiation (since things like the colorspace, codec, etc. cannot always be changed for an active codec session). Toggling HW decode is just probably one of the fastest ways to do it.

As for what's happening on the Google TV, to elaborate slightly...

Prior that option being added, Steam Link's behavior was:

1. Ask for something that'll decode "video/<fmt>" ("video/hevc" or "video/av1" or whatever) and take whatever it gets
   
2. Try to enable low-latency support in that codec, by setting a bunch of various low-latency codec options we'd found

On many things (Amazon Fire TV devices being a notable offender here, ESPECIALLY the Cube 3rd Gen), doing that meant you got a high-quality codec with *extremely bad* latency. (Because it was meant for streaming, like, Prime Video.)

That wasn't great. So the changes made were:

1. If set to "System Default" still just take whatever the system gives you.
   
2. If set to "Enabled", walk through all available codecs for a given video format and find one that explicitly has the low-latency feature flagged.
   
3. In either case, try to enable low-latency support in that codec, by setting a bunch of the most common low-latency options. This included a couple of *new* low-latency bits we found, one of which was defined by Google.

My *hope* was that the "System Default" on the Streamer 4K might be a non-low-latency version of the codec (e.g. one that ignores the low-latency bits), but my *fear* (which your test pretty much confirms) is that the problem is instead that it gets bogged down when low-latency is enabled and runs for a long time... and that the low-latency mode is in fact keyed off of one of the new bits that gets set. So on 1.3.20 it wasn't using the low-latency mode of the codec, but in later ones it is.

Soooo, guess it's time for a third option for that setting, "Disabled", which skips setting those bits entirely.

Thank you Packetdancer.

Since the new updates to Steam Link, i've experienced frame loss on my Formuler Z11 Pro Max, but after changing low latency video to system default the frame loss went back to 0% again. Many thanks!

I think I'm having the same issue on my 2021 Bravia TV

For those who are having this issue, can you check to see whether you have bandwidth set to "Unlimited"?

If so, can you try setting it to "Automatic" and see if that fixes the issue? If so, can you please make sure you are using Steam Link version 1.3.32 or newer, opt into the Steam beta client on your PC, switch it back to "Unlimited" and see what happens then?

Please let us know!

Also, it got left off of the beta patch notes, but the aforementioned "Disabled" setting is now in the Android beta build. (See my giant post several comments back in this thead for context.)

For those experiencing the gradually increasing frame loss/latency, I'd be curious if switching Low-Latency Video to the new 'Disabled' option in the streaming settings on the Android side makes the problem go away.

Sorry for the late response. I didn't have access to my PC / TV for a while.

I installed version 1.3.32 BETA and tested it in various configurations. Personally, I don't see any patterns in the results. I should mention that many things have changed in the overall setup since my first post. Lots of other things have been updated, and I think the TV itself has received some updates.

TL;DR: The regular degradation in decoder latency has sort of gone away.

I tested with Low-Latency Video "enabled" and "disabled" with no effect. All observations below are applicable to both options. During the tests, I set the bandwidth to 75 MB/s, the FPS to 60, and the resolution to 1080p.

If the stream starts successfully, no matter how long I sit in Steam menu, no degradation happens. However, sometimes the stream has excessive decode latency right from the start. Restarting the stream sometimes helps and sometimes doesn't, and I have to restart it several times (or toggle HW decode).

I tested "System Shock," and it played well with no latency issues during the game. However, quite often, the latency degrades when I close the game. Also, sometimes the image is all scrambled at the start of the game. Restarting the game often helps.

I also tried playing Elden Ring, but it failed to start. The stream just freezes right before the first splash screen with the developer's logo (black or white screen on a TV), and the stream details show a weird resolution: 800x480. I would have assumed this was a host-side problem, but I can play Elden Ring on my phone with no issues.

I tried enabling SteamRT3, and I see the latency degradation happening on a two-minute schedule, as before. Disabling or enabling Low-Latency Video again does not make a difference.

Is there a list of "good" TVs for Steam streaming? xDD

Jokes aside I can gather logs if you tell me which logs (on host side or on TV) and which configs to target.

Originally posted by Fecalius de Pump:

Is there a list of "good" TVs for Steam streaming? xDD

My personal list probably starts with "does not have 'Bravia' anywhere in the name." (Slouken will laugh on reading this, I suspect.)

More seriously, I don't really like *any* of the Android-powered TV options, personally -- largely because in my experience many have focused on codec implementations that favor *quality* over *latency*, even when they claim to support low-latency. (Which, in fairness, is reasonable for their actual purpose -- their general 'streaming video' case is watching something from Netflix or Amazon Prime or whatever, and you don't care if there's even a full *second* of latency between hitting 'play' and the stream starting in that use case.)

I just also don't have the same visceral "oh god what fresh hell" reaction with most of the Android smart TVs that I get when I see the word 'Bravia' turn up in a post, because it feels like Bravia TVs are the source of like... a solid 50% of all the weird latency and strange behavior that gets reported with Android-powered smart televisions.

I've found much better luck *overall* with external Android TV boxes (Nvidia Shield TV usually works quite well, for instance) where low-latency codecs tend to actually be low-latency codecs. Or even just using a Raspberry Pi and running the Pi version of Steam Link.

Originally posted by Fecalius de Pump:

Jokes aside I can gather logs if you tell me which logs (on host side or on TV) and which configs to target.

On the host side, you'd want streaming_log.txt which will be in Steam's "logs" directory. If you're on Windows, that'll be somewhere like C:\Program Files (x86)\Steam\logs most likely, unless you installed Steam somewhere weird. I'd just remove that log before you start streaming, and then if the session has things go Wrong And Bad, save off the streaming_log.txt to send.

On the TV side, if you've got adb access to the television, you can just use adb logcat and watch the com.valvesoftware.steamlink package. You can also watch all of logcat (in case anything turns up in system logs rather than the Steam Link ones), but as Android is... uh... "chatty" in logfiles, it's a bit like trying to drink from a fire hydrant.

Here are logs: https://gist.github.com/fviolence/f98f4013aac6d6b260b79191e5ee74d0

Low-Latency Video was disabled.

Stream started normally. Then I launched a game (System Shock) and stream degraded right from game's start. Latency and frame loss spiked. This continued in steam menu after I closed the game. I managed to "cure" the stream by opening left side menu in steam. For whatever reason (when streaming to the TV) this menu opens in the middle of the screen with two wide vertical black bars to its' sides, not like it normally should in BigPicture mode.

So, the log definitely shows something I've seen with the Bravia here before, which is that the codec is actually taking slightly longer than it should per-frame, and so falls increasingly behind the longer the stream actually goes.

Resetting the stream in any way (e.g. toggling any setting that causes the stream to be ended and restarted) will of course temporarily fix it, because now you have a fresh stream and it starts falling behind again from the original zero point.

One of the ways to reset the stream is to change the resolution; that will cause the stream to be ended and started fresh. Because of how Big Picture works and how gamestream capture works, opening the Big Picture menu will do this.

As a side note: the reason that happens is that the menu is technically a separate window, and the Linux gamestream capture is in the efficient capture-only-one-window mode, but that causes it to only capture the menu while the menu is open. (I'd like to eventually change that, but it's a LOT of change for a fairly minimal gain, so it's not really high priority. Plus it's actually helped to expose a LOT of weird behaviors with odd resolutions...)

ANYway. All of that tracks with what you were seeing and what I saw in your log. You can even see the messages where Steam Link is like "hey, we are running way behind where we should be" and periodically trying to drop frames and request a keyframe to catch up, but the codec never really fully recovers so it ends up in an endless cycle of falling behind far enough that it dumps frames and requests a keyframe, and...

At any rate, what I would recommend actually trying here is maybe adjusting the bandwidth in streaming settings to turn it down from unlimited or auto, and see if that helps at all? Feeding the codec a bit less raw data helps with the Bravia here, so...

I don't know if this shows up in the logs in any way, but I was using a bandwidth limit of 75 Mb/s. As an experiment, I just tried running a stream at 25 Mb/s, and the result was exactly the same - the stream cuts out immediately after game start.

I’d also like to note that the nature of the problem has changed somewhat since my first post. Previously, the stream would "degrade" as if on a timer, every 2 minutes or so. Now, I can stay in the Steam menu for as long as I want, and everything is fine. But as soon as I launch the game, there’s a spike in latency and frame drops.

Moreover, the problem doesn’t occur in all games. So maybe disabling the low-latency codec helped, but there’s another issue with similar symptoms.

I collected more logs with the bandwidth capped at 25 Mb/s (logcat is so big, I had to split it into 2 parts): https://gist.github.com/fviolence/a3fd4dc7d36b7e7d2659c84c1e49ec61

Again, I don’t understand what changed, but Elden Ring started working for me - it streams quite successfully. So I recorded logs from launching Elden Ring, then launched System Shock in the same session and reproduced the stream "breakage".

I ran the logs through the chatgpt, and it produced the following observations regarding the differences in how the games launched.

During the Elden Ring launch, the stream briefly changes from 1920x1080 to 800x450 and then back to 1920x1080. This resets the decoder, but it recovers and the stream remains stable.

System Shock behaves differently. The repeating frame drops begin immediately after Steam switches the video source from `Desktop_MovieStream` to `GameOverlay_MovieStream_11407`. There is no actual resolution change logged before the first video overflow. The client then repeatedly reports roughly 270–380 ms of queued video, requests keyframe synchronization, and drops frames due to codec resets.

The problem also continues after System Shock is closed and Steam switches back to the desktop stream.

Not sure what to take from it, hope it can help somehow.

Hm. Could you try changing System Shock's resolution in the settings, then changing it back, just to see what happens?

The Elden Ring 1920x1080 -> 800x450 -> 1920x1080 is almost certainly due to a loading splash screen during startup; I see the same sort of thing with a lot of games, as Steam first captures the little splash screen (which doesn't take up the whole screen) and then swaps to the actual game window once it appears.