[Libva] vaDeriveImage returns wrong image size, data size and strange fourcc NV11.
kwisp
kwispost at gmail.com
Tue Apr 23 20:42:30 PDT 2013
thank you.
I understand how work with vaDeriveImage.
:)
On 23 April 2013 06:52, ykzhao <yakui.zhao at intel.com> wrote:
> On Mon, 2013-04-22 at 11:40 -0600, kwisp wrote:
> > >>>Fourcc: 3231564E: (NV12 format).
> >
> > In va/va.h file 3231564E is NV11 format.
>
> Really? Which branch of libva is you using?
> #define VA_FOURCC_NV12 0x3231564E
> #define VA_FOURCC_NV11 0x3131564e
>
> Will you please double check it again?
> > >>>What is wrong when you try to read the image by using the above/* a
> > few common FourCCs */
> > example
> > code?
> >
> > Nothing. I can get valid image using pithches and offsets. But I am
> > afraid of wrong data size. Who can guarantee that my code do not crash
> > outside the image.data_size?
> >
> In theory you can't read/write the image buffer that is beyond
> image.data_size. It is developer's responsibility to assure the
> reading/writing the correct size. Per my understanding the
> image.data_size should be the size of image buffer. If so, the EMGD
> driver doesn't return the correct size. The real buffer size should be
> 1.5 * image.data_size.
>
> > Gwenole, thank you.
> >
> >
> >
> > On 19 April 2013 20:10, Gwenole Beauchesne <gb.devel at gmail.com> wrote:
> > 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
> >
> >
> >
> > --
> > -----------------------------------------
> > С Уважением, Клочков В.В.
> > mailto: kwispost at gmail.com
>
>
>
--
-----------------------------------------
С Уважением, Клочков В.В.
mailto: kwispost at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libva/attachments/20130424/dbb78af0/attachment.html>
More information about the Libva
mailing list