[Spice-devel] give me some advise how to improve display effect and decrease client cpu usage

[Frédéric Grelot]

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 at redhat.com> 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 at lists.freedesktop.org
> >>> http://lists.freedesktop.org/mailman/listinfo/spice-devel
> >>>
> >>
> >
> >
> >
> 
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>