What about scrapping the conversion to streaming video entirely and replacing it with a networked graphics protocol that allows one PC to draw on another's graphics natively?
Well that would simplify things greatly of course, but then it means bit hit on the bandwidth.
I mean, a 720p60Hz stream in 4:2:0 (12 bits per pixel) still amounts to 663Mbits/s. You won't get that out of a gigabit link realistically (at least not over IP). Of course you could use a lightweight compression algorithm, but you'll have to divide this bandwidth by at least 5 to make it manageable for the average home network I'd say (I have absolutely nothing to back that last number, but 100Mbits/s doesn't look too scary...). And that's only for 720p remember.
I think if you plan to stream HD video over the network you have to encode and be clever about it.
It seems to me, intuitively, that the only ways to do that are:
1. Essentially equivalent to streaming, or
2. Essentially equivalent to normal CPU->GPU communication but over the network (and, thus, needing the bandwidth that local CPU->GPU communication has if you want to avoid slowing things down -- GigE wouldn't seem to be enough, much less WiFi, even if you consider only bandwidth and not latency.)
I mean, a 720p60Hz stream in 4:2:0 (12 bits per pixel) still amounts to 663Mbits/s. You won't get that out of a gigabit link realistically (at least not over IP). Of course you could use a lightweight compression algorithm, but you'll have to divide this bandwidth by at least 5 to make it manageable for the average home network I'd say (I have absolutely nothing to back that last number, but 100Mbits/s doesn't look too scary...). And that's only for 720p remember.
I think if you plan to stream HD video over the network you have to encode and be clever about it.