[Bug 779642] New: Bus error occurs when trying to run mp4 file with vaapidecodebin

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=779642

Bug ID: 779642
Summary: Bus error occurs when trying to run mp4 file with
vaapidecodebin
Classification: Platform
Product: GStreamer
Version: 1.11.2
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gstreamer-vaapi
Assignee: gstreamer-***@lists.freedesktop.org
Reporter: ***@gmail.com
QA Contact: gstreamer-***@lists.freedesktop.org
CC: ***@gmail.com, ***@igalia.com
GNOME version: ---

Created attachment 347296
--> https://bugzilla.gnome.org/attachment.cgi?id=347296&action=edit
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

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=779642

***@gmail.com changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=779642

Julien Isorce <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #1 from Julien Isorce <***@gmail.com> ---
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.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=779642

--- Comment #2 from Víctor Manuel Jáquez Leal <***@igalia.com> ---
(In reply to Julien Isorce from comment #1)

Post by "GStreamer" (GNOME Bugzilla)
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).

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=779642

--- Comment #3 from ***@gmail.com ---
(In reply to Julien Isorce from comment #1)

Post by "GStreamer" (GNOME Bugzilla)
Worth to mention that Gurkirpal told me that it does not crash when using
vaapih264dec. So the difference here is vaapipostproc.
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
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
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
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
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

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=779642

Hyunjun Ko <***@igalia.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@igalia.com

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=779642

--- Comment #4 from Julien Isorce <***@gmail.com> ---
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!

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=779642

--- Comment #5 from Víctor Manuel Jáquez Leal <***@igalia.com> ---
(In reply to Julien Isorce from comment #4)

Post by "GStreamer" (GNOME Bugzilla)
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.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=779642

Víctor Manuel Jáquez Leal <***@igalia.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Summary|Bus error occurs when |vaapi: direct
|trying to run mp4 file with |download/upload crashes in
|vaapidecodebin |gallium backends

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=779642

--- Comment #6 from Julien Isorce <***@gmail.com> ---
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 .

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=779642

Julien Isorce <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@vodafone.de

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=779642

Julien Isorce <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=779642

Holger Kaelberer <***@getslash.de> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@getslash.de

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=779642

Víctor Manuel Jáquez Leal <***@igalia.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugzilla.gnome.org/
| |show_bug.cgi?id=775848

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=779642

Víctor Manuel Jáquez Leal <***@igalia.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Whiteboard| |P3

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=779642

Tomas Rataj <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #7 from Tomas Rataj <***@gmail.com> ---
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:
#0 0x00007fffe837d199 in ()
#1 0x00007ffff5dac38b in video_orc_pack_BGRA (d1=0x7ffff7fede00 <error: Cannot
access memory at address 0x7ffff7fede00>, s1=0x7fffdc041800 '\377' <repeats 183
times>, n=320) at tmp-orc.c:4653
#2 0x00007ffff5fea696 in convert_hline_generic (p=<optimized out>,
frame=0x7fffd2ffc950, y=<optimized out>) at videotestsrc.c:1289
#3 0x00007ffff5fea348 in videotestsrc_convert_tmpline
(p=***@entry=0x7fffd2ffc840, frame=***@entry=0x7fffd2ffc950, j=***@entry=22)
at videotestsrc.c:273
#4 0x00007ffff5feac5e in gst_video_test_src_smpte (v=0x55555592d2a0
[GstVideoTestSrc], pts=<optimized out>, frame=0x7fffd2ffc950)
at videotestsrc.c:351
#5 0x00007ffff5fe7951 in gst_video_test_src_fill (psrc=0x55555592d2a0
[GstVideoTestSrc], buffer=0x555555a97740)
at gstvideotestsrc.c:1152
#6 0x00007ffff5b1acff in gst_base_src_default_create (src=0x55555592d2a0
[GstVideoTestSrc], offset=18446744073709551615, size=4096,
buffer=0x7fffd2ffcd20) at gstbasesrc.c:1474
#7 0x00007ffff5b1df6f in gst_base_src_get_range (src=***@entry=0x55555592d2a0
[GstVideoTestSrc], offset=***@entry=18446744073709551615, length=<optimized
out>, buf=***@entry=0x7fffd2ffcdf8) at gstbasesrc.c:2453
#8 0x00007ffff5b1f8af in gst_base_src_loop (pad=0x55555592e030 [GstPad]) at
gstbasesrc.c:2729
#9 0x00007ffff7b49aa1 in gst_task_func (task=0x55555593f290 [GstTask]) at
gsttask.c:335
#10 0x00007ffff73abeee in g_thread_pool_thread_proxy (data=<optimized out>) at
././glib/gthreadpool.c:307
#11 0x00007ffff73ab4f5 in g_thread_proxy (data=0x555555942e30) at
././glib/gthread.c:784
#12 0x00007ffff6d17494 in start_thread (arg=0x7fffd2ffd700) at
pthread_create.c:333
#13 0x00007ffff6a59a8f in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=779642

Julien Isorce <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@igalia.com,
| |***@igalia.com

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=779642

--- Comment #8 from Alicia Boya García <***@igalia.com> ---
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)

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=779642

--- Comment #9 from Julien Isorce <***@gmail.com> ---
(In reply to Alicia Boya García from comment #8)

Post by "GStreamer" (GNOME Bugzilla)
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

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.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=779642

--- Comment #10 from Julien Isorce <***@gmail.com> ---
(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!

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=779642

Víctor Manuel Jáquez Leal <***@igalia.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO

--- Comment #11 from Víctor Manuel Jáquez Leal <***@igalia.com> ---
changing to need info according Julien request to Tomas

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=779642

GStreamer system administrator <***@gstreamer.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |RESOLVED
Resolution|--- |OBSOLETE

--- Comment #12 from GStreamer system administrator <***@gstreamer.net> ---
-- 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.