After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 793890 - Segfault when playing raw RGB video MP4 file with vaapi with AMD card
Segfault when playing raw RGB video MP4 file with vaapi with AMD card
Status: RESOLVED DUPLICATE of bug 793889
Product: GStreamer
Classification: Platform
Component: gstreamer-vaapi
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-02-27 17:35 UTC by Alicia Boya García
Modified: 2018-02-28 10:29 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Test vector (1.32 MB, video/mp4)
2018-02-27 17:36 UTC, Alicia Boya García 		Details
Backtrace (20.71 KB, text/plain)
2018-02-27 17:38 UTC, Alicia Boya García 		Details
GST_DEBUG=WARN,*vaapi*:TRACE gst-play-1.0 /tmp/counter.mp4 (33.52 KB, text/plain)
2018-02-27 17:41 UTC, Alicia Boya García 		Details

Description Alicia Boya García 2018-02-27 17:35:36 UTC 
The attached file crashes when played with gst-play-1.0 with my AMD card.

OpenGL renderer string: AMD Radeon (TM) RX 460 Graphics (AMD POLARIS11 / DRM 3.19.0 / 4.14.16-300.fc27.x86_64, LLVM 5.0.0)
Fedora 27
Comment 1 Alicia Boya García 2018-02-27 17:36:04 UTC 
Created attachment 369050 [details]
Test vector
Comment 2 Alicia Boya García 2018-02-27 17:38:39 UTC 
Created attachment 369051 [details]
Backtrace
Comment 3 Alicia Boya García 2018-02-27 17:41:00 UTC 
Created attachment 369052 [details]
GST_DEBUG=WARN,*vaapi*:TRACE gst-play-1.0 /tmp/counter.mp4
Comment 4 Philippe Normand 2018-02-27 19:06:05 UTC 
vaapisink shouldn't be used. What happens if you use gst-play-1.0 --videosink glimagesink ?
Comment 5 Philippe Normand 2018-02-28 09:19:14 UTC 
Here with vaapisink:

0:00:00.212759760 23102 0x7f8bc804e8a0 ERROR                  vaapi gstvaapiwindow.c:219:gst_vaapi_window_vpp_convert_internal: failed to process surface 0x1 (error 2)
ERROR Internal error: could not render surface for file:///home/phil/Downloads/counter.mp4
ERROR debug information: ../subprojects/gstreamer-vaapi/gst/vaapi/gstvaapisink.c(1475): gst_vaapisink_show_frame_unlocked (): /GstPlayBin:playbin/GstPlaySink:playsink/GstBin:vbin/GstVaapiSink:vaapisink0

No crash.
Playback works with glimagesink and xvimagesink though.
Comment 6 Alicia Boya García 2018-02-28 10:29:00 UTC 
(In reply to Philippe Normand from comment #4)
> vaapisink shouldn't be used. What happens if you use gst-play-1.0
> --videosink glimagesink ?

In that case it works, but why shouldn't it be used, and why is it being picked as the default then?


I just noticed that this file is not actually h264, but raw RGB video in MP4.

0:00:00.037652707  9694 0x564fc5cd0770 INFO                 qtdemux qtdemux.c:10738:qtdemux_parse_trak:<qtdemux0> type raw  caps video/x-raw, format=(string)RGB, width=(int)320, height=(int)240, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, colorimetry=(string)sRGB, framerate=(fraction)0/1

Therefore it may be related to https://bugzilla.gnome.org/show_bug.cgi?id=793889.
Indeed the traceback looks very similar, and the input for vaapisink looks the same except in this case it's RGB instead of BGRx.

Given the similarities, I'll mark this bug as duplicate and add the file as an additional test vector for the other one.

*** This bug has been marked as a duplicate of bug 793889 ***