| 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.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
