[Spice-devel] xf86-video-qxl performance

[John A. Sullivan III]

On Mon, 2012-05-28 at 12:59 +0300, Alon Levy wrote:
> On Mon, May 28, 2012 at 11:29:23AM +0200, Attila Sukosd wrote:
> > Low latency (and relatively low bandwidth) video streaming can be done with
> > x264 and xvid (low enough for a 3d game to be playable over the net)
> > However, it introduces licensing issues and high-ish CPU usage on the host
> > side :(
> 
> The later is fixable with hw based compression.
> 
This post was made to the X2Go mailing list a little less than a year
ago:

I read about this today and and although not a developer I wondered if
this could possibly be another
means to migrate from the NX libraries ?   It is for real time
communications?

http://www.h-online.com/open/news/item/Google-open-source-WebRTC-for-open-video-audio-chat-1253848.html

"Google's WebRTC codecs and intellectual property are all royalty-free,
come with a patent grant and the source code is available under a BSD
licence. Google obtained the underlying audio technology when it
acquired Global IP Solutions in May 2010. GIPS was known for it's
narrowband iLBC and wideband iSAC voice codecs. 

These codecs, along with Google's VP8 video codec are brought together
in a communications stack which includes network connection technology. 

The network components manage NAT and firewall traversal, implement
buffering and error concealment for the audio and video streams and
offer support for peer to peer connections."

> > 
> > 
> > On Mon, May 28, 2012 at 11:19 AM, Alon Levy <alevy at redhat.com> wrote:
> > 
> > > On Thu, May 24, 2012 at 01:24:05PM -0500, Jeremy White wrote:
> > > > > Actually, for WAN, we require ACK for 40 messages, but we allow sending
> > > > > up to 80, without getting an ack for the first 40.
> > > > > From my experience with Windows guest, it sounds like the DRAW_FILL
> > > > > commands might be related to anti aliasing, and maybe the future RENDER
> > > > > support that Alon mentioned will indeed help with this. Meanwhile I
> > > > > would also try to disable off-screen surfaces, as was also mentioned in
> > > > > a previous reply,
> > > >
> > > > Ah, yes, sorry; I knew 20 was imprecise.   But (500 / 80) * 80 ms is
> > > > still a good bit of delay.
> > > >
> > > > Increasing the ack window (and pipe size) by a factor of 10 makes the
> > > > first apparent problem vanish.
> > > >
> > > > Disabling off screen surfaces has the same user visible effect.
> > > >
> > > > Note, though, that I have the luxury of focusing on a long term agenda,
> > > > so I'd rather pursue the 'best' solution (at least for now).
> > > >
> > > >
> > > > > What OS your client has? When spice-server identifies WAN, it
> > > > > automatically turn on Nagle's for the display channel (turns off
> > > > > TCP_NODELAY), which should aggregate small tcp messages. However, it
> > > has
> > > > > bad interaction with the delayed acks on the client side (especially in
> > > > > Windows clients, where the default delayed ack timeout is 200ms iirc),
> > > > > and overall it can lead to bigger latency between operations. We are
> > > > > planning to get read of this, and aggregate the messages on the
> > > > > application layer instead.
> > > >
> > > > I'm currently testing with Debian testing, although our eventual
> > > > deployment platform will be a heavily modified RHEL 6 system.  The
> > > > pointer to TCP_NODELAY is also a good one; I'll play with that and see
> > > > what effect it has.
> > > >
> > > > > Just to clarify, we currently don't condense messages in spice-server,
> > > > > though it is another item in our TODO.
> > > >
> > > > Ah, okay, that's helpful (although there is some very limited pruning in
> > > > red_worker.c, no?)
> > > >
> > > > Is that todo on anyone’s immediate radar?  I'm certainly not qualified,
> > > > but it seems like that could have an major impact on what we're trying
> > > > to achieve (regular Office applications hosted on a pure Linux server
> > > > across a WAN).  So perhaps I need to become qualified :-/.
> > >
> > > I have a patchset that didn't seem to do anything so I let it go, but if
> > > you'd like I can find it (that's the hard part) and put it somewhere you
> > > can have a look. It aggregates packets at the application layer
> > > (server/red_channel.c)
> > >
> > > >
> > > > Cheers,
> > > >
> > > > Jeremy
> > > > _______________________________________________
> > > > 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
> > >
> 
> > _______________________________________________
> > 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