[Libva] Question about vaPutSurface

[Jean-Yves Avenard]

Hi

On 25 June 2014 14:35, Gwenole Beauchesne <gb.devel at gmail.com> wrote:
>
> Have you checked with the XPixmap or through TFP/GL only?
> You can use the X RENDER extension to display that pixmap if you want.

Only via TFP/GL

The display is fully OpenGL rendered. As such, the only thing changed
here, is upon your advice replace the vaCopySurfaceGLX with
vaPutSurface.

So the call to vaCopySurfaceGLX has been replaced with:
- Create the XPixmap
- Create the GLXPixmap from that XPixmap
- Bind the GLXPixmap to the surface that is going to be rendered (via
glXBindTexImageEXT)

The XBitmap is of the same dimension of the source frame (and of the
target surface).

I didn't expect to see a different behaviour from our earlier use of
vaCopySurfaceGLX

>
> Note: if your clip provides clipping regions, this needs to be
> honoured as follows:
> src_rect will be the crop region
> dst_rect will be the source video size minus the crop size, with
> origin = (0,0). You pixmap should have the cropped size too btw.

there's no clipping region, no clipping should occur seeing that both
the source and destination are of the same size.

I admit I'm not an expert in how the XPixmap will behave, seeing that
this is the first time I use glXBindTextImageEXT


>
> The first step is to validate the X pixmap itself. If you don't have
> cropping in the clip, then vaPutSurface() to a Pixmap must work as
> follows:

The content of the X pixmap is only filled via vaPutSurface, I guess I
could display/save it on the side and see what's in it after the call
to vaPutSurfaces.

I'll try that later today and report...

> src_rect to match the video size with origin = (0, 0)
> dst_rect to match the pixmap size with origin = (0, 0)

this is what is occurring.
src_rect == video_size == dest_rect == pixmap size

>
> If this doesn't work, please fill in a bug report. This must be fixed.

I'm interesting in what the XBMC folks are seeing, the changes I've
made is very similar to theirs...

As I noted earlier, vaCopySurfaceGLX works great for me with the intel
libva drivers, but using the AMD's vaapi Xvba backend, I notice a
similar behaviour, the result image is stretched.

definitely something dogy here, and a difference of behaviour between
the various libva drivers