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