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
