Hi,
you can specify the fourcc when creating a VA surface for JPEG decoding, please refer to
the code in libva-utils:
if (h1 == 2 && h2 == 1 && h3 == 1 &&
v1 == 2 && v2 == 1 && v3 == 1) {
//surface_type = VA_RT_FORMAT_IMC3;
surface_type = VA_RT_FORMAT_YUV420;
forcc.value.value.i = VA_FOURCC_IMC3;
ChromaTypeIndex = 1;
type = "VA_FOURCC_IMC3";
}
...
va_status = vaCreateSurfaces(va_dpy,surface_type,
priv->width[scan_num],priv->height[scan_num],
&surface_id, 1, &forcc, 1);
Thanks
Haihao
> Hi Xiang,
>
> I use vaCreateSurfaces() now.
> But it does not allocate surface actually, which means obj_surface->bo
> is not allocated due to this condition
> (
https://github.com/01org/intel-vaapi-driver/blob/master/src/i965_drv_vide...
> L1457).
> The condition is false in using vaCreateSurfaces, until
> expected_fourcc is specified by attrib_list.
> I am not sure there is a way to find the appropriate fourcc when
> calling vaCreateSurfaces (before rendering).
> If there is, my problem would be resolved.
>
> Best,
> Hirokazu Honda
>
> On Wed, Jul 12, 2017 at 9:19 AM, Xiang, Haihao <haihao.xiang(a)intel.com>
wrote:
> >
> > Sorry, I mean vaCreateSurfaces().
> >
> > > Hi Xiang,
> > >
> > > What is vaCreateSurface()?
> > > There is only vaCreaateSurfaces() in libva.
> > >
> > > Best,
> > > Hirokazu Honda
> > >
> > > On Mon, Jul 10, 2017 at 4:49 PM, Xiang, Haihao
<haihao.xiang(a)intel.com>
> > > wrote:
> > > >
> > > > How did you call vaCreateSurface() to create the surface?
> > > >
> > > > > Hi, Qu
> > > > >
> > > > > I found why my program didn't work correctly.
> > > > > I used DeriveImage and DestroyImage to compute the memory usage
of
> > > > > VASurface.
> > > > > I noticed that the memory for VASurface is not allocated in
> > > > > createSurfaces.
> > > > > Instead, it will be allocated in calling DeriveImage and
(probably?)
> > > > > EndPicture.
> > > > > The problem happened because fourcc decided in DeriveImage
differed
> > > > > from one decided in EndPicture.
> > > > > When DeriveImage is called, if fourcc is not decided yet,
DeriveImage
> > > > > guesses it and allocated VASurface with fourcc.
> > > > > However, because EndPicture will not use that fourcc, decoding
results
> > > > > is incorrected.
> > > > >
> > > > > What I would like to do is to compute the memory usage as soon
as
> > > > > possible after calling createSurface.
> > > > > I think the problem is createSurfaces does not allocate the
memory of
> > > > > Surface.
> > > > > Also, seeing document, it seems DeriveImage and DestroyImage do
not
> > > > > have any side effect.
> > > > > But DeriveImage actually has.
> > > > >
> > > > > Best,
> > > > > Hirokazu Honda
> > > > >
> > > > > On Fri, Jul 7, 2017 at 7:44 PM, Qu, Pengfei
<pengfei.qu(a)intel.com>
> > > > > wrote:
> > > > > > Hi Honda,
> > > > > >
> > > > > > I think you are debugging as jpegdecoder does not work.
Right? I am
> > > > > > not
> > > > > > sure
> > > > > > I catch your issue.
> > > > > >
> > > > > > For the Jpeg decoder, I guess the following only render part
of
> > > > > > buffer.
> > > > > >
> > > > > > if (pending_va_bufs_.size() > 0) {
> > > > > > // Commit parameter and slice buffers.
> > > > > > va_res = vaRenderPicture(va_display_, va_context_id_,
> > > > > > &pending_va_bufs_[0],
> > > > > > pending_va_bufs_.size());
> > > > > > VA_SUCCESS_OR_RETURN(va_res, "vaRenderPicture for
va_bufs
> > > > > > failed",
> > > > > > false);
> > > > > > }
> > > > > >
> > > > > > if (pending_slice_bufs_.size() > 0) {
> > > > > > va_res =
> > > > > > vaRenderPicture(va_display_, va_context_id_,
> > > > > > &pending_slice_bufs_[0],
> > > > > > pending_slice_bufs_.size());
> > > > > > VA_SUCCESS_OR_RETURN(va_res, "vaRenderPicture for
slices
> > > > > > failed",
> > > > > > false);
> > > > > > }
> > > > > >
> > > > > > vaRenderPicture is called as the following order for each
buffer.
> > > > > > ==========================================================
> > > > > >
https://github.com/01org/libva-utils/blob/master/decode/tinyjpeg.c
> > > > > >
> > > > > > va_status = vaBeginPicture(va_dpy,
context_id,
> > > > > > surface_id);
> > > > > > CHECK_VASTATUS(va_status,
"vaBeginPicture");
> > > > > >
> > > > > > va_status = vaRenderPicture(va_dpy,context_id,
> > > > > > &pic_param_buf,
> > > > > > 1);
> > > > > > CHECK_VASTATUS(va_status,
"vaRenderPicture");
> > > > > >
> > > > > > va_status = vaRenderPicture(va_dpy,context_id,
&iqmatrix_buf,
> > > > > > 1);
> > > > > > CHECK_VASTATUS(va_status,
"vaRenderPicture");
> > > > > >
> > > > > > va_status = vaRenderPicture(va_dpy,context_id,
> > > > > > &huffmantable_buf,
> > > > > > 1);
> > > > > > CHECK_VASTATUS(va_status,
"vaRenderPicture");
> > > > > >
> > > > > > va_status = vaRenderPicture(va_dpy,context_id,
> > > > > > &slice_param_buf,
> > > > > > 1);
> > > > > > CHECK_VASTATUS(va_status,
"vaRenderPicture");
> > > > > >
> > > > > > va_status = vaRenderPicture(va_dpy,context_id,
> > > > > > &slice_data_buf,
> > > > > > 1);
> > > > > > CHECK_VASTATUS(va_status,
"vaRenderPicture");
> > > > > >
> > > > > > va_status = vaEndPicture(va_dpy,context_id);
> > > > > > CHECK_VASTATUS(va_status,
"vaEndPicture");
> > > > > >
> > > > > >
================================================================
> > > > > >
> > > > > > Thanks,
> > > > > > Pengfei
> > > > > > -----Original Message-----
> > > > > > From: intel-vaapi-media
[mailto:intel-vaapi-media-bounces@lists.01.o
> > > > > > rg]
> > > > > > On
> > > > > > Behalf Of Hirokazu Honda
> > > > > > Sent: Friday, July 7, 2017 9:45 AM
> > > > > > To: intel-vaapi-media(a)lists.01.org
> > > > > > Subject: [intel-vaapi-media] Does DeriveImage and
DestroyPicture
> > > > > > affects
> > > > > > decoding jpeg?
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I use DeriveImage to compute the memory usage of
VASurface.
> > > > > > There is no function in libva to obtain
obj_surface->size, except
> > > > > > this
> > > > > > function.
> > > > > > The image gotten by vaDeriveImage is destroyed by
vaDestroyImage.
> > > > > > However, decoding does not work correctly in jpeg
decoding.
> > > > > > More precisely, the decoding with HW codec is too different
from one
> > > > > > with
> > > > > > Soft codec, although no error happens in each libva
function.
> > > > > > I also confirmed video decodeing result is good and there is
no
> > > > > > problem.
> > > > > > The different points between jpeg decoding and video
decoding is the
> > > > > > buffer
> > > > > > contents that are passed to vaRenderPicture
(
https://cs.chromium.org
> > > > > > /chr
> > > > > > omiu
> > > > > >
m/src/media/gpu/vaapi_jpeg_decoder.cc?type=cs&q=vaapi_jpeg_&sq=packa
> > > > > > ge:c
> > > > > > hrom
> > > > > > ium&l=248).
> > > > > >
> > > > > > According to libva document, DeriveImage and DestroyImage
does not
> > > > > > have
> > > > > > any
> > > > > > side effects. Then, it seems wired that decoding does not
works
> > > > > > correctly
> > > > > > only if these functions are inserted before vaEndPicture
like below
> > > > > > (https:/
> > > > > >
/cs.chromium.org/chromium/src/media/gpu/vaapi_wrapper.cc?type=cs&sq=
> > > > > > pack
> > > > > > age:
> > > > > > chromium&l=826).
> > > > > >
> > > > > > > VA_SUCCESS_OR_RETURN(va_res, "vaRenderPicture
for slices
> > > > > > > failed",
> > > > > > > false);
> > > > > > > }
> > > > > > >
> > > > > > > + VAImage image;
> > > > > > > + va_res = vaDeriveImage(va_display_, va_surface_id,
> > > > > > > &image); va_res
> > > > > > > + = vaDestroyImage(va_display_, image.image_id);
> > > > > > > +
> > > > > > > // Instruct HW codec to start processing committed
buffers.
> > > > > > > // Does not block and the job is not finished after
this
> > > > > > > returns.
> > > > > > > va_res = vaEndPicture(va_display_, va_context_id);
> > > > > > > VA_SUCCESS_OR_RETURN(va_res, "vaEndPicture
failed", false);
> > > > > >
> > > > > >
> > > > > >
> > > > > > Best,
> > > > > > Hirokazu Honda
> > > > > > _______________________________________________
> > > > > > intel-vaapi-media mailing list
> > > > > > intel-vaapi-media(a)lists.01.org
> > > > > >
https://lists.01.org/mailman/listinfo/intel-vaapi-media
> > > > > _______________________________________________
> > > > > intel-vaapi-media mailing list
> > > > > intel-vaapi-media(a)lists.01.org
> > > > >
https://lists.01.org/mailman/listinfo/intel-vaapi-media