I find it really weird that in inherently "networked" games (where there is a concept of a shared deterministic game-session physics-frame counter), the PC
playing the game has to be the same PC
rendering the game. You can recreate exactly the same view each player has from that player's outgoing network traffic! Thus, some alternatives to rendering on the user's own GPU come to mind:
1. instead of those HDMI-path recorder middleboxes, you could have an Ethernet-path renderer+recorder box and put all the heavy GPUs there. (Note that, if you don't care about streaming precisely "live", the rendering and recording no longer need to be dataflow-synchronous; you could play the whole game, buffer the network data into the rendering pipeline, and then it would sit there rendering the results for however long you wanted to give to achieve a desired "quality" bound. Effectively, you're doing the same thing as people who stream their commentary of a finished match by rendering off the replay-file the match; but in this case, the "replay file" is streaming to the renderer as it's being created.)
2. You could have an in-game option to asynchronously stream the session data to a cloud GPU instance and render the game there. (Or, y'know, if any of the game infrastructure providers really knew what they were doing with the Internet, they could offer those instances themselves, for a profit.)
3. Or, with the game studios' cooperation, just throw the whole edifice of local rendering away, capture the "replay" data for every match to the studio's data-centers, and then provide a service for cacheable just-in-time rendering of any replay data. Effectively, the game studio would say "whenever you play a match, we render a video from each player's perspective and post it immediately"—but without the need to actually do that (or keep said videos around long-term), because the video is entirely "computed state" that can be recreated from the replay files at any time.
4. One step more: a sudio could even provide an HTML5 "enhanced viewer" interacting with such a render-farm-backed CDN, that let people change perspective of the action themselves, to switch between the perspectives of the players and other views, sort of making such a viewer into an HTML5 thin-client for the game engine on the renderer instance (but without game-state-manipulation logic.) Imagine such a viewer as an embeddable iframe, like a YouTube video. A replay commentator could walk through a session as they would in-client to store a camera-movement-record on the server, get a permalink to the embeddable "video" for that, and then feed it to MashupTwitch along with commentary audio. Presuming the thing that gets embedded is an iframe of the same rendering service, though, any given player could "break out of" the commentated-on view to look around at what else is happening in the game at any time (pausing the commentary mash-up and starting up an extra renderer), and then, when they're done, restart the commentary (terminating the renderer instance and resuming the parent session from where it was.) All the control of being a spectator for a physical sport; all the convenience of a DVR.
---
Mind you, with such a shift, you no longer get "for free" the compositing of the game session video-feed with other things going on on your PC, like voice/webcam recording. But it's simple enough to create a "mash-up" site that plays a raw video-stream from a game-renderer service, and then syncs and overlays a much-more-diminutive 96kbps audio stream from the user's own computer. Twitch would likely grow to serve that market that if the components were in place.
The important thing about this change, though, is that with remote async game-session rendering, you could actually stream games on a less-than-stellar internet connection (you'd still need low latency to play at all, but high bandwidth would no longer be a concern.) So many of my friends living in rural, under-served-by-ISPs areas wish they could stream, but can't.