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 756028 - avviddec: On OpenBSD H.264 playback crashes with an assertion error
avviddec: On OpenBSD H.264 playback crashes with an assertion error
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-libav
1.6.0
Other OpenBSD
: Normal normal
: 1.6.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-10-04 04:01 UTC by Brad Smith
Modified: 2015-11-09 13:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
debug log file (658.09 KB, application/x-xz)
2015-10-04 18:31 UTC, Brad Smith
  Details
avviddec: Don't fallback on allocation failure (3.62 KB, patch)
2015-11-07 17:13 UTC, Nicolas Dufresne (ndufresne)
committed Details | Review

Description Brad Smith 2015-10-04 04:01:07 UTC
Since upgrading from GStreamer 1.4 to 1.6 I am now no longer able to playback a lot of the H.264 content I have with what looks like gst-plugins-libav crashing with an assertion error.

$ gst-play-1.0 Alien\ Resurrection-1080p.mkv  
Press 'k' to see a list of keyboard shortcuts.
Now playing /Multimedia/Movies/Alien Resurrection-1080p.mkv
Redistribute latency...
**00:00.0 / 1:56:08.7       
ERROR:gstavviddec.c:834:gst_ffmpegviddec_get_buffer2: assertion failed: (picture->linesize[c] == ffmpegdec->stride[c])
Abort trap
Comment 1 Tim-Philipp Müller 2015-10-04 08:58:41 UTC
It's likely that this problem is related to the other bug you filed, isn't it?

Does openbsd use the internal snapshot of libav/ffmpeg that we ship in gst-libav, or does it link against a system libav/ffmpeg?

Note that we switched from libav to ffmpeg in 1.6, so if it's linking against system libav (instead of ffmpeg) it might not work.
Comment 2 Brad Smith 2015-10-04 16:53:07 UTC
I don't know why you would say that. It's a different file and from the error message to me it looks like a different issue. This looks like a bug with the gst-libav wrapper plugin. The other ticket to me looks like an issue with the Matroska demuxer.

OpenBSD's port / package for gst-libav uses the internal copy of FFmpeg.
Comment 3 Tim-Philipp Müller 2015-10-04 17:19:19 UTC
It's just my spidey senses :)

Could you make a GST_DEBUG=*:6 log for this one as well please?
Comment 4 Brad Smith 2015-10-04 18:31:15 UTC
Created attachment 312647 [details]
debug log file
Comment 5 Sebastian Dröge (slomo) 2015-10-13 09:31:41 UTC
Nicolas, any ideas how it could run into this... and only on OpenBSD?
Comment 6 Nicolas Dufresne (ndufresne) 2015-10-13 21:37:16 UTC
From the trace, I just noticed it's going through a less tested code path.

> gstavviddec.c:862:gst_ffmpegviddec_get_buffer2:<avdec_h264-0> alloc failed, fallback alloc

Which is the result of gst_buffer_pool_acquire_buffer() failing. Digging a little more:

> xvimagepool.c:199:xvimage_buffer_pool_alloc:<xvimagebufferpool2> can't create image

Which points to xvimagesink proposing a pool that does not work, and the fallback allocation in libav decoder not working. Very few element have such a fallback, so first issue is major issue for OpenBSD. The second, we can try and simulate the error and fix.
Comment 7 Sebastian Dröge (slomo) 2015-10-13 21:51:57 UTC
The xvimage allocator problem is bug #756029
Comment 8 Nicolas Dufresne (ndufresne) 2015-10-14 09:27:21 UTC
Ok, so what do you prefer, re-implement this fallback so it won't change the strides, or drop it and fail ? As said, this is the only decoder I found capable of surviving a pool that stops working. It's like if the pool had a maximum allocaion limit, but it was not exposed. In that case, we would have to be lucky enough for few buffers to be freed, so the fallback allocated memory can be copied over into shared XV memory.
Comment 9 Sebastian Dröge (slomo) 2015-10-14 10:53:22 UTC
I think it's fair to fail if the pool does not work correctly. We should just not assert and crash but fail gracefully :)

And yes, there seems to be a maximum limit in the xvimage pool on OpenBSD. That should be handled in the other bug :) Here we should just fail properly instead of crashing.
Comment 10 Nicolas Dufresne (ndufresne) 2015-10-14 12:17:02 UTC
Ok, assignment to myself, I have this time week, if in urge and doing it now, let me know.
Comment 11 Nicolas Dufresne (ndufresne) 2015-11-07 17:13:04 UTC
Created attachment 315061 [details] [review]
avviddec: Don't fallback on allocation failure

Allocation should keep working, falling back causes the stride to
change which is not supported in direct rendering.
Comment 12 Nicolas Dufresne (ndufresne) 2015-11-07 22:33:35 UTC
Attachment 315061 [details] pushed as 2a7aaeb - avviddec: Don't fallback on allocation failure
Comment 13 Sebastian Dröge (slomo) 2015-11-08 13:50:03 UTC
This should also go into 1.6.2, Nicolas can you backport?