[Bug 105145] vaExportSurfaceHandle interaction with surface interlaced flag prevents switching on vaapi deinterlacing dynamically

[bugzilla-daemon@freedesktop.org]

[-- Attachment #1.1: Type: text/plain, Size: 3326 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=105145

            Bug ID: 105145
           Summary: vaExportSurfaceHandle interaction with surface
                    interlaced flag prevents switching on vaapi
                    deinterlacing dynamically
           Product: Mesa
           Version: git
          Hardware: All
                OS: All
            Status: NEW
          Severity: major
          Priority: medium
         Component: Drivers/Gallium/radeonsi
          Assignee: dri-devel@lists.freedesktop.org
          Reporter: k.philipp@gmail.com
        QA Contact: dri-devel@lists.freedesktop.org

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=vaapi /path/to/interlaced/video.mkv
(add --gpu-context=wayland 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 VASurfaceID)"
and not get any deinterlacing. Having deinterlacing enabled from the beginning
(e.g. with "--deinterlace=yes") works, since no unprocesssed surface 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=9d21dbeb88bc99ca0e153c11265e19536ad36b61#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 (see
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/va/surface.c?id=9d21dbeb88bc99ca0e153c11265e19536ad36b61#n966)
- Now we want to turn on postproc.
- Create surfaces for postproc. They are, again, marked interlaced by default
- 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
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/va/postproc.c?id=9d21dbeb88bc99ca0e153c11265e19536ad36b61#n131)

Reporting this against the radeonsi driver since I couldn't test with anything
else, but the issue may really be in how vlVaExportSurfaceHandle works on all
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 blits. 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 5185 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel