[Libva] vaDeriveImage returns wrong image size, data size and strange fourcc NV11.

[Gwenole Beauchesne]

Hi,

This is an issue in the EMGD driver that is still present in version 1.16.

The dimensions are not reported correctly in the resulting VAImage,
though the pitch information is. Please report a bug in Intel Premier.
Another test application is hwdecode-demos with vaapi_h264 invoked
with --getimage for example. The VAImage.{width,height} fields should
match the VA surface dimensions. The VAImage.pitches[] can match the
underlying implementation needs, e.g. next-power-of-two.

Thanks,
Gwenole.

2013/4/19 ykzhao <yakui.zhao at intel.com>:
> On Wed, 2013-04-17 at 10:40 -0600, kwisp wrote:
>> On 17 April 2013 08:44, ykzhao <yakui.zhao at intel.com> wrote:
>>         On Tue, 2013-04-16 at 12:26 -0600, kwisp wrote:
>>         > I use standart libva example
>>         >
>>         http://cgit.freedesktop.org/libva/tree/test/decode/mpeg2vldemo.c
>>         >
>>         >
>>         > I try retrive image by calling vaDeriveImage after decoding
>>         and
>>         > recieve stange VAImage.
>>         >
>>         > image.width = 512 image.height = 32 image.data_size=16384
>>         > image.numplanes=2
>>         >
>>         > image.format.fourcc = NV11 image.offsets[0] = 0,
>>         image.offsets[1] =
>>         > 16384, image.pitches[0] = image.pitches[1] = 512.
>>         >
>>         >
>>         > If I convert this VAImage data to normaly FOURCC format I
>>         see correct
>>         > picture.
>>         >
>>
>
> The vaDeriveImage is used to read/write the image content from the
> corresponding decoded buffer. And we don't need to care whether the
> width/height of derived image is different with real image size(The
> width/height of derived image is determined by the video hardware).
> We should follow the corresponding offset/pitches to read the buffer.
>
>>
>>         Will you please describe how you call the vaDeriveImage in
>>         your
>>
>> libva: libva version 0.32.0
>> libva: va_getDriverName() returns 0
>> libva: Trying to open /usr/lib/dri/emgd_drv_video.so
>> Intel(R) Embedded Media and Graphics Driver 1.10 Build 2209
>> libva: va_openDriver() returns 0
>> 3 image formats
>> 0 - imageFormat: fourcc(41424752), byteOrger(1), bitsPerPixel(32),
>> depth(32), redM(16711680), greenM(65280), alphaM(4278190080)
>> 1 - imageFormat: fourcc(32595559), byteOrger(1), bitsPerPixel(16),
>> depth(0), redM(0), greenM(0), alphaM(0)
>> 2 - imageFormat: fourcc(32315659), byteOrger(1), bitsPerPixel(12),
>> depth(0), redM(0), greenM(0), alphaM(0)
>> imageinfo: w:14, h:0, data_size:3075098360, planes:3073595636,
>> palettes:2195, bytes:-1221371576, comp_order ┬q╥, fourcc:bfa809f0
>> pitch[0]=4131212846, offset[0]=0
>> pitch[1]=3075553328, offset[1]=0
>> pitch[2]=18, offset[2]=1
>> surface status: 4
>> vaDeriveImage
>> imageinfo: w:512, h:32, data_size:16384, planes:2, palettes:0,
>> bytes:0, comp_orderYUV, fourcc:3231564e
>> pitch[0]=512, offset[0]=0
>> pitch[1]=512, offset[1]=16384
>> pitch[2]=0, offset[2]=0
>> img:0xb6bf9000, size:16384
>> 24576 bytes written
>> press any key to exit
>>
>
> For the above info about the vaDeriveImage, it seems that fourcc,
> pitches/offset is right.
> Fourcc: 3231564E: (NV12 format).
> pitches and offsets are also right.
>
> What is wrong when you try to read the image by using the above example
> code?
>
>> OS: Linux Debian Squeeze
>>
>> Driver: EMGD 1.10
>>
>> Xorg: 1.10
>>
>> What do you whant to know about platform?
>>
>>
>> --
>> -----------------------------------------
>> С Уважением, Клочков В.В.
>> mailto: kwispost at gmail.com
>
>
> _______________________________________________
> Libva mailing list
> Libva at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libva