From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:39287)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1TtC5R-0000GO-2h
	for qemu-devel@nongnu.org; Thu, 10 Jan 2013 01:58:02 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1TtC5Q-0005kV-5K
	for qemu-devel@nongnu.org; Thu, 10 Jan 2013 01:58:01 -0500
Received: from mx1.redhat.com ([209.132.183.28]:58373)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1TtC5P-0005kQ-TK
	for qemu-devel@nongnu.org; Thu, 10 Jan 2013 01:58:00 -0500
Message-ID: <50EE6673.8030107@redhat.com>
Date: Thu, 10 Jan 2013 07:57:55 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
References: <1357752469-17825-1-git-send-email-david.verbeiren@intel.com>
	<8738ya6r3h.fsf@codemonkey.ws>
	<5650EBDE-4AAA-407A-829B-648E42B9DBB5@suse.de>
In-Reply-To: <5650EBDE-4AAA-407A-829B-648E42B9DBB5@suse.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH] ui/vnc: VA API based H.264 encoding for
 VNC framebuffer updates
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Alexander Graf <agraf@suse.de>
Cc: Anthony Liguori <aliguori@us.ibm.com>, David Verbeiren <david.verbeiren@intel.com>, qemu-devel@nongnu.org

On 01/09/13 23:18, Alexander Graf wrote:
> 
> On 09.01.2013, at 21:25, Anthony Liguori wrote:
> 
>> 
>> Since we really can't guarantee that libva will initialize okay, we
>> need to more gracefully handle falling back to another encoding
>> type.
> 
> In fact, doesn't libavcodec / gstreamer support vaapi? If we could
> just send our updates to a library and have that determine whether
> vaapi is available or maybe fall back to software H.264 encoding,
> people without vaapi compatible hardware (or software) could exploit
> this feature too.

Using libavcodec directly is a non-starter as distros don't ship that
due to the multimedia codec patent mess.

gstreamer should be workable, and thanks to the plugin system you can
even use libavcodec indirectly if it happens to be installed (from 3rd
party repo).

cheers,
  Gerd