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:[email protected]] >Sent: Wednesday, September 14, 2016 3:53 PM >To: Xiang, Haihao <[email protected]> >Cc: [email protected] >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 <[email protected]>: >> >> >> 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 <[email protected]>: >>> > >>> > >>> > 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 <[email protected]>: >>> > > > >>> > > > 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 <[email protected]> >Blade -- 90 avenue des Ternes, 75017 Paris _______________________________________________ Libva mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/libva
