Hi, A recent information about firefox and video pass-through : Firefox 24 (22 was released this week) will have better html5/gstreamer support. As I understood it, gstreamer will be used for H264, MP4 and AAC decoding. I remember that the plans about video pass-through talked about intercepting (with the agent?) gstreamer streams : that would be a very interesting improvement regarding this new Firefox feature! However, I'm not sure how gstreamer is integrated with FF : does it send the stream to the screen/speaker, or is it sent back to Firefox, which is then responsible for the final rendering? In this last option, using gstreamer to send the stream to the client would be quite complicated... I hope this information will help! Frederic. ----- Mail original ----- > 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. > 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