5 ms·

It seems to work like the nVidia Shield's streaming. Another computer on your home network handles the heavy lifting and streams the video output to your SteamO

It seems to work like the nVidia Shield's streaming. Another computer on your home network handles the heavy lifting and streams the video output to your SteamOS box.

rocky1138 13y ago
I've never had good luck with streaming a game, even on a local, wired connection. There's just way too much input lag.
- asdasf 13y ago
  That doesn't make any sense. If you can handle ~20ms of latency from your TV itself, how is <1ms of latency from a local ethernet connection a problem?
  - cwoods 13y ago
    I really doubt an ethernet connection can push a full HD video frame in 1ms. The <1ms is for ping, which uses a really small network packet. Pushing 1080p HD video is a totally different matter.
    - asdasf 13y ago
      ping uses whatever size packet you tell it to: $ ping -s 1450 192.168.11.10 PING 192.168.11.10 (192.168.11.10): 1450 data bytes 1458 bytes from 192.168.11.10: icmp_seq=0 ttl=255 time=0.646 ms 1458 bytes from 192.168.11.10: icmp_seq=1 ttl=255 time=0.478 ms 1458 bytes from 192.168.11.10: icmp_seq=2 ttl=255 time=0.469 ms
      - errnoh 13y ago
        1080p video is nowhere near 1458 bytes. For raw 720p RGBA you'd send: 1280 * 720 * 32 = 29,491,200 bits but obviously you're not going to do that. Suddenly you're not only sending data but also encoding / decoding it.
        asdasf 13y ago
        >1080p video is nowhere near 1458 bytes. It doesn't matter, that's the point. Your MTU is almost certainly 1500 bytes. You are sending 1500 byte packets at the most. That does not cause latency. If you want to argue that we're incapable of encoding or decoding video with acceptable latency go right ahead, but doing it in response to me correcting a misconception about network latency doesn't make much sense.
        simias 13y ago
        Having worked on the particular issue of streaming real-time video over wireless, I can say that the main issue is not link latency. The main lag comes from encoding/decoding. If you do it naively you encode frame-per-frame (encoding slices is more difficult), and the encoder does not only outputs iframes: you get partial frames that depend on both previous and future frames. Also the decoder does not always output frames in order. So you have to expect something around ~10 frames of latency, maybe less if you optimize everything well enough. That still means easily more than 100ms of lag. The network is really not the main issue here.
        rocky1138 13y ago
        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?
        dragonwriter 13y ago
        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.)
        simias 13y ago
      - VLM 13y ago
        It would be insane to do this, but you could shove ATSC between boxes over ethernet by shoving each 188-byte MPEG transport stream packet in an ethernet frame and skipping all the layer 3 stuff. Or UDP it, if you want to route it. They probably like the idea of a difficult to route protocol keeping data on one ethernet segment. My HDhomerun ATSC receiver certainly has no problem shoving a couple megabits of high def video over ethernet. Nor does my mythtv setup, or even just plain old NFS shares to watch videos.
sliverstorm 13y ago
You're kidding. This is perfect.
Karunamon 13y ago
This is genius. All you need now is a micro box running windows with appropriate video card that you can stick in the corner next to your router and never have to look at again. Assuming the streaming and UX works half as well as they're playing at, they've just managed to commoditize hardware compatibility. I don't think the importance of this can be understated.
- giovannibajo1 13y ago
  You could do this already for years with Apple TV and Airplay mirror. The real problem is that of controls, mouse and keyboard don't match well with couch
  - Karunamon 13y ago
    The difference being that i can see Steam releasing the applications to make this work everywhere, while Apple has traditionally been hostile to this kind of interoperability.
    - giovannibajo1 13y ago
      It's true that Apple is hostile (= doesn't release spec, but doesn't actively make the protocol hard to reverse-engineer either, eg: the DRM stuff is limited to DRM content and not part of the protocol proper), but the protocol has been reverse engineered and there are many implementations of AirPlay nowadays. What is the precedence on which you base your belief that, whatever protocol Valve has come up with to replicate the video stream, it will be open? I'm not that much into gaming, but Steam is a closed-source software that includes mandatory DRM for the games, it doesn't really set a precedent of openness and interoperability.
      - Karunamon 13y ago
        Couple of reasons. First off, Steam is the only DRM I can think of that actually adds value and makes my life easier instead of the reverse. Second, keep in mind that they've already announced streaming inside the LAN. Having mobile apps would be a natural extension of that. (Note I didn't say that it would be open, I said they will probably release mobile apps). That streaming is also completely not a threat to their system.

It seems to work like the nVidia Shield's streaming. Another computer on your home network handles the heavy lifting and streams the video output to your SteamOS box.

rocky1138 13y ago

I've never had good luck with streaming a game, even on a local, wired connection. There's just way too much input lag.

asdasf 13y ago
That doesn't make any sense. If you can handle ~20ms of latency from your TV itself, how is <1ms of latency from a local ethernet connection a problem?
- cwoods 13y ago
  I really doubt an ethernet connection can push a full HD video frame in 1ms. The <1ms is for ping, which uses a really small network packet. Pushing 1080p HD video is a totally different matter.
  - asdasf 13y ago
    ping uses whatever size packet you tell it to: $ ping -s 1450 192.168.11.10 PING 192.168.11.10 (192.168.11.10): 1450 data bytes 1458 bytes from 192.168.11.10: icmp_seq=0 ttl=255 time=0.646 ms 1458 bytes from 192.168.11.10: icmp_seq=1 ttl=255 time=0.478 ms 1458 bytes from 192.168.11.10: icmp_seq=2 ttl=255 time=0.469 ms
    - errnoh 13y ago
      1080p video is nowhere near 1458 bytes. For raw 720p RGBA you'd send: 1280 * 720 * 32 = 29,491,200 bits but obviously you're not going to do that. Suddenly you're not only sending data but also encoding / decoding it.
      - asdasf 13y ago
        >1080p video is nowhere near 1458 bytes. It doesn't matter, that's the point. Your MTU is almost certainly 1500 bytes. You are sending 1500 byte packets at the most. That does not cause latency. If you want to argue that we're incapable of encoding or decoding video with acceptable latency go right ahead, but doing it in response to me correcting a misconception about network latency doesn't make much sense.
        simias 13y ago
        Having worked on the particular issue of streaming real-time video over wireless, I can say that the main issue is not link latency. The main lag comes from encoding/decoding. If you do it naively you encode frame-per-frame (encoding slices is more difficult), and the encoder does not only outputs iframes: you get partial frames that depend on both previous and future frames. Also the decoder does not always output frames in order. So you have to expect something around ~10 frames of latency, maybe less if you optimize everything well enough. That still means easily more than 100ms of lag. The network is really not the main issue here.
        rocky1138 13y ago
        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?
        dragonwriter 13y ago
        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.)
        simias 13y ago
    - VLM 13y ago
      It would be insane to do this, but you could shove ATSC between boxes over ethernet by shoving each 188-byte MPEG transport stream packet in an ethernet frame and skipping all the layer 3 stuff. Or UDP it, if you want to route it. They probably like the idea of a difficult to route protocol keeping data on one ethernet segment. My HDhomerun ATSC receiver certainly has no problem shoving a couple megabits of high def video over ethernet. Nor does my mythtv setup, or even just plain old NFS shares to watch videos.

sliverstorm 13y ago

You're kidding. This is perfect.

Karunamon 13y ago

This is genius. All you need now is a micro box running windows with appropriate video card that you can stick in the corner next to your router and never have to look at again. Assuming the streaming and UX works half as well as they're playing at, they've just managed to commoditize hardware compatibility. I don't think the importance of this can be understated.

giovannibajo1 13y ago
You could do this already for years with Apple TV and Airplay mirror. The real problem is that of controls, mouse and keyboard don't match well with couch
- Karunamon 13y ago
  The difference being that i can see Steam releasing the applications to make this work everywhere, while Apple has traditionally been hostile to this kind of interoperability.
  - giovannibajo1 13y ago
    It's true that Apple is hostile (= doesn't release spec, but doesn't actively make the protocol hard to reverse-engineer either, eg: the DRM stuff is limited to DRM content and not part of the protocol proper), but the protocol has been reverse engineered and there are many implementations of AirPlay nowadays. What is the precedence on which you base your belief that, whatever protocol Valve has come up with to replicate the video stream, it will be open? I'm not that much into gaming, but Steam is a closed-source software that includes mandatory DRM for the games, it doesn't really set a precedent of openness and interoperability.
    - Karunamon 13y ago
      Couple of reasons. First off, Steam is the only DRM I can think of that actually adds value and makes my life easier instead of the reverse. Second, keep in mind that they've already announced streaming inside the LAN. Having mobile apps would be a natural extension of that. (Note I didn't say that it would be open, I said they will probably release mobile apps). That streaming is also completely not a threat to their system.