Hi, all, can someone define exactly what the "hardware encoding/decoding" is meant to do in your Steam In-Home Streaming setup?

I am streaming from a higher-end rig (i5 4690k and SLI 970s) to a bare-bones HTPC (dual core Celeron, no discrete graphics) over hardwired gigabit (soon to be AC wifi as I will be moving it to another room).

Based on this setup, would enabling hardware encoding/decoding be advantages or not?

-R.

Hardware encoding uses your GPU's built-in h.264 encoder in order to send video to the client. It may or may not provide better quality. For your client with that old CPU you will need to leave hardware decoding off.

Just try different combinations until you find one that looks and performs the best. After all we're only talking about one on or off setting on two different machines, it's not like it is going to take you a long time to figure out which setting is working the best.

If you can't tell a difference then it doesn't matter. Personally, I use hardware encoding and see no difference between turning hardware decoding on my clients on or off. I even stream to a Macbook with no discrete GPU and I still get 60 FPS and good quality on WiFi.

Yeah, I am not seeing much of a difference either way, but I'm not getting a stable 60 FPS, either. Would it make sense to get a super cheap discrete Nvidia card for the HTPC to utilize the hardware encoding done on the host? You can get an Nvidia GeForce 210 for like 30 bucks. I want to keep the HTPC's heat, noise, and power level down, and that card wouldn't really impact any of those variables. I wonder if it would improve performance, though. If it did, I'd totally go for it (I guess I can try it and return it if it doesn't make a difference as Amazon is pretty good with stuff like that).

-R.

The hardware (h.264) encoder on the GPU is a dedicated block of silicon that just does video encoding. So enabling hardware encoding does not take (significant) resources away from the GPU for rendering the game (although it will push up the thermal load, even if that silicon is super-efficient, so can have some impact on perf). There is very little benefit to trying to get a second, cheap GPU to act as a dedicated encoder (even if that is a supported configuration, which I'm pretty sure it is not). Right now it makes a lot of sense to encode the video on the GPU, where the frame is being generated for scan-out onto your monitor, before pushing it down the PCI-Express bus to save onto HDD (ShadowPlay) or stream down a network (ShadowPlay or Steam IHS). This may be slightly complicated by SLI (but I assume that the GPU which is physically outputting the video is the one that uses the video encoding hardware and it all works out ok - maybe Google to confirm this isn't horribly broken and SLI is a niche config and Valve only just started supporting nVidia hardware encoding via the NVENC API with Steam IHS).

The alternative is pushing the full frames down the PCI-E but to the CPU and then either using hardware encoding (branded QuickSync) on your CPU or not (the software fallback that runs the encoding algorithm using the general purpose area of your CPU). So even if you aren't going to use the GPU encoder, you still want Steam to be using the hardware encoder path to use you Intel silicon efficiently.

Of course, a lot of games are GPU-constrained and so the CPU has extra processing headroom to do video encoding at the same time without performance loss. So you don't always see software encoding as being worse, but the way the hardware is organised it should be the least efficient way of doing Steam IHS. Best case (assuming everything is working as intended - IHS is still under development and the beta client seems to get tweaks every week to fix stuff) then not using hardware encoding is going to be making your CPU run slightly hotter and perform the same, worst case the game will have a worse fps than if you enable hardware encoding (with your level of equipment).

So that was hardware encoding on your "server" (machine rendering the game) - I've split these up to make it easier to conceptualise. Choosing to use hardware encoding and choosing to use hardware decoding are completely independent choices (made on the local machine) for Steam IHS. There are 4 combinations you can test, although I suggest that enabled/enabled is the likely best choice to make.

Hardware decoding is the dedicated silicon on the CPU or GPU that decompresses the h.264 video stream back to full-frame video. This is something so ubiquitous that basically every device you own with a screen supports it. Just with encoding, having dedicated hardware is more efficient than using general purpose silicon ("software") for the task. That's where this rose to prominence: mobile phone processors needed a way to show video and would eat their battery to do it "in software" so they got dedicated silicon. Everything else follow suite.

While the video encoding hardware (QuickSync) in Celerons is disabled, the hardware decoding is still enabled. This should be switched on to reduce the power/heat in your HTPC when using Steam IHS. Just as with encoding, this assumes the Steam software is configured to work well with your hardware but the likely worst case is that it doesn't have the right hooks for your model/generation of Celeron and reverts to software decoding even if you have hardware selected. As your "client" (machine displaying the stream and returning the input to the server) doesn't really do much except decode a video stream and push the input to the server, this should be easily in the wheelhouse of even the lowliest of HTPC machines. This is literally something you can do on a tablet processor (eg ShadowPlay to a nVidia Shield device on any Android device via Moonlight) so it's not an extreme processor load for even very-low-power hardware with dedicated silicon.