Remote Desktop works by transferring graphical information from the remote computer to your local computer. In the most naive straightforward implementation of this functionality, everything would be rendered on the remote computer. And then the snapshots of already rendered data would be sent over to RD client computer. However, RD implementation is much less naive.
For graphics that consists of "line art" and text drawn through Windows API, Remote Desktop actually performs a remote procedure call: it sends the API call parameters to the client machine and carries out the actual call on the client machine. I.e. the graphics is actually rendered on your local client machine. This is an extremely compact and efficient way to transfer graphics, which is why all "line art" and text drawn through Windows API work very fast over Remote Desktop connection. Basic Windows GUI is one example of such graphical information. In essence, this graphical information is transferred over the network in extremely efficient vector form. This is what makes typical Windows GUI elements to work so well over Remote Desktop connection.
Now, any graphical information that cannot be described as a sequence of vector Windows API calls has to be transferred in bitmap form. That applies to raster images, for example. You probably noticed that ordinary bitmap images are drawn in Remote Desktop client much slower than typical GUI elements. The same applies to video. Video is actually played on remote machine and then the rendered result is transferred to your local client machine as a rapid sequence of bitmaps. This generates a huge amount of network traffic, which easily exceeds the bandwidth of a typical connection. This is why videos are virtually unplayable through Remote Desktop.
4Make the video smaller. Start with calculating the RAW bandwidth needed to stream the video (RDP will do better than that, but start with that. Then compare it to your wireless speed (which usually is a lot less then 54Mbit/sec, and even on a 54MB 'wireless' connection you can not transfer 54Mbit of data per second. Wireless has a lot of overhead). -- To help with the data part: say yo steam a 1024x768 image at true colour. That is 1024x768x32 MB (3MB) per frame. To reach a smooth 50 frames per second you would need 150MB/sec (or about 1500mbit wireless and good conditions). – Hennes – 2013-03-23T00:56:18.510
1@Hennes if it requires that much bandwidth, why i have no problem when i visit the source site and stream directly? – user22105 – 2013-03-23T01:00:03.897
2Because the source is most likely in a compressed format. Sane video format do things like "full frame with max compression", followed by "X frames with only the differences from the previous frame". That makes a huge difference. This is why I capitalised RAW in the previous comment. – Hennes – 2013-03-23T01:00:55.103
@Hennes hmm... if what you said is true, is there a way to make it play fluidly from a remote PC? – user22105 – 2013-03-23T01:10:51.343
Yes, do not stream the already uncompressed images. Stream the compressed data (in other words, run the player on the iPad). – Hennes – 2013-03-23T01:14:23.383
Retitle this, How do I get Retro IBM AT EGA frame rates so I can experience the past. With the iPad, you're doing screen refreshes as packets over a wireless lan. With the computer, you're receiving compressed video which it's decompressing and displaying over a PCI or better bus. Wireless LAN != PCI bus. How do you make it fluid? You don't. – Fiasco Labs – 2013-03-23T01:30:31.283