GNOME Bugzilla – Bug 779642
vaapi: direct download/upload crashes in gallium backends
Last modified: 2018-11-03 15:49:16 UTC
Created attachment 347296 [details] gdb log A window opens and hangs there when trying to use the following piepline gst-launch-1.0 -v filesrc location=/home/gpalsingh/Downloads/serenity_hd_dvd-trailer/Serenity\ -\ HD\ DVD\ Trailer.mp4 \! qtdemux \! h264parse \! vaapidecodebin \! ximagesink
Worth to mention that Gurkirpal told me that it does not crash when using vaapih264dec. So the difference here is vaapipostproc. Gurkirpal, please try: A: gst-launch-1.0 videotestsrc ! "video/x-raw, format=NV12, width=1280, height=720" ! vaapipostproc ! "video/x-raw, format=BGRx, width=1280, height=720" ! ximagesink B: gst-launch-1.0 videotestsrc ! "video/x-raw, format=NV12, width=1280, height=720" ! vaapipostproc ! "video/x-raw, format=BGRA, width=1280, height=720" ! videoconvert ! ximagesink C: gst-launch-1.0 videotestsrc ! "video/x-raw, format=NV12, width=1280, height=720" ! vaapipostproc ! "video/x-raw, format=RGBA, width=1280, height=720" ! videoconvert ! ximagesink D: gst-launch-1.0 videotestsrc ! "video/x-raw, format=NV12, width=1280, height=720" ! vaapipostproc ! "video/x-raw, format=RGBx, width=1280, height=720" ! videoconvert ! ximagesink E: gst-launch-1.0 videotestsrc ! "video/x-raw, format=NV12, width=1280, height=720" ! vaapipostproc ! "video/x-raw, format=NV12, width=640, height=480" ! videoconvert ! ximagesink And let us know if there is one working. Thx! This is using vaapi nouveau driver from mesa/gallium but the crash happens in gstreamer. At first glance I would say it is a problem in vaapi nouveau because it is not as well tested as vaapi intel driver. But since it crashes in gstreamer it could still be a pb in gst.
(In reply to Julien Isorce from comment #1) > This is using vaapi nouveau driver from mesa/gallium but the crash happens > in gstreamer. At first glance I would say it is a problem in vaapi nouveau > because it is not as well tested as vaapi intel driver. But since it crashes > in gstreamer it could still be a pb in gst. Gurkirpal also filed a bug for mesa st/va: https://bugs.freedesktop.org/show_bug.cgi?id=100075 Which also is a crash in gstreamer (while using orc).
(In reply to Julien Isorce from comment #1) > Worth to mention that Gurkirpal told me that it does not crash when using > vaapih264dec. So the difference here is vaapipostproc. > > Gurkirpal, please try: > > A: > gst-launch-1.0 videotestsrc ! "video/x-raw, format=NV12, width=1280, > height=720" ! vaapipostproc ! "video/x-raw, format=BGRx, width=1280, > height=720" ! ximagesink > > B: > gst-launch-1.0 videotestsrc ! "video/x-raw, format=NV12, width=1280, > height=720" ! vaapipostproc ! "video/x-raw, format=BGRA, width=1280, > height=720" ! videoconvert ! ximagesink > > C: > gst-launch-1.0 videotestsrc ! "video/x-raw, format=NV12, width=1280, > height=720" ! vaapipostproc ! "video/x-raw, format=RGBA, width=1280, > height=720" ! videoconvert ! ximagesink > > D: > gst-launch-1.0 videotestsrc ! "video/x-raw, format=NV12, width=1280, > height=720" ! vaapipostproc ! "video/x-raw, format=RGBx, width=1280, > height=720" ! videoconvert ! ximagesink > > E: > gst-launch-1.0 videotestsrc ! "video/x-raw, format=NV12, width=1280, > height=720" ! vaapipostproc ! "video/x-raw, format=NV12, width=640, > height=480" ! videoconvert ! ximagesink > > And let us know if there is one working. Thx! > > This is using vaapi nouveau driver from mesa/gallium but the crash happens > in gstreamer. At first glance I would say it is a problem in vaapi nouveau > because it is not as well tested as vaapi intel driver. But since it crashes > in gstreamer it could still be a pb in gst. Out of the given pipelines only "E" seems to be working even though I see some errors: Pipeline is PREROLLING ... Got context from element 'vaapipostproc0': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayX11\)\ gldisplayx11-0"; Got context from element 'vaapipostproc0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayGLX\)\ vaapidisplayglx1"; 0:00:00.464439479 4880 0xf4ed90 ERROR vaapivideomemory gstvaapivideomemory.c:736:gst_video_info_update_from_surface: Cannot create a VA derived image from surface 0xf4f140 0:00:00.465799491 4880 0xf4ed90 ERROR vaapivideomemory gstvaapivideomemory.c:736:gst_video_info_update_from_surface: Cannot create a VA derived image from surface 0x7fe534003230 Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock
Same results with mesa/va/radeon, but it all works if I replace ximagesink by vaapisink (mem VASurface) or glimagesink (meta GL upload). So there is a problem with VASurface to system memory conversion. And I found with git bisect that A, B, C and D were all working before commit https://cgit.freedesktop.org/gstreamer/gstreamer-vaapi/commit/?id=02f16e82e948231a665824c30c065128ac9a1b19 So this commit (and also https://cgit.freedesktop.org/gstreamer/gstreamer-vaapi/commit/?id=202110bded181192c1b571d51968d2b15cbe7478) causes a regression. Victor any idea ? Thx!
(In reply to Julien Isorce from comment #4) > Same results with mesa/va/radeon, but it all works if I replace ximagesink > by vaapisink (mem VASurface) or glimagesink (meta GL upload). So there is a > problem with VASurface to system memory conversion. > > And I found with git bisect that A, B, C and D were all working before > commit > https://cgit.freedesktop.org/gstreamer/gstreamer-vaapi/commit/ > ?id=02f16e82e948231a665824c30c065128ac9a1b19 > So this commit (and also > https://cgit.freedesktop.org/gstreamer/gstreamer-vaapi/commit/ > ?id=202110bded181192c1b571d51968d2b15cbe7478) causes a regression. > > Victor any idea ? Thx! Both commits intent to use vaDerivedImage to export images from surfaces, instead of using vaImages. In the case of intel driver, the upload of images to surface using derived images is faster (commit 02f16e82). Meanwhile, the download of images using derived images is faster only in some intel platforms (commit 202110bd), that is the reason of bug #775848. Perhaps we could argue that the implementation of vaDeriveImage in those gallium backends are not complete. I don't know.
VaDeriveImage is implemented in gallium/va, but only for RGB likes at the moment, so not for NV12. But gstreamer-vaapi currently properly fallback if that direct upload fails. About the download direct, the drive image succeeds because the pipeline above convert to RGB. But it sounds like the mapped buffer is not accessible: "error: Cannot access memory at address 0x7ffff7ff9000" and the it crashes. For a moment I thought this was because of the WRITE only flag here https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/va/buffer.c#n128 but I get same result with PIPE_TRANSFER_READ_WRITE .
Hi, I have the same problem with mesa radeonsi. This one is working: gst-launch-1.0 videotestsrc is-live=true ! video/x-raw,format=NV12 ! vaapipostproc ! video/x-raw,format=BGRx ! fakesink This one is not: gst-launch-1.0 videotestsrc is-live=true ! video/x-raw,format=BGRx ! vaapipostproc ! video/x-raw,format=NV12 ! fakesink Causing a segfault or following error: 0x705efd0 ERROR vaapipostproc gstvaapipostproc.c:810:gst_vaapipostproc_process_vpp:<vaapipostproc0> failed to apply VPP filters (error 2) It is indeed caused by direct upload. When I disable direct upload flag it is working correctly, here: https://cgit.freedesktop.org/gstreamer/gstreamer-vaapi/tree/gst/vaapi/gstvaapipluginbase.c#n519 At least gstreamer-vaapi is not properly fallback as Julien mentioned. Maybe adding env variable to be able to disable it until it is implemented in mesa? Thanks backtrace:
+ Trace 237749
Since I was CCed here, I'll post the results in my system: AMD Radeon (TM) RX 460 Graphics (AMD POLARIS11 / DRM 3.19.0 / 4.14.16-300.fc27.x86_64, LLVM 5.0.0) [amdgpu] GStreamer 1.12.4 Fedora 27 Neither of the testcases provided here caused a crash (including Serenity Trailer). All of them worked fine except this one, which showed an error, same as the post above but without the crash: $ GST_DEBUG=WARN gst-launch-1.0 videotestsrc is-live=true ! video/x-raw,format=BGRx ! vaapipostproc ! video/x-raw,format=NV12 ! fakesink 0:00:00.360818739 14263 0x559f567b14f0 ERROR vaapipostproc gstvaapipostproc.c:810:gst_vaapipostproc_process_vpp:<vaapipostproc0> failed to apply VPP filters (error 2) 0:00:00.360857735 14263 0x559f567b14f0 WARN basesrc gstbasesrc.c:2939:gst_base_src_loop:<videotestsrc0> error: Internal data stream error. 0:00:00.360865825 14263 0x559f567b14f0 WARN basesrc gstbasesrc.c:2939:gst_base_src_loop:<videotestsrc0> error: streaming stopped, reason error (-5)
(In reply to Alicia Boya García from comment #8) > AMD Radeon (TM) RX 460 Graphics (AMD POLARIS11 / DRM 3.19.0 / > All of them worked fine except this one, which showed an error, same as the > post above but without the crash: Thx for the report. So it looks like it happens only with NVIDIA cards (va/gallium/nouveau). The fact that it properly fails without crash with NV!2 is the expected behavior (see comment #6). So the crash is either specific to va/gallium/nouveau or it has been fixed in latest mesa.
(In reply to Tomas Rataj from comment #7) Hi Tomas, thx for your previous report can you still reproduce the "crash" with latest gstreamer-vaapi and more recent mesa ? If yes please provide dmesg | grep drm just after a fresh boot and mesa+gst versions. Thx!
changing to need info according Julien request to Tomas
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/issues/50.