New micro-stutter issue since last update

[advocation]

Hello all,

Prior to the last update, I've been using in-home streaming without an issue. However, it appears since the last update, something has changed and I am now getting a micro-stutter in any game I try. Using the performance monitor, I still stay at a near rock solid 60 fps in all my games, and if you watch the game from the host pc, the stutter is not present. But, watching on the pc I'm streaming on, the stutter is constant and very apparent. Any idea what could be the problem? I've tried enabling/disabling all options there basically are. Both PC's are hardwired 1gig over a switch.

Host Machine: i7 4770k
290x
16 gigs ram

Current Settings on host:
"Enable hardware decoding."

Client Machine:
AMD X4 965
AMD HD 5950
4 Gigs RAM

Current settings on client:
"Beautiful (have tried all 3)"
Limit Bandwidth: Automatic (have tried other settings including unlimited)
Limit Display Resoultion: 1080p
Hardware decoding: Unchecked


Both machines have latest drivers (including GPU).

EDIT - Looking at the logs and addtional details, I'm seeing high frame loss (20%) with these errors: [2016-03-09 19:19:03] CLIENT: Marking frame 1315 complete with status k_EStreamFrameResultDroppedLate

[Polysorbate]

Until this is fixed, here's a partial workaround for couch gaming while using desktop Steam: there's a program called Controller Companion, it's $3:

http://store.steampowered.com/app/367670/
It does a very good job of allowing you to use a gamepad as a mouse/keyboard replacement for UI navigation and will automatically disable this functionality when a full-screen application like a game is running. You can also use a button combination to disable it (or re-enable it) and it'll remember which programs you enable/disable it for. It's great for games with partial controller support.

If you use it while using the Steam desktop client you can navigate it easily without needing a keyboard/mouse hooked up. If you put Steam's library view to the tile mode it's almost as good as big picture mode.

I believe you'd want to install this on the streaming client.

[Polysorbate]

Αναρτήθηκε αρχικά από Kaldaien:

Steam Link works fine for me in all modes, I don't use it very often though because it's limited to 1080p.

So it seems like probably something to do with the client machine is the problem for you, right?

[y3000]

@Polysorbate: Indeed! I use this wonderful piece of software since two weeks. Before I used the Logitech Profiler but Controller Companion ist so much better and the virtual keyboard and the game specific profiles makes it nearly perfect - so I can even play old DOS games like Commander Keen with the gamepad and can use the virtual keyboard to label the savegames within these games :)

[Polysorbate]

A new Steam Beta update came out which supposedly improved AMD hardware encoding performance, any improvement?

[Never Ready Eddie]

My post at the bottom of page 1 stated I tried another client and the problem disappeared so it is the client in my case. In the end I have given up on BPM which is a shame as it is so good. My solution now is to use a DualShock4 PS4 pad which combined with a program called Input Mapper (or DS4Windows) means the touch pad becomes a mouse track pad. Now I can easily launch games from desktop mode while on the couch.

Man I wish they would fix this though. March 8th it started!

[Polysorbate]

The fact that it seems to be random and affects both AMD and Nvidia GPUs tells me it's likely a software configuration issue unrelated to Steam. Rather than a Steam update being the problem itself, I would guess it exposed a pre-existing problem in something else. Probably something that wrongly activates based on something BPM does. A hardware power-saving mode, gameplay recording software, a driver error (video/audio/encoder/etc), the wrong GPU being activated in a multi-GPU system... there's any number of possibilities.

It's clearly not a workload limitation since you can encode from desktop just fine. It's not a BPM bug since there would be a hundred topics on the subject and it would've been addressed by now - I've seen Valve roll back updates over far less important issues. It has to be an external software misconfiguration or error, possibly not even something you did yourselves.

If I had your PCs in front of me here I'm confident I could find the common thread between them and diagnose the issue but it's hard to do it from a distance.

[y3000]

@Polysorbate: I still think it's a bug in BPM. On the specific day as the streaming suddenly stopped working correctly via BPM, the only thing changed was Steam. No hardware changes, no new or updated other software and no Windows updates has been performed between the two gaming sessions where the problem appeared for the first time.

I think today after work I can test it with the latest Steam beta update. Furthermore I now have a other graphic card (GTX 760 > GTX 1060) in my host PC ... maybe this makes the difference. I will report :)

[Dekkart]

I dont see an essential difference between a "bug in BPM" and "something that wrongly activates based on something BPM does". Actually, I agree witrh the both of you. What I would love to know @Polysorbate, is where you would search for the common thread and how you would do it. Would you look into the gpu drivers, network issues or concerned games or what? As far as I overlook this thread, we could outrule some of the possible issues already, so Im still confident we can find the one thing nobody thought of yet. So please throw in some educated ideas, and I will certainly check them out!

[advocation]

All of a sudden, all these "different" machines are having something "activate" on the same day a patch was released that broke BPM on them? The fact that it effects both GPU's tells me the opposite; it's a bug in BPM. I can see if it was a unifed set of hardware doing it (ie, power save mode on the video card), etc...but none of our machines are alike.

Again, something released in that version of BPM that broke something. Maybe it changed the way BPM works with somethin else, sure...but it was a change in BPM that caused it.

[y3000]

@Polysorbate: Even with the latest Beta update and the new graphic card (host) no improvement.

[Polysorbate]

I'm going to go a few paragraphs talking about video encoding/decoding nonsense. If you want to skip over it, go to the heading at the end where I give some additional troubleshooting steps to try and please report back with your results. Thanks.

Video codec nonsense begins:

The difference between "a bug in BPM" and "something that wrongly activates based on something BPM does" could be (making up a random example) something like, a driver update for a specific chipset looks for conditions X+Y+Z to determine if a program is running in high performance mode or not, which determines what power state that hardware runs in. Then BPM is updated to minimize its background power use in order to ensure the best possible performance in games and streaming, and this puts it under the threshold where the driver thinks the hardware should run in high performance mode.

Another random example: Steam could have switched to a new video codec which results in better performance on the host machine and thus lower streaming latency and better video appearance. However, certain client machines don't fully support hardware video decoding using this codec. The full video stream is arriving at the client, but only certain frames (the "i" frames, assuming h.264 codec) are able to be successfully decoded, while others (the "b" frames) can't be decoded. This is actually a VERY common hardware issue that people might be familiar with if they've downloaded a video off the internet and tried to play it on the iPhone or PS3.

With video encoding you can target four main things: complexity, encoding speed, decoding speed, and file size. Obviously for in-home streaming the encoding and decoding speed need to be absolutely minimized, so the remaining factors are complexity and file size. This is a difficult balancing act and someone will suffer no matter what's chosen: if you target modern video decoding hardware you can get a lower bitrate stream that'll work better for wireless networks, but you might have problems with clients not being able to fully decode the stream. If you target the broadest client compatibility, the bitrate will need to be much higher to compensate. The difference could be 50% greater bitrate requirement, maybe more.

As if this wasn't all complex enough already, different video encoders each have different ideas of what the "right" way to encode video is. A high-quality encoder will find lots of places to save on bitrate (but increase complexity) where a low-quality encoder might not. So you might have two PCs with identical hardware and software, but get completely different results if you have one using an Intel video encoder, one using a Nvidia video encoder, one using an AMD video encoder, and one using a software-only video encoder. All four video streams would have different characteristics, and if the client machine's hardware video decoder wasn't fully spec-compliant it might work perfectly fine with some of those streams but choke on others because the lower-quality encoders would produce a higher-bitrate but less complex video stream.

So you see, BPM might have simply changed its order of preference for video encoding hardware/software and this triggered a change in video encoding characteristic to something that the client machine didn't like. The difference could be something as simple as whether the host machine or client machine has their iGPU enabled or not, since the iGPU usually includes a video encoder and this may be what's at fault - or it might be the option that works, but some of you don't have one enabled or included in your CPU...

Sorry this is all so long and technical, hopefully I'm giving some idea what sort of headache it is to isolate the cause of a video codec issue.

Αναρτήθηκε αρχικά από Dekkart:

What I would love to know @Polysorbate, is where you would search for the common thread and how you would do it. Would you look into the gpu drivers, network issues or concerned games or what?

If I had the computers in front of me I'd make a disk image using Acronis or something, then format, install a fresh copy of Windows with nothing additional, install Steam, and try to stream in BPM. If it worked I'd try updating drivers, reboot, see if BPM still works. Then I'd begin installing all the old software one at a time. I'd also try different versions of Windows.

This would let me narrow the possible cause much better.

.

Please try this and report back:

On the client PC go to Settings -> In-Home Streaming. Set the quality preset to "balanced" and leave it there while doing the rest of the testing today. Next click the "Advanced client options" button. Select the "Display performance information" checkbox. Now stream a game using BPM. On the client PC, it should say something on the screen about a button combination you can press to show detailed performance information. Press it. Write down the information it says. The video encoder is especially important.

Now exit BPM and stream the same game again. If it performs properly, write down the detailed performance information again and please reply here to report what results you got from both the BPM and non-BPM streaming modes.

The above information will be very useful on its own, but if you want to be even more helpful you can continue with more detailed testing:

On the host PC go to Settings -> In-Home Streaming -> Advanced Host Options. Disable hardware video encoding. Retry streaming and write down what it says in the detailed performance information overlay. Take note of whether performance seems to be good/bad/better/worse.

On the client PC go to Settings -> In-Home Streaming -> Advanced Client Options. Disable hardware video decoding. Retry streaming. Retry streaming and write down what it says in the detailed performance information overlay. Take note of whether performance seems to be good/bad/better/worse.

If these fail, individually try each of the hardware video encoding options on the host while keeping hardware video decoding disabled on the client. Retry streaming and write down what it says in the detailed performance information overlay for each option. Take note of whether performance seems to be good/bad/better/worse.

If these fail, individually try each of the hardware video encoding options on the host while keeping hardware video decoding enabled on the client. Retry streaming and write down what it says in the detailed performance information overlay for each option. Take note of whether performance seems to be good/bad/better/worse.

Please include your CPU and GPU model(s) when replying.

Once you're done testing all these please report back to let us know if any combination worked.

[Dekkart]

Ok, sorry it took me some time to do some test runs, here come my results:

My host runs a Geforce GTX 660M and an Intel core i7-3630QM
The client is a Geforce 9650M-GT in a Intel Centrino 2 P8600 system.
Both machines are laptops, the client is hooked to a Samsung HD TV running a 720p resolution.

Positive case without stuttering is streaming Dark Souls 2 (Prepare to Die edition) without BPM. Which means: 1280x720 @ constant 55-60fps
Encoder: D3D11 NV12 + libx 264 main (4 threads)
Decoder: DXVA H.264 variable length, no film grain
Latency input ~5.97ms display ~23ms
ping ~20ms
incoming bitrate ~2100kb/s Video ~1900kb/s
outgoing 25-50kbs
-> packet loss 0% ~5% frame loss

Now when I switch into BPM, the encoder and decoder stay exactly the same, so do ping and input latency. However, display latency jumps off the chart with 250ms latency , that is 10 times the latency of not using bpm, resulting in a frame loss of ~50% and that is what causes the stuttering I suppose.
Ok, so I did some switching around in the encoder settings and surprisingly, nothing changed. The encoder always remains the same, no matter if I activate any of the hardware encoders or not. Always the same encoder and, of course, always ~50% frame loss (with bpm that is - without bpm, the frame loss disappears even though the encoder is the same).

Realising this, I tried another game, Skyrim, and indeed, it changed the encoder to Desktop DWM NV12 + Intel Quicksync D3D11. Here, the same again: Inside bpm, frame loss and display latency jump off charts while it is perfectly playable with a smooth display latency of ~25ms and 5% frame loss, which is ok for me.

So what I did not try up until then was deactivating the hardware decoder and this is where it gets interesting. Switching of hardware decoding solves the problem value-wise: display latency goes down to 50-60ms and frame loss is even reduced to 0.33%. Quite amazing numbers, but the image get heavily distorted displaying only parts of the picture and even resulting in a crash to BPM two times in a row. Also, incoming bitrates drop to 350kb/s and 190 kb/s which is roughly 1/10 compared to switching hardware decoding on.

So my guess is that this whole problem is based in the decoding, which makes kind of sense, because the gtx 660m was not built for streaming like this. Nonetheless, it should work, shouldn't it? What do you think, Polysorbate? Ready to try something else here.

[Maneauleau]

I will add my post with the same problem:

the stream lags when in BPM and works perfectly with the normal steam client

Host: Windows 10 64 bit, proc: i5, graphic card: Nvidia gtx 970, ram: 8gb ram.
Client: Windows 10 64 bits, proc: Celeron NUC, 4gb ram.

I get 1080p@60fps with no lag streaming to the client when using the regular steam client view.

When I switch to big picture mode I get some lag

:(

[Polysorbate]

Right-click steam.exe (probably in C:\Program Files (x86)\Steam), say "create shortcut". Then right-click the new shortcut and say properties. Add these to the target: "-windowed -tenfoot"

It should look like this: http://i.imgur.com/G2eCh94.png

How does streaming perform when Steam is launched this way?

[Dekkart]

Tried this client-side. Steam directly launches into windowed bpm, streaming issues persist as described above. Frame loss in menus drops to 30-40%, but in motion goes back up to 50%.