When decoding interlaced video with VAAPI and least when using=
the radeonsi
driver, it is impossible to postproc-deinterlace a frame from a surface that
was used with vaExportSurfaceHandle() before.
This effectively means that it is impossible to dynamically switch on
deinterlacing mid-stream, i.e. after an *interlaced* frame has been shown
unprocessed with vaExportSurfaceHandle.
Try for example with mpv from git:
mpv -vo gpu --hwdec=3Dvaapi /path/to/interlaced/video.mkv
(add --gpu-context=3Dwayland when running under Wayland, else vaapi will not
work)
give it a few seconds and then switch on deinterlacing with the 'd' key.
You will see the error mesage "vaRenderPicture() failed (invalid VASur=
faceID)"
and not get any deinterlacing. Having deinterlacing enabled from the beginn=
ing
(e.g. with "--deinterlace=3Dyes") works, since no unprocesssed su=
rface is
exported then.
The chain of events seems to be:
- Create surfaces for decoding. They are marked interlaced by default on
radeonsi. (see
https=
://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/radeonsi/si_get.=
c?id=3D9d21dbeb88bc99ca0e153c11265e19536ad36b61#n655
- PREFERS_INTERLACED is always returned as true)
- Export the decoded surfaces with vaExportSurfaceHandle() and present them=
to
the user. This has the side-effect of making the surfaces non-interlaced (s=
ee
htt=
ps://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/va/surf=
ace.c?id=3D9d21dbeb88bc99ca0e153c11265e19536ad36b61#n966)
- Now we want to turn on postproc.
- Create surfaces for postproc. They are, again, marked interlaced by defau=
lt
- Trying to deinterlace gives VA_STATUS_ERROR_INVALID_SURFACE_ID since it
thinks that the source surface is not interlaced, and that the destination
surface is - both of which is wrong (see
ht=
tps://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/va/pos=
tproc.c?id=3D9d21dbeb88bc99ca0e153c11265e19536ad36b61#n131)
Reporting this against the radeonsi driver since I couldn't test with anyth=
ing
else, but the issue may really be in how vlVaExportSurfaceHandle works on a=
ll
drivers.
On a related note, since the radeonsi driver by default generates interlaced
surfaces when using vaCreateSurfaces, vlVaExportSurfaceHandle making them
progressive seems to be the only reason it correctly bob-deinterlaces at the
moment (MADI seems to be fine because it uses another code path). At least
after all output surfaces have been exported once, before that it just blit=
s. I
also consider this a bug that could now be solved at the same time. If not,=
I
can open a new ticket for that.