A few HEVC files gives me a segfault in radeonsi_dri.so when trying to play them via Kodi. They work fine when decoding in software, and other HEVC files work fine being decoded in hardware. I do not know what is special about these files. > amdgpu: Failed to allocate a buffer: > amdgpu: size : 3221295104 bytes > amdgpu: alignment : 4096 bytes > amdgpu: domains : 4 > amdgpu: Failed to allocate a buffer: > amdgpu: size : 3221295104 bytes > amdgpu: alignment : 4096 bytes > amdgpu: domains : 4 > EE ../src/gallium/drivers/radeon/radeon_vcn_dec.c:880 rvcn_dec_message_decode UVD - Can't allocated context buffer. > /usr/bin/kodi: line 219: 1223 Segmentation fault (core dumped) ${KODI_BINARY} $SAVED_ARGS Lines seen in ~/.xsession-errors This is the details Kodi reports about the video: > 2019-05-17 19:51:31.904 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: Metadata: > 2019-05-17 19:51:31.904 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: ENCODER : Lavf58.27.102 > 2019-05-17 19:51:31.904 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: Duration: 01:29:45.38, start: 0.000000, bitrate: 1598 kb/s > 2019-05-17 19:51:31.904 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: Stream #0:0(eng): Video: hevc (Main 10), yuv420p10le(tv), 1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default) > 2019-05-17 19:51:31.904 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: Metadata: > 2019-05-17 19:51:31.904 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: BPS-eng : 8246896 > 2019-05-17 19:51:31.904 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: DURATION-eng : 01:29:45.380000000 > 2019-05-17 19:51:31.904 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: NUMBER_OF_FRAMES-eng: 129120 > 2019-05-17 19:51:31.904 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: NUMBER_OF_BYTES-eng: 5551584033 > 2019-05-17 19:51:31.904 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: _STATISTICS_WRITING_APP-eng: mkvmerge v33.1.0 ('Primrose') 64-bit > 2019-05-17 19:51:31.904 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: _STATISTICS_WRITING_DATE_UTC-eng: 2019-05-13 00:59:51 > 2019-05-17 19:51:31.904 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES > 2019-05-17 19:51:31.904 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: ENCODER : Lavc58.51.100 libx265 > 2019-05-17 19:51:31.904 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: DURATION : 01:29:45.380000000 > 2019-05-17 19:51:31.904 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: Stream #0:1(eng): Audio: eac3, 48000 Hz, 6 channels, fltp (default) > 2019-05-17 19:51:31.904 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: Metadata: > 2019-05-17 19:51:31.904 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: BPS-eng : 640000 > 2019-05-17 19:51:31.904 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: DURATION-eng : 01:29:45.376000000 > 2019-05-17 19:51:31.904 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: NUMBER_OF_FRAMES-eng: 168293 > 2019-05-17 19:51:31.904 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: NUMBER_OF_BYTES-eng: 430830080 > 2019-05-17 19:51:31.904 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: _STATISTICS_WRITING_APP-eng: mkvmerge v33.1.0 ('Primrose') 64-bit > 2019-05-17 19:51:31.904 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: _STATISTICS_WRITING_DATE_UTC-eng: 2019-05-13 00:59:51 > 2019-05-17 19:51:31.904 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES > 2019-05-17 19:51:31.904 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: DURATION : 01:29:45.384000000 > 2019-05-17 19:51:31.904 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: Stream #0:2(eng): Subtitle: ass > 2019-05-17 19:51:31.904 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: Metadata: > 2019-05-17 19:51:31.904 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: BPS-eng : 38 > 2019-05-17 19:51:31.904 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: DURATION-eng : 01:29:38.000000000 > 2019-05-17 19:51:31.904 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: NUMBER_OF_FRAMES-eng: 955 > 2019-05-17 19:51:31.905 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: NUMBER_OF_BYTES-eng: 26165 > 2019-05-17 19:51:31.905 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: _STATISTICS_WRITING_APP-eng: mkvmerge v33.1.0 ('Primrose') 64-bit > 2019-05-17 19:51:31.905 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: _STATISTICS_WRITING_DATE_UTC-eng: 2019-05-13 00:59:51 > 2019-05-17 19:51:31.905 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES > 2019-05-17 19:51:31.905 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: ENCODER : Lavc58.51.100 ssa > 2019-05-17 19:51:31.905 T:140684663195392 INFO: ffmpeg[7FF3B3600700]: DURATION : 01:29:42.162000000 This is with mesa-dri-drivers-19.0.4-1.fc30.x86_64.
Created attachment 144290 [details] gdb bt full A backtrace of the crash from gdb. It looks like the allocation filed, but then either kodi or the driver went ahead and tried to clear the buffer anyway.
I think I've spotted a difference. The crashing files are all yuv420p10le, whilst everything else is in yuv420. Hope this helps.
I found a lower resolution yuv420p10le video, and it crashes the same way. So it seems the pixel format is the key issue here, not the resolution.
As a workaround, is it possible to configure VA-API to refuse to handle this specific format? It would be nice to have to disable hardware acceleration entirely.
Hi, I believe I am experiencing the same issue, what can I do to help fix it?
I can't reproduce it here, but maybe my test file (from https://github.com/mpv-player/mpv/issues/4736#issuecomment-333505294) isn't good to trigger the bug. Does the issue occur with the file above? And could you test with a different player?
The sample provided in the post above is not triggering the crash. However a sample was provided to me that reliably crashes. https://drive.google.com/open?id=1bDhF6U5ccW-K1G63fl1qnO-98kopMJyw ryzen 2400g linux 5.1.10 mesa 19.1.0 ffmpeg 4.0.3 libva 2.5.0.pre1 (from git) kodi 19 (from git) I have a stacktrace but it's quite useless, if needed I could rebuild all the packages with debug info and reproduce. I don't have another player on the affected system atm.
I believe this file is also triggering the crash condition. http://www.users.on.net/~ostickley/snip.mkv
Thanks, I could reproduce on a Raven setup using the files from comment 7 and 8. The driver fails when trying to allocate a buffer for this video with a ENOMEM error (the requested size is 3 GB).
(In reply to Pierre-Eric Pelloux-Prayer from comment #9) > The driver fails when trying to allocate a buffer for this video with a > ENOMEM error (the requested size is 3 GB). Well that strongly sounds like we miscalculated the necessary size somewhere.
(In reply to Christian König from comment #10) > (In reply to Pierre-Eric Pelloux-Prayer from comment #9) > > The driver fails when trying to allocate a buffer for this video with a > > ENOMEM error (the requested size is 3 GB). > > Well that strongly sounds like we miscalculated the necessary size somewhere. Indeed. The size is computed by the `calc_ctx_size_h265_main10()` function. I'm not familiar enough with hevc to fix it though (but the calculation seems to overflow because context_buffer_size_per_ctb_row is 1GB and is multiplied by max_references (= 23) and the result is stored in an unsigned int).
Can you try the branch from https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1154 and report if it fixes the issue for you?
Applied the PR mentioned in 12 as a patch on top of the 19.1.0 tarball release. All the crashy samples I have now play perfectly. All the good media I have continues playing perfectly. Huge thanks for the quick fix.
Is there any reason the fix isn't merged yet?
The fix has been merged today (https://gitlab.freedesktop.org/mesa/mesa/commit/c81c784a4a05f8a957a649d73c8194247de47b56).
And the fix is also included in Mesa 19.1.2 release.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.