GNOME Bugzilla – Bug 756028
avviddec: On OpenBSD H.264 playback crashes with an assertion error
Last modified: 2015-11-09 13:57:05 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
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.
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.
It's just my spidey senses :) Could you make a GST_DEBUG=*:6 log for this one as well please?
Created attachment 312647 [details] debug log file
Nicolas, any ideas how it could run into this... and only on OpenBSD?
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.
The xvimage allocator problem is bug #756029
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.
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.
Ok, assignment to myself, I have this time week, if in urge and doing it now, let me know.
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.
Attachment 315061 [details] pushed as 2a7aaeb - avviddec: Don't fallback on allocation failure
This should also go into 1.6.2, Nicolas can you backport?