Commen=
t # 8
on bug 10514=
5
from Christian K=C3=
=B6nig
(In reply to k.philipp from comment #7)
> I did think about that, but it has the problem o=
f breaking deinterlacing on
> all clients that do *not* set VA_SURFACE_ATTRIB_USAGE_HINT_VPP_READ (w=
hich I
> assume to be most) since there is - correct me if I'm wrong - at prese=
nt no
> code to un-weave a decoded frame to fields and go back to interlaced/f=
ield
> mode, causing the initial issue in the first place.
Yeah, we can't do this without at least adding this frame to field conversi=
on.
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 voluntee=
ring 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 st=
ate
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 fra=
me
into two fields. I can search for the code if you're interested.