On 07/23/2014 07:28 AM, Carlos E. R. wrote:
El 2014-07-23 a las 13:15 +0200, jcsl escribió:
I'm probing ssh with X forwarding. Server is a phenom II x6 and client is a netbook. If I start a ssh connection from the netbook and try to play a 1080p video, playback is sluggish. CPU usage raises up to about 50% and MPlayer shows the typical "Your system is too SLOW to play this!". If I run Google Earth it complains about the graphic. This lead me think that it is netbook's hardware who is doing the graphic stuff. Am I right? I did suppose that all the processing was done in the server? Network cards are 10/100 for what it's worth.
Display processing is done on your local machine, yes.
Just so. This is what X is about, separating the display engine from the compute engine. In ancient of days it followed the hallowed tradition of regular 'glass ttys' which worked that wy. UIX was a multi-user system and the Old Iron did not have graphics engines per user. The PC driven by Microsoft Windows and Apple MAC is the other way round. It is dominated by the single user per machine model and integrates the graphics engine into the compute engine, even to the point of then sharing memory. There have been a number of protocols that allow for graphics to be communicated efficiently. One of the most obvious is the old 1980s era PDI used for a while by ATT for information terminals at hotels and airports using a 1200 baud link. It could deal with the basic shapes and colours and made great use of bandwidth for that era. When the X protocol works at the same level it is fast, but that's not how much of 'graphics as pictures' works today. Drawing a rectangular dialog box by sending "coordinates, 'square', color' and text overlays is one thing. We can see similar with the way HTML forms are described. But detailed graphics is another matter. Its one thing to have it handled by a memory mapped unit on the same machine; its another to convert it to a serial stream of information for transmission over a data links, be it high speed IP packets or a 1200 baud modem. Think of television. That too is a stream of bits. Yes we have protocols that can compress video, delta encoding. But they make a LOT of assumptions that may not be valid in this circumstance and don't deal well with the 'scene shifts' of movies.
The procedure does not work well with video intensive apps, you have to use a different method.
I think it is sending the full bitmap image of each frame, so perhaps reducing frame rate of the video could help. Just a bit.
Better use a protocol designed to send video remotely.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org