vaapi: Scrambled rendering for some h.264 videos with glimagesink on AMD GPU
Submitted by Philippe Normand @philn
Link to original bug (#796584)
Description
vainfo:
libva info: VA-API version 1.1.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_1
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.1 (libva 2.1.0)
vainfo: Driver version: mesa gallium vaapi
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileHEVCMain : VAEntrypointVLD
VAProfileHEVCMain10 : VAEntrypointVLD
VAProfileJPEGBaseline : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProc
Scrambled rendering with: https://download.blender.org/durian/trailer/Sintel_Trailer.480p.DivX_Plus_HD.mkv
No rendering issue with: https://trac.webkit.org/export/232834/webkit/trunk/LayoutTests/media/content/test.mp4
Designs
- Show closed items
Activity
-
Newest first Oldest first
-
Show all activity Show comments only Show history only
Julien Isorce@cap
said:Does it happen only with glimagesink or with videoconvert ! xvimagesink too ?
What are the caps negotiated between vaapih264dec and glimagesink ? Víctor Manuel Jáquez Leal@vjaquez
said:(In reply to Julien Isorce from comment 1)
Does it happen only with glimagesink or with videoconvert ! xvimagesink too
?
What are the caps negotiated between vaapih264dec and glimagesink ?it is only with glimagesink and with this sample (other media files work OK). It is dmabuf negotiated.
Nicolas Dufresne@ndufresne
said:Can you provide a screenshot?
Philippe Normand@philn
said:Here's a screencast: https://owncloud.igalia.com/index.php/s/NyZMdW3gc2ToP5s
Nicolas Dufresne@ndufresne
said:Ok, this is what I had in mind. This is tiled/compressed video displayed as if it was linear. It also means that the DMABuf uploaded in glupload failed and it had falledback to raw uploader. It means the code to ensure that exported DMABuf are linear is broken. This is a problem we get in various scenarios with recent Mesa.
Shall we fail in glupload if DMABuf capsfeature has been chosen and dmabuf uploaded failed ?
Sreerenj Balachandran@sree
said:I have seen similar issues for some specific resolution videos when playing with gst-msdk plugins and glimagesink when negotiating dmabuf.
Sreerenj Balachandran@sree
said:Is this the same issue we discussed multiple times in different bugs and IRC ? "Using vaapipostproc after vaapih264dec fix the issue when using glimagesink in dmabuf mode and egl platform"
- Philippe Normand mentioned in merge request !72 (merged)
mentioned in merge request !72 (merged)
- Developer
Hi, I have narrowed down this issue:
gst-launch-1.0 videotestsrc ! video/x-raw, width=1200, height=720 ! x264enc ! h264parse ! vaapih264dec ! vaapipostproc ! "video/x-raw, format=RGBA" ! glimagesink
case 1: GST_GL_PLATFORM=egl
->
scrambled`case 2: GST_GL_PLATFORM=glx ->
works
(with 1280x720 or 1902x1080 it works in both cases).
There is
no
DMABUF in above pipelines. - Developer
Ah now I remember there can be dmabuf without the caps feature so above still involves DMAbuf.
Issue can be reproduced with a simpler pipeline:
gst-launch-1.0 videotestsrc ! video/x-raw, width=1200, height=720, format=NV12 ! vaapipostproc ! "video/x-raw(memory:SystemMemory), format=RGBA" ! glimagesink
case 1: GST_GL_PLATFORM=egl ->
scrambled
but works with width=1280case 2: GST_GL_PLATFORM=glx ->
works
- Maintainer
Can you attach a screenshot of what you call scrambled. I suspect the dmabuf are non-linear or compressed. We need to port to the new DRM PRIME API, the one that expose the DRM modifiers. For now, this will allow us disabling DMABuf, long term we need to pass the modifier.
- Developer
Just a stride issue, I added traces in mesa/gallium/va and the stride for the returned dmabuf is 4864, and not 1200*4=4800. So in gstgl if I hard code attribs[atti++] = 4864 then it renders correctly.
Otherwise it looks like the following:
- Developer
- Developer
I have a local fix to properly set the stride and offset https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/va/image.c#n283
pipe_resource_reference(&img_buf->derived_surface.resource, surfaces[0]->texture); + pscreen = VL_VA_PSCREEN(ctx); + drv->pipe->flush(drv->pipe, NULL, 0); + memset(&whandle, 0, sizeof(whandle)); + whandle.type = WINSYS_HANDLE_TYPE_FD; + if (pscreen->resource_get_handle(pscreen, drv->pipe, + img_buf->derived_surface.resource, + &whandle, PIPE_HANDLE_USAGE_FRAMEBUFFER_WRITE)) { + img->pitches[0] = whandle.stride; + img->offsets[0] = whandle.offset; + img->data_size = whandle.stride * h; + close((intptr_t) whandle.handle); + } img->buf = handle_table_add(VL_VA_DRIVER(ctx)->htab, img_buf);
But it is not nice. Main issue is that when calling
VaAcquireBufferHandle
there is no way to return the stride and offset so it has to be done in VaDriverImage.Other solution would be to use the new libva API
VaExportSurfaceHandle
https://github.com/intel/libva/blob/master/va/va.h#L3550 . @vjaquez WDYT ?Edited by Julien Isorce - Maintainer
Other solution would be to use the new libva API
VaExportSurfaceHandle
https://github.com/intel/libva/blob/master/va/va.h#L3550 . @vjaquez WDYT ?That's what we need!
The are several issue in our current implementation for dmababuf (e.g.: !27 (closed)), and I don't want devote time on fixing them but rather use vaExportSurfaceHandle. But I haven't find the time to devote on it.
And there are a couple open question:
- Shall we remove/deprecated our current dmabuf handling using vaAcquire/ReleaseBuffer??
- Shall we keep our approach of using a custom allocator or rather we shall add a new element like vaapidownload that would transform a VAmemory featured buffer to a dmabuf/GLMemory/etc
- Developer
Hi Victor, I think when we get time, the sequence should be:
1- if vaExportSurfaceHandle is available, try it. If fail: 2- try vaAcquire 3- fallback
We should keep 2 and 3, we just need to add 1. I believe the custom allocator is still necessary for 1 so it should not be a lot of changes.
In the mean time I am working on a fix here https://bugs.freedesktop.org/show_bug.cgi?id=110443 which should fix #100 (closed)
- Developer
I submitted a fix to mesa mesa/mesa!721 (merged), will see.
- Developer
Hi @philn , please try with latest mesa, I made a couple of patches that are now merged in mesa master and available in latest padoka mesa ppa (1:19.2
git190512201800.974c4d6b~padoka0, https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/mesa)If interested, the patches are here: https://bugs.freedesktop.org/show_bug.cgi?id=110443
- Maintainer
I updated to Mesa git master and libva 2.4.1 and now the DRI driver fails to load:
0:00:00.256178243 28316 0x55baa3ca8410 INFO vaapi gstvaapiutils.c:94:gst_vaapi_log: VA-API version 1.4.1 0:00:00.256217017 28316 0x55baa3ca8410 INFO vaapi gstvaapiutils.c:94:gst_vaapi_log: va_getDriverName() returns 0 0:00:00.256226697 28316 0x55baa3ca8410 INFO vaapi gstvaapiutils.c:94:gst_vaapi_log: Trying to open /home/phil/WebKitBuild/DependenciesGTK/Root/lib/dri/radeonsi_drv_video.so 0:00:00.256287521 28316 0x55baa3ca8410 INFO vaapi gstvaapiutils.c:94:gst_vaapi_log: va_openDriver() returns -1 0:00:00.256297938 28316 0x55baa3ca8410 DEBUG vaapi gstvaapiutils.c:130:vaapi_check_status: vaInitialize(): unknown libva error 0:00:00.256837474 28316 0x55baa3ca8410 INFO vaapi gstvaapiutils.c:94:gst_vaapi_log: VA-API version 1.4.1 0:00:00.257647838 28316 0x55baa3ca8410 INFO vaapi gstvaapiutils.c:94:gst_vaapi_log: va_getDriverName() returns 1 0:00:00.257660739 28316 0x55baa3ca8410 WARN vaapi gstvaapiutils.c:77:gst_vaapi_warning: va_getDriverName() failed with operation failed,driver_name=radeonsi 0:00:00.257667616 28316 0x55baa3ca8410 DEBUG vaapi gstvaapiutils.c:130:vaapi_check_status: vaInitialize(): operation failed 0:00:00.258248617 28316 0x55baa3ca8410 INFO vaapi gstvaapiutils.c:94:gst_vaapi_log: VA-API version 1.4.1 0:00:00.258462500 28316 0x55baa3ca8410 INFO vaapi gstvaapiutils.c:94:gst_vaapi_log: va_getDriverName() returns -1 0:00:00.258474057 28316 0x55baa3ca8410 WARN vaapi gstvaapiutils.c:77:gst_vaapi_warning: va_getDriverName() failed with unknown libva error,driver_name=(null) 0:00:00.258481617 28316 0x55baa3ca8410 DEBUG vaapi gstvaapiutils.c:130:vaapi_check_status: vaInitialize(): unknown libva error
- Maintainer
Shoot. A tpyo in my LIBVA_DRIVERS_PATH! Rendering is correct now for Sintel_Trailer.480p.DivX_Plus_HD.mkv \o/
- Maintainer
vainfo output, for reference:
vainfo: VA-API version: 1.4 (libva 2.4.0) vainfo: Driver version: Mesa Gallium driver 19.2.0-devel for Radeon RX 560 Series (POLARIS11, DRM 3.27.0, 4.19.0-4-amd64, LLVM 7.0.1) vainfo: Supported profile and entrypoints VAProfileMPEG2Simple : VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointVLD VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main : VAEntrypointVLD VAProfileVC1Advanced : VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice VAProfileH264Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointEncSlice VAProfileH264High : VAEntrypointVLD VAProfileH264High : VAEntrypointEncSlice VAProfileHEVCMain : VAEntrypointVLD VAProfileHEVCMain : VAEntrypointEncSlice VAProfileHEVCMain10 : VAEntrypointVLD VAProfileJPEGBaseline : VAEntrypointVLD VAProfileNone : VAEntrypointVideoProc
- Developer
Great news! Thx @philn for having confirmed the issue is fixed. Closing.
- Julien Isorce closed
closed