GNOME Bugzilla – Bug 732368
gstreamer vaapi crashes in some pipeline configurations
Last modified: 2017-03-07 16:39:58 UTC
Created attachment 279449 [details] GDB Trace when totem crashes A lot of people are reporting crashes with gstreamer-vaapi. It's cropping up in firefox with HTML 5 videos, totem and can be triggered just using gst-launch-1.0 directly. See: https://bbs.archlinux.org/viewtopic.php?pid=1428300 https://bugzilla.mozilla.org/show_bug.cgi?id=1024125 https://bugs.archlinux.org/task/40989 I'm also hitting this issue on Arch with Nvidia card and proprietary drivers. I decided to see if it was still an issue with latest git versions of gstreamer-vaapi, gstreamer and libva. The issue is still there. I attach a trace from gdb and command line output from totem when it tries to display subtitles with gstreamer-vaapi enabled. My versions of those packages are listed as: local/gst-plugins-base-git 1.3.3.1.13440.693f3f9-1 GStreamer Multimedia Framework Base Plugins local/gst-vaapi-git 1685.9169c52-1 GStreamer Multimedia Framework VA Plugins local/gstreamer-git 1.3.3.1.15624.0e0e78e-1 GStreamer Multimedia Framework (Git version) local/libva-git libva.1.3.1.4.gc61d8c6-1 Video Acceleration (VA) API for Linux. Git version. I could not find a PKGBUILD for libva-vdpau-dirver which is version (I had problems building it manually due to: hitting this issue: https://bugs.archlinux.org/task/33482) libva-vdpau-driver 0.7.4-1 Command line output running totem when the crash happens: pebble% totem (totem:31191): Grilo-WARNING **: [registry] grl-registry.c:944: Failed to open module: libgssdp-1.0.so.3: cannot open shared object file: No such file or directory (totem:31191): Grilo-WARNING **: [registry] grl-registry.c:944: Failed to open module: libdmapsharing-3.0.so.2: cannot open shared object file: No such file or directory libva info: VA-API version 0.35.2 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/dri/nvidia_drv_video.so libva info: Found init function __vaDriverInit_0_33 libva info: va_openDriver() returns 0 0:00:15.934774626 31191 0x7f31f0002ca0 ERROR vaapivideomemory gstvaapivideomemory.c:167:gst_video_meta_map_vaapi_memory: unsupported map flags (0x3) 0:00:15.934850482 31191 0x7f31f0002ca0 ERROR default video-frame.c:138:gst_video_frame_map_id: failed to map video frame plane 0 0:00:15.934934750 31191 0x7f31f0002ca0 ERROR vaapivideomemory gstvaapivideomemory.c:167:gst_video_meta_map_vaapi_memory: unsupported map flags (0x3) 0:00:15.934978358 31191 0x7f31f0002ca0 ERROR default video-frame.c:138:gst_video_frame_map_id: failed to map video frame plane 0 ** (totem:31191): CRITICAL **: gst_vaapi_image_get_plane: assertion '_gst_vaapi_image_is_mapped(image)' failed ** (totem:31191): CRITICAL **: gst_vaapi_image_get_pitch: assertion '_gst_vaapi_image_is_mapped(image)' failed ** (totem:31191): CRITICAL **: gst_vaapi_image_get_plane: assertion '_gst_vaapi_image_is_mapped(image)' failed ** (totem:31191): CRITICAL **: gst_vaapi_image_get_pitch: assertion '_gst_vaapi_image_is_mapped(image)' failed zsh: segmentation fault totem
How can it be reproduced with gst-launch, which pipeline are you using? And is this only on specific files? If so, can you provide one?
Sounds like an issue in gstreamer-vaapi
Hi Sebastian, I haven't played with gst-launch myself but an example from the user progandy at: https://bbs.archlinux.org/viewtopic.php?pid=1430801#p1430801 is: curl -O http://samples.mplayerhq.hu.nyud.net/V-codecs/h264/PAFF/Grey.ts gst-launch-1.0 filesrc location="./Grey.ts" ! decodebin name=demux demux. ! autovideosink demux. ! autoaudiosink I just confirmed this causes a similar looking crash to what I originally reported for me also but only with the current arch gstreamer and gst-vaapi packages. When I use the packages from git this example *works* (but my original totem example does not).
(In reply to comment #3) > Hi Sebastian, > > I haven't played with gst-launch myself but an example from the user progandy > at: https://bbs.archlinux.org/viewtopic.php?pid=1430801#p1430801 > > is: > > curl -O http://samples.mplayerhq.hu.nyud.net/V-codecs/h264/PAFF/Grey.ts > gst-launch-1.0 filesrc location="./Grey.ts" ! decodebin name=demux demux. ! > autovideosink demux. ! autoaudiosink > > I just confirmed this causes a similar looking crash to what I originally > reported for me also but only with the current arch gstreamer and gst-vaapi > packages. > > When I use the packages from git this example *works* (but my original totem > example does not). As an update, Arch linux updated their gstreamer packages. My versions are now: gst-vaapi: 0.5.9-1 gstreamer: 1.4.0-1 libva: 1.3.1-2 gst-plugins-ugly: 1.4.0-2 totem: 3.12.1-2 With these packages issues that people had playing HTML5 videos in Firefox with gst-vaapi installed seem to have gone away (at least they have for me), but, Totem doesn't seem to play any files I throw at it. It just shows a white screen, sometimes with a message that says: Gstreamer encountered a general stream error. Running totem --debug does not seem to output any additional information. If I uninstall gst-vaapi then totem works as expected (albeit without GPU hardware acceleration of course). Perhaps this is now more of a Totem issue than a Gstreamer one? I'd be happy to provide any additional info if you can tell me what you need.
i can reproduce this with gst-launch using gst-launch-1.0 udpsrc port=5000 ! application/x-rtp, payload=96 ! rtpjitterbuffer ! rtph264depay ! avdec_h264 ! fpsdisplaysink sync=false text-overlay=false waldo@WaldoD:/etc$ gst-launch-1.0 udpsrc port=5000 ! application/x-rtp, payload=96 ! rtpjitterbuffer ! rtph264depay ! avdec_h264 ! fpsdisplaysink sync=false text-overlay=false Setting pipeline to PAUSED ... libva info: VA-API version 0.35.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/fglrx_drv_video.so libva info: Found init function __vaDriverInit_0_32 libva info: va_openDriver() returns 0 Pipeline is live and does not need PREROLL ... Setting pipeline to PLAYING ... New clock: GstSystemClock ** (gst-launch-1.0:14093): CRITICAL **: gst_vaapi_image_get_plane: assertion '_gst_vaapi_image_is_mapped(image)' failed ** (gst-launch-1.0:14093): CRITICAL **: gst_vaapi_image_get_pitch: assertion '_gst_vaapi_image_is_mapped(image)' failed ** (gst-launch-1.0:14093): CRITICAL **: gst_vaapi_image_get_plane: assertion '_gst_vaapi_image_is_mapped(image)' failed ** (gst-launch-1.0:14093): CRITICAL **: gst_vaapi_image_get_pitch: assertion '_gst_vaapi_image_is_mapped(image)' failed ** (gst-launch-1.0:14093): CRITICAL **: gst_vaapi_image_get_plane: assertion '_gst_vaapi_image_is_mapped(image)' failed ** (gst-launch-1.0:14093): CRITICAL **: gst_vaapi_image_get_pitch: assertion '_gst_vaapi_image_is_mapped(image)' failed ** (gst-launch-1.0:14093): CRITICAL **: gst_video_meta_unmap_vaapi_memory: assertion 'mem->surface' failed ** (gst-launch-1.0:14093): CRITICAL **: gst_video_meta_unmap_vaapi_memory: assertion 'mem->surface' failed ** (gst-launch-1.0:14093): CRITICAL **: gst_video_meta_unmap_vaapi_memory: assertion 'mem->surface' failed Got EOS from element "pipeline0". Execution ended after 0:00:32.378609739 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... video input comming from raspbery camera using raspivid -t 999999 -b 2000000 -o - | gst-launch-1.0 -e -vvv fdsrc ! h264parse ! rtph264pay pt=96 config-interval=5 ! udpsink host=192.168.69.253 port=5000 does this on ubuntu trusty : Source: gstreamer-vaapi Version: 0.5.7-0ubuntu4
forgot to mention that removing the gstreamer1.0-vaaapi package from the system makes the above pipeline work perfect
I think it's an issue in gstreamer-vaapi. The vaapi allocated buffers can't be mapped for writing or something (IIRC, I have run into this before as well). Maybe you can work around it by doing fpsdisplaysink video-sink=xvimagesink or ximagesink or glimagesink or so.
Moving to Product:GStreamer, Component:gstreamer-vaapi
using gstreamer-vaapi 1.8.1 in Totem 3.20.1 with Intel Broadwell card on Arch Linux. gstreamer-vaapi playback works only in Xorg environment with DRI2. Enabling DRI3 break gstreamer-vaapi playback under X. Logging in Wayland session break gstreamer-vaapi playback both with DRI2 and DRI3. Enabling modesetting DDX driver breaks gstreamer-vaapi playback in any scenario. gstreamer 1.8.1 xf86-video-intel 1:2.99.917+636+g562ae1f-1 mesa 11.2.1 xorg-server 1.18.3 gnome 3.20.1
(In reply to rockonthemoonfm from comment #9) > gstreamer-vaapi playback works only in Xorg environment with DRI2. > > Enabling DRI3 break gstreamer-vaapi playback under X. Yes, this issue is known: https://bugs.freedesktop.org/show_bug.cgi?id=71759 > Logging in Wayland session break gstreamer-vaapi playback both with DRI2 and > DRI3. > Enabling modesetting DDX driver breaks gstreamer-vaapi playback in any > scenario. Perhaps we would need a different bug report to track each of these issues.
actually I am able to play only *.avi videos in non X/DRI2 scenario
Since, originally, this bug only affected the deprecated libva-vdpau-driver, which now is rejected since bug 764673, this is bug is obsolete now. Thus, closing.