[Spice-devel] xf86-video-qxl performance
alevy at redhat.com
Wed May 23 23:52:51 PDT 2012
On Wed, May 23, 2012 at 10:02:03PM -0400, Marc-André Lureau wrote:
> ----- Mensaje original -----
> > Also, as a crazy idea, has anyone considered implementing a pure
> > streaming video driver? That is, what if we had a frame buffer
> > driver,
> > and then a thread that fired 29 times a second to drive a theora or
> > vp8
> > encoder, simply feeding the current frame at those intervals.
The idea is not crazy at all. On the todo list.
> Even if doable, using theora or vp8 would result in poor visual quality
> that isn't really acceptable for desktops.
> Although there are some screencast video codecs (microsoft a developped
> several over the years, unfortunately, there aren't very well known, and
> I wonder how they differ from some kind of saved rdp stream)
I couldn't find any codec that was opened last time I searched.
> However, I haven't look much at optimization, but I can imagine it
> could be interesting to combine drawing operation more aggressively
> perhaps based on a timer too (I don't think we do it, but I know that we
> do some combining in some cases when the sending queue is full).
No, what we do is combine some operations (change/drop) by looking at
current outstanding messages (queued but not yet sent - in the pipe)
whenever we read a new message from the device (from the ring). There is
a good visual iirc on spice-space.org .
Doing actual merging is required to move the multiple client support
from "experimental" to "production", since it is a must for different
bandwidth clients. Another long time todo.
> That could cost some host cpu though, but lower bandwidth...
> There is certainly room for experimentation, improvements and tweaking!
> > The advantage to that crazy proposal is that it would likely make the
> > pure html5 client work 'perfectly'. The obvious disadvantage is that
> > it
> > would consume a lot more cpu resources on the host, although it's not
> > clear to me how substantial that would be.
> In general video compression is substantially more intensive than
> image compression. Long time ago, I ran some checks with vp8 (and webp)
> with speed encoding params (low quality) and it was like ~x10-x20 slower
> than jpeg-turbo iirc. Would be worth re-doing those tests, it's not
> difficult. But I was discouraged to look further at that time.
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
More information about the Spice-devel