Comment # 8
on bug 105145
from Christian König
(In reply to k.philipp from comment #7) > I did think about that, but it has the problem of breaking deinterlacing on > all clients that do *not* set VA_SURFACE_ATTRIB_USAGE_HINT_VPP_READ (which I > assume to be most) since there is - correct me if I'm wrong - at present no > code to un-weave a decoded frame to fields and go back to interlaced/field > mode, causing the initial issue in the first place. Yeah, we can't do this without at least adding this frame to field conversion. How about VA_SURFACE_ATTRIB_USAGE_HINT_EXPORT then? The VA-API hints seem to describe the use case instead of the effect, so that would match. > > Now you just need to find somebody volunteering to implement that :) > Using the hint like in your proposal sounds doable to me because it's just > shuffling some code around, but if we have to add de-weaving (is that even a > word?) I'm probably out. Actually not so much of a problem, IIRC we have code for this in the OMX state tracker you could just copy&paste. Basically you allocate a new video buffer and then copy from (0,0)-(width, heigth-1) to the top field and (0,1)-(width,height) to the bottom field of the new buffer using the blitter function. Since the blitter uses nearest pixel interpolation that should slit the frame into two fields. I can search for the code if you're interested.
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
