[Libva] Image corruption with overlay on Up board

[Xiang, Haihao]

I don't see issue with subpicture. Are you using libva-intel-driver? If yes, could you file a bug on https://bugs.freedesktop.org/ with component set to libva and product set to Intel.
It would be better to provide your test case.

Thanks
Haihao


>-----Original Message-----
>From: Yann Dirson [mailto:yann.dirson at blade-group.com]
>Sent: Wednesday, September 14, 2016 3:53 PM
>To: Xiang, Haihao <haihao.xiang at intel.com>
>Cc: libva at lists.freedesktop.org
>Subject: Re: [Libva] Image corruption with overlay on Up board
>
>I had also tested a couple of tests around this idea, and just refreshed my
>patches to check again:
>* calling vaAssociate (still on all 3 surfaces) just before vaPutSurface (drawing
>into it just before or just after vaAssociate), and vaDeassociate just after: no
>improvement
>* associating to just the surface to be drawn: no improvement
>* associating just the overlays to be drawn, and not those currently
>hidden: makes the problem less visible:
>  - no corruption seen when overlay not drawn, but we still see it transiently
>when activating the overlay (no visible change when swapping order of
>redraw and vaAssociate)
>  - corruption still there when overlay is displayed
>
>
>2016-09-14 3:59 GMT+02:00 Xiang, Haihao <haihao.xiang at intel.com>:
>>
>>
>> You should call vaDeassociateSubpicture() to remove the association of
>> the subpicture with your target surface.
>>
>> Thanks
>> Haihao
>>
>>> Oh, you're right, I ought to check my facts better, it is 0.7.0.
>>> Just updated the yocto recipes for 0.7.2, and I get the same symptom.
>>>
>>> As for the symptom itself, the description was not quite correct
>>> either: the short horizontal lines
>>> are not black, when the subpicture is displayed they are of the color
>>> of the underlying image  (as if the subpicture had some
>>> fully-transparent lines), and when removing the subpicture they are
>>> of the color of the subpicture (much more visible when something was
>>> drawn in the subpicture other than the background)
>>>
>>> Here is what I'm doing:
>>> * identify subpicture format for bgra in what
>>> vaQuerySubpictureFormats returns
>>> * vaCreateImage with that format and the size of my overlay
>>> * vaMapBuffer of the image's buf, and vaCreateSubpicture
>>> * vaAssociateSubpicture with all the 3 surfaces I'm using for
>>> decoding
>>> * redraw in the mapped buffer (fill with a background with an alpha)
>>> between vaEndPicture and vaPutSurface
>>> * to remove the overlay, I just memset the buffer with 0
>>>
>>>
>>> 2016-09-13 10:10 GMT+02:00 Xiang, Haihao <haihao.xiang at intel.com>:
>>> >
>>> >
>>> > How did you add the rectangle overlay?
>>> >
>>> > BTW did you build libva-x11 from the latest source code? We don't
>>> > have
>>> > libva-x11 0.7.1
>>> >
>>> > Thanks
>>> > Haihao
>>> >
>>> >
>>> > > Hello,
>>> > >
>>> > > It is libva-x11 0.7.1
>>> > >
>>> > > Thanks
>>> > >
>>> > > 2016-09-13 4:23 GMT+02:00 Xiang, Haihao <haihao.xiang at intel.com>:
>>> > > >
>>> > > > Hi Yann,
>>> > > >
>>> > > > Are you using libva? what is v0.7.1 / v0.7.2?
>>> > > >
>>> > > > Thanks
>>> > > > Haihao
>>> > > >
>>> > > > > I have a decoding app which successfully decodes an h.264
>>> > > > > stream on several platforms, both with i965 and amdgpu
>>> > > > > backends. If I add a simple rectangle overlay on one part of
>>> > > > > the stream, while it's working on some i965 platforms, on the
>>> > > > > UP board we can see a good number of horizontal short black
>>> > > > > line artifacts on the overlay area while it's displayed, and
>>> > > > > a very large quantity of them once the overlay is removed.
>>> > > > > The artifacts progressively with each frame, as long as no
>>> > > > > overlay is modified.
>>> > > > >
>>> > > > > Is this a problem others have seen ?  Could it come from a
>>> > > > > wrong usage of overlays, which only by just luck works
>>> > > > > elsewhere ?
>>> > > > >
>>> > > > > This is using v0.7.1 (0.7.2 changes do not mention any fix of
>>> > > > > the sort).
>>> > > > >
>>> > >
>>> > >
>>> > >
>>>
>>>
>>>
>
>
>
>--
>Yann Dirson <yann at blade-group.com>
>Blade -- 90 avenue des Ternes, 75017 Paris