Hi, On Thu, Jun 27, 2013 at 02:28:29PM -0400, Yonit Halperin wrote: > Hi, > On 06/18/2013 09:25 PM, bigclouds wrote: > > > >so much thanks Yonit: > >1. > >i basicly understand some of your ideas, please give me more details > >about video pass throught, and hardware accelerate, > >i think it is hardware related, my hardware is 1G cpu, 2 core, AMD, does > >not has special hardware. > >if on android platform, i am not sure if which has such hardware. > video pass-through: with spice current implementation, videos are > decoded inside the guest, the rendered frames reach the server, and > then, if the server manages to classify them as video, the server > re-encodes them (MJPEG), and the client decodes them. > video pass-through means to stream the *original* encoded video > (i.e., you need to catch the video in driver level, or maybe using a > browser/player plugin), and then you decode the original video on > the client side. is there a preference for implementing this at the driver level (xf86-video-qxl I assume) versus at the browser/plugin level? thanks, - Vasilis > This feature might raise some licensing issues, unless decoding of > proprietary codecs is done in the graphics driver of the client. > By hardware acceleration, I meant encoding/decoding using the GPU. > Maybe it will be interesting to compare gstreamer-vaapi jpeg > decoding to libjpeg-turbo decoding. But I'm not familiar with libva, > and how common are the graphics driver it supports. Maybe someone > else from the team have more information about this. > >2. > > improved caching , if you mean 'display tree' or send queue? this > >part seems hard for me, spice use pixman directly, but there is no > >document about pixman. if you can ,please explain display architeture > >to me. > Caching: the server and client have a synchronized cache of bitmaps > (server hold bitmaps hash keys; client holds the the actual > bitmaps). When a bitmap is sent to the client, if it is already in > the cache, only its id is sent, instead of the whole bitmap. > There is --spice-cache-size option for remote-viewer. You can change > the size of the cache and see if it improves the performance. Then > we can consider implementing caching on disk, and not only memory. > > Cheers, > Yonit. > > thanks. > > > > > > > > > >At 2013-06-19 01:44:29,"Yonit Halperin" <yhalperi@xxxxxxxxxx> wrote: > >>Hi, > >>On 06/18/2013 10:33 AM, bigclouds wrote: > >> > >>>hi,all > >>>i have used spice for a long time,it is good, but in pratice it needs > >>>improvement, like resource usage, network bandwidth,performance. > >>>1.it eats up much cpu on client side, up to 90% when play video. i am > >>>sure whether decompression or something else uses so much cpu. if > >>>client (remote-viewer) is corss-compiled to arm platform, what will > >>>happen? iordan has succellful compiled it to android platform. > >>>how to decrease cpu usage on client side?(if Mplayer which Fedor has > >>>mention will help ) > >>For improving video streaming cpu & network usage, it would be great to > >>have video pass-through and hardware accelerated decoding. > >>>2.how to improve display effect and decrease network usage. > >>>now glz algorithm seems the best, but display stuck, and mosaic (video > >>>screen not sync) exist. > >>By default we use auto_glz. Quic is applied on images that are > >>classified as "real life" bitmaps. And GLZ is applied on images that are > >>artifical (e.g., mainly contain text). > >>>better network leads to larger traffic, some time it goes up to 7M/s. > >>>in future spice client will be often used in WAN , in that case the > >>>less trafic the better. > >>>guys , do you have some ideas? > >>Spice bandwidth usage is not deterministic, i.e., if you observe network > >>usage of 7M/s on LAN, it doesn't mean that spice-server will try to push > >>the same amount of data over WAN. Some of the bitmaps may be dropped if > >>possible. > >>For decreasing the bandwidth usage, you can think of features like > >>- improved caching (e.g., try to enlarge the cache size, and if it > >>helps, consider disk based caching). > >>- improved lossless compression (e.g., finding identical sub-regions > >>between bitmaps that are not necessarily "artificial" and compressed by > >>glz today; something like a combination of a dictionary-based encoding > >>and predictive encoding). > >>- Instead of setting TCP_NODELAY=0 over WAN (enabling Nagle's > >>algorithm), concatenate small messages in the application level (i.e., > >>in spice server).Nagle's algorithm can lead to observed latencies due to > >>its interaction with the delayed ack timeout on the peer side (see > >>http://www.stuartcheshire.org/papers/NagleDelayedAck/) > >> > >>Regards, > >>Yonit. > >>>thanks > >>> > >>> > >>> > >>> > >>>_______________________________________________ > >>>Spice-devel mailing list > >>>Spice-devel@xxxxxxxxxxxxxxxxxxxxx > >>>http://lists.freedesktop.org/mailman/listinfo/spice-devel > >>> > >> > > > > > > > > _______________________________________________ > Spice-devel mailing list > Spice-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/spice-devel _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel