[Libva] Image corruption with overlay on Up board

[Yann Dirson]

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