From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MWu94-0002fH-Cl
	for qemu-devel@nongnu.org; Fri, 31 Jul 2009 11:35:46 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MWu90-0002e1-ML
	for qemu-devel@nongnu.org; Fri, 31 Jul 2009 11:35:46 -0400
Received: from [199.232.76.173] (port=46192 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MWu90-0002dw-Iz
	for qemu-devel@nongnu.org; Fri, 31 Jul 2009 11:35:42 -0400
Received: from qw-out-1920.google.com ([74.125.92.144]:17776)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1MWu90-0000Bj-9f
	for qemu-devel@nongnu.org; Fri, 31 Jul 2009 11:35:42 -0400
Received: by qw-out-1920.google.com with SMTP id 5so1070401qwc.4
	for <qemu-devel@nongnu.org>; Fri, 31 Jul 2009 08:35:41 -0700 (PDT)
Message-ID: <4A730F48.7050106@codemonkey.ws>
Date: Fri, 31 Jul 2009 10:35:36 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH] Add JPEG encoding to VNC server
References: <1249024897-11100-1-git-send-email-agraf@suse.de>
	<20090731152750.GA31833@shareable.org>
In-Reply-To: <20090731152750.GA31833@shareable.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jamie Lokier <jamie@shareable.org>
Cc: qemu-devel@nongnu.org, kraxel@redhat.com, Alexander Graf <agraf@suse.de>, stefano.stabellini@eu.citrix.com

Jamie Lokier wrote:
> Alexander Graf wrote:
>   
>> While this might sound like it renders the whole implementation useless, it
>> does make sense to implement it nevertheless. I have some ideas to implement
>> progressive encodings for video.
>>
>> So when we'd detect that one region is updated a lot in a short
>> about of time with content that zlib can't really handle well, we'd
>> just send a really low quality JPEG first and then send the update
>> after a timer if the region wasn't updated within that timeframe.
>>     
>
> Detecting video regions may also be possible if virtual video overlay
> hardware can be offered.  It would probably require a special guest
> driver.  virtio-video :-)

vmware-vga can do it already.

I don't want to send JPEG, I'd rather send YUV.  The nice thing about an 
overlay is that you get the yuv data directly and you get small update 
regions (which is a feature of vmware-vga).  The nice thing is that you 
get pretty close to mpeg encoding with that.  If a blit is used for tile 
motion, that's even better.

Also, hardware scaling could be coded effectively too.

>  Then again the trend, if you believe in the
> <video> element demos in web browsers, is likely towards OpenGL-driven
> video frame rendering because it's more versatile.
>
> Sending JPEG quality first and a lossless update after is an
> interesting idea, even for non-video.  On a slow link, seeing boxes
> and buttons appear quickly might be quicker to click through a GUI, as
> you can see where to click even if the text and decorations are a bit
> fuzzy for a moment.  Especially if you already know what to expect.
>
> Is it possible to use any of the lossless or "near-lossless" JPEG
> encodings, and would that be any more efficient than VNC's usual
> lossless encoding?
>   

near-lossless is going to result in very large images.  I'm quite sure 
it's worse than even hextile.

OTOH, zlib compressed raw tiles is probably pretty close to as good as 
hextile and it's quite easy to do.  Alex has already done it once for 
the zlib encoding :-)

Regards,

Anthony Liguori