[Libva] [PATCH 00/16] libva: wayland support

[Gwenole Beauchesne]

Hi,

2012/6/28 Zhao, Halley <halley.zhao at intel.com>:
> I know the shortcoming of current implementation.
> Then could you give an estimation date if we have to wait for your YUV texture support in mesa.

Kristian is taking care of this, right now. Well, since the past two days. :)

> Personally, I don't think the problems ruining the usage:
>         - There is few case to change va surface size on the fly.
>         - client can use callback of wl_surface_frame to avoid overwrite.

The most common use-case after playing a single video is two present a
wall/grid of videos, while possibly playing them simultaneously. So,
you should not assume there won't be concurrent usages.

Regards,
Gwenole.

>> -----Original Message-----
>> From: Gwenole Beauchesne [mailto:gb.devel at gmail.com]
>> Sent: Wednesday, June 27, 2012 11:43 PM
>> To: Zhao, Halley
>> Cc: Beauchesne, Gwenole; libva at lists.freedesktop.org
>> Subject: Re: [Libva] [PATCH 00/16] libva: wayland support
>>
>> Hi,
>>
>> 2012/6/27 Zhao, Halley <halley.zhao at intel.com>:
>> > It is not a temporary VA surface, but reuse the region of
>> render_state ( it is not perfect but works).
>>
>> Please don't use render_state, that's generally a bad idea. Besides,
>> there are at least two problems with this approach: (i) if consecutive
>> source VA surfaces have different size, then you reallocate the buffer,
>> (ii) even for two VA surfaces of same size, you would overwrite the
>> buffer, so you won't get the expected rendered contents.
>>
>> Really, vaGetSurfaceBufferWl() only needs to expose the VA surface
>> buffer as is, without conversion whatsoever. If source VA surface is
>> YUV, wl_buffer is YUV, if it is RGB, then it is RGB. If the client
>> application wants an RGBA format, (i) it knows about it and controls it,
>> (ii) it uses VA/VPP to perform the color-conversion to that format, and
>> assures the lifetime of the RGBA VA surface.
>>
>> Regards,
>> Gwenole.