# Bandwidth needed?

This topic is 3484 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hello. What do you think is the minimum bandwidth (down speed) for send like a stream all the game video and audio to another computer? I explain. Supoups that run a game in computer A that acts like a server, but I send all the output(audio+ video) through the net to computer B that is a "super thin" client that receives all this information. How good should it be the bandwith conexion between both of them for a smooth visualization in the B computer? Image a game like call of duty 4 for example. I just asking for a approximation guess, nothing extrict is need it. Thanks. [Edited by - vsk on May 26, 2008 11:56:57 PM]

##### Share on other sites
Depends on the kind of quality that you want.
Do you want it to look like Youtube, or should it look as good as the original image?

If you want full quality (with no compression), it will use up about 1/3rd of a gigabit network's bandwidth:
Images:
800*600 * 3 = 1.4MB bitmap per frame
@ 30hz = 41MB per second
= 330 megabits per second
Sound:
44,000khz * 16bit samples = 86kB per second
= 687.5 kilobits per second

If you do some major compression (which would require lots of CPU time on either end for compression/decompression), you could cut it down a lot:
Images:
640*480 * 3 = 900kB bitmap per frame
900kB bitmap can compress to ~9kB JPEG
@ 15hz = 135kB per second
= 1 megabit per second
Sound:
11,000khz * 8bit samples = ~10kB per second
= 86 kilobits per second

Of course you can keep cutting the quality until you get down to 96 kilobits per second (or whatever), but it's going to look pretty terrible at that stage...

##### Share on other sites
wow! thanks you are a genius, quick and accuracy response! :).

Yes I will need original quality and original sound.
Have you tried this in practice?
Is this approach that I named used for anything actually? and in games?
If so, could you please send me some page link to read about it, I have search, but not found, maybe because I don't use the proper terms for search (english is not my native language).

Thanks again!.

##### Share on other sites
Ok, last one.
If I have a 5Mb bandwidth and run the game on computer A, then pass the 800*600*3 image to computer (next to A) C with a good procesor, (let say, quad core) to ONLY compress this images in the way you named. And then send it to B through the net. In the B (super thin client) I decompress again with a good processor.
Could I manage a 30hz smooth visualization?
Thanks

##### Share on other sites
You could, but it would be pretty ordinary.
If the internet lag didn't kill you, compressing and decompressing on top of this might.

If you plan on adding more players/users later this approach will not work on your bandwidth.

##### Share on other sites
It depends on the entropy of the image.

Remote desktops manage much more, but they rely on knowledge of API and cooperation of OS.

For video, it depends how much information you lose. The most trivial compression is to downsample the images. From 800x600 to 160x120, perhaps.

Quote:
 with a good procesor, (let say, quad core)
Irrelevant. Image carries certain amount of information that needs to be transferred. For typical motion video, that will be some 70-100% of raw data (assuming Huffman or arithmetic coding).

If you include motion prediction, then for low motion scenes you can get better compression ratio, but you gain nothing for full scene changes.

Another problem is also bus bandwidth. 330mbps needs to be transferred from capture card into main memory, then copied from there to network. This puts the total requirements at 660mbps. Since you include compression as well, you need to perform another copy. This all may quickly exhaust the available memory bandwidth, especially once you consider the processing needed for intra-frame motion prediction.

For all the video processing I've done, it was always the bandwidth that limited the resolution.

Note that H.264 codecs have trouble *decoding* the stream of lesser resolution on single-core machines, and they are heavily optimized.

Quote:
 Could I manage a 30hz smooth visualization?

Yes. But not at full resolution, and not over 5Mbps link. On 100Mbit LAN, by reducing resolution to 320x240, and by running one of streaming codecs.

Note that you 5Mbps link means you have 170kbps (21kBps) per frame, so you need per-frame compression ratio of 1:66.

This comes to about 1.5%, which is comparable to compression ratio of JPEG format at 60-70% quality factor!

Quote:
"Real-time streaming video"

Quote:
 Is this approach that I named used for anything actually?
YouTube, GoogleVideo, thousands more streaming sites, Skype, teleconferencing, Desktop Remoting, VNC, .....

Quote:
 and in games?

There was an experiment that used distributed ray-tracing rendering across 30 machines over high-bandwidth LAN to generate images in real-time.

Other than that, no. Full-quality or loss-less transfer isn't used, since it simply isn't viable.

Or if it is, you should consider gigabit LAN, or various fiber connections.

##### Share on other sites
If your goal was to make a super computer render the game for everyone then send out the video and sound so anyone with a decent computer and high bandwidth could play it then it's been thought of many times. It's just not a viable solution yet.

##### Share on other sites
Quote:
 Original post by SirisianIf your goal was to make a super computer render the game for everyone then send out the video and sound so anyone with a decent computer and high bandwidth could play it then it's been thought of many times. It's just not a viable solution yet.

Haha, the only one who got it ;).

So, is there any article, discussion, whatever, that you can send me to dig into it?

And besides, (related to this), anyone has seen a "projected internet -average- bandwidth" for future, I mean like the tables from the "Moore law" about the transistor, memory, etc, but about the bandwidth in internet.
I will appreciate it.

##### Share on other sites
Available bandwidth isn't much of a problem, as there are networks in developement which offer 100x the current home bandwidth but the latency (the time it takes for data to travel through the network ) is still constatined by fundemental physical constraints, and haven't improved much.

Most multiplayer games can get away with the current latency by simulating as much as possible on the client, and displaying it at the immediate framerate ( ususaly 60-30 fps). With a pure thin client (used only to render a audio/video stream), the interactive latency would produce slugish response between users actions and visual change, leading to the dreaded FPS nausa. Maybe if the client was to extraoplate the render stream and project simple a transform upon the data (ie moving left/right or forward will produce a canned video effect of panning or zooming the video stream) in anticipation of the expected eventual outcome of the video stream, it could hide some of this latency. However it can't project gameplay events like shooting as such since that required alot of knowledge about the game itself and the cascade of events from such an action.

However that said, it's not unresonable to take a hybrid approach where say the client renders the close world ( ie first 50 meters from the user ) in the tranditional manner and the rest ( ie the far world 50 -> inifinty meters out ) could be served by a supercomputer type machine rendering a non-interactive vistas ( since the user cant possibly interact with that world fast enough ).

This could be useful for MMO where they can keep a lower macine requirements for their users, while still provide them with high quality visuals.

Good Luck!

-ddn

##### Share on other sites
Interesting. Thanks for the explanation.
Anyway, I will wait for some years, I think this will be the future standard for gaming, ok, is kinda a crazy, but I really think is gonna be this way.

About the "projected bandwidth Internet average" anyone has seen one?, I have no found none on google (but again my not-native English language skills could play against me ;-)).

Greetings.

##### Share on other sites
Future standard for gaming? I don't know about that... some people have $1000-$2000 rigs set on the highest quality. To maintain that quality, you're going to have to duplicate that for just about each client. Not only could this easily cost over \$10k for a server that can duplicate the work of a very small FPS match, but tons of servers are hosted on home computers. Might as well just use what they already have in their machines.

Also, keep in mind that since you are not rendering, you have a round-trip delay for EVERY action. That means if you move your mouse a little bit, its going to take at least 100ms (assuming you have a 50ms ping, which is still very low) to do that... and thats still pretty low. More realistically, it'd be around 150-200ms. Try playing a FPS at 5-10 frames/sec and see how hard it is to aim at anything... the delay is gonna kill you big time.

##### Share on other sites
Some people have written about the growth of bandwidth, here are some links:

Then there's the Internet2 research networks which peaks out around 8Gbps.

BTW someone is actually trying to do this right now, I read a little blurb about it on GameDev.

http://www.gamedev.net/community/forums/topic.asp?topic_id=469798

-ddn

##### Share on other sites
Quote:
 Original post by vskInteresting. Thanks for the explanation.Anyway, I will wait for some years, I think this will be the future standard for gaming, ok, is kinda a crazy, but I really think is gonna be this way.

Watch Herb Sutter's presentations, or read his articles.

Bandwidth (and the implications of Moore's Law) have long lost their importance. It's all about latency these days, even for multi-core programming, and even for single-core programming.

Even given infinite bandwidth, as of now, speed of light isn't predicted to change. A trans-atlantic (6000km) connection will still have at least 40ms ping. Consider that we're getting dangerously close to this limit. General internet links over this distance currently produce ping approaching that (traceroute says 133ms for approximately this distance).

Every single online game uses predicition of some sort to hide latency, and that just isn't possible with this type of model.

##### Share on other sites
Quote:
 Original post by ddn3http://www.gamedev.net/community/forums/topic.asp?topic_id=469798-ddn

Hey!, I just get into the page, I am not the only insane person :-).
I want to see how the solve this problems.
Thanks for the charts too.

##### Share on other sites
Hey, people, (espialy the ones that say "impossible" or equivalents), GO INTO THAT PAGE!.
I hate those bastards!. :-P.

##### Share on other sites
Quote:
 Original post by vskHey, people, (espialy the ones that say "impossible" or equivalents), GO INTO THAT PAGE!.I hate those bastards!. :-P.

Assuming you are referring to this link, I believe they are mostly doing it via a 1000Mb LAN connection, reserving non-LAN usage with the hopes that the future modern home connection is actually fast (in both senses of download rate and ping) enough to stream a decent quality video that is compressed on the fly.

You have to realize the problem can't be solved by throwing better, faster hardware at it. Even if you had a computer that could magically compress a high quality video stream down to a KB per frame, you still have the latency that is going to be a result of physical location. I think you are vastly underestimating the effects of poor input response.

##### Share on other sites
Quote:
Original post by Spodi
Quote:
 Original post by vskHey, people, (espialy the ones that say "impossible" or equivalents), GO INTO THAT PAGE!.I hate those bastards!. :-P.

Assuming you are referring to this link, I believe they are mostly doing it via a 1000Mb LAN connection, reserving non-LAN usage with the hopes that the future modern home connection is actually fast (in both senses of download rate and ping) enough to stream a decent quality video that is compressed on the fly.

You have to realize the problem can't be solved by throwing better, faster hardware at it. Even if you had a computer that could magically compress a high quality video stream down to a KB per frame, you still have the latency that is going to be a result of physical location. I think you are vastly underestimating the effects of poor input response.

http://www.streammygame.com/smg/index.php
There you can find several examples of application.
Here you have their user on youtube.
Again, but this time with some prove ;-): "This is the future for gaming"

Here is its youtube example user: (in this case they are playing crysis).

Just some months ago, they enabled playing via broadband but only for super nets.

##### Share on other sites
That's the link. I remember seeing that a long time ago.

notice the resolution and the required upload speed required to host. What you asked was for hosting more than one player I figured.

Quote:
Original post by vsk
Quote:
 Original post by SirisianIf your goal was to make a super computer render the game for everyone then send out the video and sound so anyone with a decent computer and high bandwidth could play it then it's been thought of many times. It's just not a viable solution yet.

Haha, the only one who got it ;).

One person hosting and sending to one person is fine and dandy at youtube quality with DSL. Hosting tons of players even 10 would require amazing networking. It would definitely suffer from latency as you try to generate the camera angles and stuff. Also remember being able to stream crysis aka render crysis at 320x240 or low DSL speeds isn't that exciting when you take into account the latency for input. Notice how they don't say the FPS you get ;)

//edit that video you linked is probably running with an ethernet cable connected to the other computer right next to it on LAN for all we know.
//double edit. Ooh something important to point out. Some of those youtube videos are placed by the creators of streammygame for publicity. Probably shot under ideal situations on awesome hardware. Just speculating though. Did you test the software yet?

##### Share on other sites
Yes, I know it is publicity, but I don't think he has a NASA computer/network.
And not, I don't want to several players, I want to 1pc server->1 client, 10 pc server-10 clientes (or so).
Yes it is lag anyway: here is what they recommend for resolving/minimize

From its web page:

/****************************************/
1) Graphics card (GPU)
The less strain on your graphics the more power it has to play and capture the game. To improve lag caused by graphics cards you can lower the game resolutiuon or get a faster graphics card.

2) CPU
Your CPU is used by StreamMyGame to encode video along with your GPU. To improve lag caused by the CPU you can close any other applications that are not being used, overclock your CPU or get a faster CPU.

3) Bus
The coputer interconnect between the CPU and the GPU is called a bus. The latest bus is called PCIE (PCI Express) which is fast in both directions. The older bus is called APG (Accelerated Graphic Port). THe new bus is faster at sending video from the GPU to the CPU. To serve games at hi resolutions you should get PCIE.

4) Wired and Wireless Networking
The lowest lag is acheived by using wired networking at present. 100Mb wired network will achieve full HDTV 1080p with StreamMyGame. 1Gbit is even better.
SOME wireless networks say they can achieve network speeds of XXXMb, in the real world they dont get even close. If your using wireless networking try to get the latest 11n or at least 11g. We have found that there are massize variations in good and bad wireless networking router even though they all say they are 11g.
/**********FROM ITS WEB PAGE**********************/

So, comming back to laging problem, what are the solution that researcher are finding/investigatin for solving it? (if there exists a possible of solution).

##### Share on other sites
The lag we are generally referring to is the latency. There's nothing you can do. Data can only go so fast between two points. Ping is the round trip time measured in milliseconds that it takes a packet to travel. In order to compensate for lag many games trick the user. You might click forward in an FPS and even though the move wasn't validated because it takes say 50 ms to reach the server, the client might move you a little bit while it waits and perform client side hit detection. Depending on the position data it receives back it might make a small correction or snap the player to where it needs to be.

Velocity is sent along with entity positions allowing for extrapolation. Now to make this clear as to why this streammygame software will look worse is because there's no client prediction and there's no extrapolation of any sort. You send the input and it takes 100 ms (generally a worse case. I mean Planetside averages 40 - 60 ms pings) and you get the images back. So you end up with 1/10 of a second to see your response. Also games drop packets with UDP. It's inevitable on the internet. Video frames would be thrown out. You would probably see lag. Normal games extrapolate and interpolate between known coordinates and such so losing a packet isn't that bad since a spline will have the players general motion and only quick changes usually would require a snap.

##### Share on other sites
Saw this thread going for a while and got interested. Here's a few ideas to think about.

I think that the real trick with SMG (streammygame) technology is that they have developed a video compression codec that:
a) Compresses video data really small
b) Compresses video data with good quality
c) Compresses video data really quickly

When developing a video compression codec, the result is often a tradeoff between these factors. The client is only a thin client, probably sending user input via UDP (a la Source or QuakeIII delta compression) because it will travel from point a to point b faster, but then sending the video data via TCP because it is *much* better suited to streaming.

In reality you're probably looking at around 75-100ms RTT which would still be playable. The most complex part of this technology would be the video codec. It would have to be able to encode in realtime on a good PC running a high-tech game, and decode in realtime on a half decent home consumer PC.

I'm guessing the SMG video tech is based on some kind of GPU accelerated video codec that compresses some variation on the H.264 (MPEG4) standard - the latest developments by the graphics card vendors can accelerate the playback of high-def video data using PS.3 enabled GPU's, so maybe they have figured out a way to accelerate the encoding of this data too. H.264 would require a super dooper CPU to compress in realtime while running Crysis without some kind of assistance by a parallel processor - the GPU would be a good candidate. If GPU acceleration is not possible then some heavy optimisation using knowledge of SIMD CPU extensions and parallel processing techniques would probably be necessary, but still, DMAing the framebuffer over the system bus for processing would be taxing even on a super dooper GPU.

H.264 contains certain properties that would make it favourable for this kind of project - it can compress data down very small, and it is relatively lightweight to decompress - the iPod Touch can decode H.264 video with only a 500MHz ARM processor running the show.

Basically, to target internet users here you need to compress your video data stream data to around 2Mbps (~240KBps) to target the majority home users. If you're working with a LAN then you can get away with a codec that doesn't compress the data so much but uses less resources to do it. Also bear in mind that audio imposes an extra processing and bandwidth penalty.

##### Share on other sites
Quote:
 Original post by TheGilbH.264 contains certain properties that would make it favourable for this kind of project - it can compress data down very small, and it is relatively lightweight to decompress - the iPod Touch can decode H.264 video with only a 500MHz ARM processor running the show.

While I'm sure it's possible, what is the trade-off?

While playing back The Dark Knight trailer the 720p preview peaked the CPU (resulting in mostly jerky movement frequently) on single-core machine. On dual core machine the 1080p stalls at about 4 spots during playback (at least you have actual reference to compare).

how much quality trade-off are we talking here?

But for me, this poses a much more important question. Why? I honestly don't see any benefit this approach brings. My use cases are the following:
- I own the server and client, both on LAN. Through streaming, I gain nothing, but have more latency, increased demand on actual game machine, and decreased image quality
- Over internet, I gain unplayable latency (ask a FPS fan if they would play with 70-100 ms latency), I need to pay subscription, and I don't even know who hosts the game or under what terms. Plus, I still need a very powerful machine to decode the video stream, as well as, for current purposes, unacceptable bandwidth requirements (I could get 100/100 fiber, but for now, 8M/2M cable is all I could need)

So where is this killer feature? I honestly cannot find one use-case that would offer any benefit with such approach when offered for free, and nothing that would in any way warrant monthly subscription.

PS. On my development machine I use dual monitor setup, with remote Linux desktop and third desktop mirrored to another computer resulting in effectively 4 monitors, so I'm absolutely no stranger to remoting in any way whatsoever. But no for such purpose.

##### Share on other sites
Movement lag can be compenstated but only slightly within this scheme, ie transforming the video stream based on the users actions (ie moving fwd/bckwd, left/right ) thats simple enough. That will reduce the apparent movement latency to an acceptable degree, but gameplay will still suffer.

Imagine playing this on a multiplayer game, not only would you have the transactional latency of the streamming system in addition to the latency from the multiplayer game added on :D

As for latency, the time packets take to travel, were getting to a lower bound. I get about 30-40ms pings from people within my local area (in state), it hasn't improved at all really in years, and I dont think it will. Most of the new technology is aimed at increasing bandwidth not reducing latency.

It should be noted that 30-40 ms is adequate for this scheme to work, given sufficent network capacity and processing power on both sides. People are not going to notice 30-40 ms movement latency.

GPUs are doubling in processing power every generation and CPUs are poised to for massivle parallizaiton, with the new multi-core iniatives and bandwidth also seems to be doubling every 8 months.

So with that, this technology seems inevitable, but whether it will be a player overall, that's more difficult to ascertain.

-ddn

##### Share on other sites
Quote:
 Original post by ddn3Movement lag can be compenstated but only slightly within this scheme, ie transforming the video stream based on the users actions (ie moving fwd/bckwd, left/right ) thats simple enough. That will reduce the apparent movement latency to an acceptable degree, but gameplay will still suffer.

wait what? Transforming the video? I'm afraid I'm not following you. You mean extrapolating images given previous frames? If you turn your camera you can't extrapolate unknown pixels on the edge of the screen. Maybe I'm misunderstanding what you mean.

##### Share on other sites
Given that were displaying a FPS game, this isn't applicable to every game ofcourse. If the player were to say move left, if you observe in a normal FPS game moving left, all it does is pan the viewport right and vice versa for moving right.

Even a simple thin client can do the panning initally on its side without waiting for the server to respond. We can wortk out the math about how many pixels of movement the user can do within a given timeslice for their latency but i'll guessimate, say 50 ms ping, 25ms 1/2 ping, with a framerate of 30fps, tidy up the numbers user does 1 frame extraoplation before real data comes down pipe to fill extrapoolated data.

That would mask some movement latency, with tradeoff with some visual discrepancy on screen edge.

Moving into/out of screen would also be simple transform of zoom/unzoom of viewport.

Even more advance interpolation scheme can be developed ofcoruse, such as breaking the streams apart into tagged data which can then be expolated independenly.

The biggest benifit I see for systems like this is its scaleablity. The user can move from mobile device, laptop, desktop, and console and still have relaltily the same experience.

Were talking about making FPS playable ( which have the tightest requirements for interaction ), this system will work for them but with some drawbacks. For all other game types, it works much better.

-ddn

##### Share on other sites

This topic is 3484 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
628726
• Total Posts
2984410

• 25
• 11
• 10
• 16
• 14