On Wed, May 23, 2012 at 10:02:03PM -0400, Marc-André Lureau wrote: > Hi > > ----- 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@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/spice-devel _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel