Description of problem: clapper crashes with SIGSEGV when trying to play videos encoded with H.265/HEVC codec with 10-bit color. Version-Release number of selected component (if applicable): clapper-0.5.2-1.fc37.x86_64 gjs-1.76.2-2.fc38.x86_64 gstreamer1-1.22.8-1.fc38.x86_64 gstreamer1-plugins-base-1.22.8-1.fc38.x86_64 libglvnd-gles-1.6.0-2.fc38.x86_64 How reproducible: Always Steps to Reproduce: 1. Download any HEVC 10-bit-encoded video, e.g. https://drive.google.com/file/d/0BwxFVkl63-lEdVBuZkltckdZZ0k/view?usp=sharing&resourcekey=0-k91iv2m3Plumc5jdKCbxdQ linked from https://kodi.wiki/view/Samples 2. clapper 4K\ HEVC\ 59.940\ Broadcast\ Capture\ Sample.mkv Actual results: crocus: driver missing Segmentation fault (core dumped) Expected results: crocus: driver missing ... and working playback. Additional info: HEVC videos with 8-bit color play fine, so the issue seems to be specifically with 10-bit color videos. Video playback of the above works in totem. mpv plays them correctly, too. I have two GPUs: Intel IvyBridge HD4000 iGPU and AMD Radeon RX 6700 dGPU. The iGPU one has no displays connected and is enabled but unused, which is causing the "crocus: driver missing" message, probably. The crash seems to be happening in gjs, but ABRT is refusing to report it (due to "low informational value"): https://retrace.fedoraproject.org/faf/reports/731777/
I cannot reproduce this. clapper plays the video as expected with no sound, as Fedora does not support H265 due to the patent situation. But something is extremely weird with your system: You are using a clapper package for Fedora 37, while you seem to be running Fedora 38. Can you please try this on a freshly installed system to make sure the issue is not your system? It should play the audio while the video being just black.
(In reply to Jonathan S. from comment #1) > I cannot reproduce this. clapper plays the video as expected with no sound, > as Fedora does not support H265 due to the patent situation. Sorry, brain fart. I meant it plays the video with only sound.
(In reply to Jonathan S. from comment #1) > I cannot reproduce this. clapper plays the video as expected with no sound, > as Fedora does not support H265 due to the patent situation. I'm using vah265dec to offload the decoding to my GPU. gstreamer1-plugins-bad-free comes from Fedora repos. You need to install mesa-va-drivers-freeworld from a third-party repo to enable support. However, removing gstreamer1-plugins-bad-free causes avdec_h265 to be selected instead and playback works. I guess we can reassign this to gstreamer1-plugins-bad-free, then. > But something is extremely weird with your system: You are using a clapper > package for Fedora 37, while you seem to be running Fedora 38. There were no clapper builds in F38 time frame, so the F37 got included in the repos: https://koji.fedoraproject.org/koji/packageinfo?packageID=34751 > Can you > please try this on a freshly installed system to make sure the issue is not > your system? It should play the audio while the video being just black. I'm not interested in the scenario with missing H.265 codec, so I can see no point in doing this. The crash is 100% reproducible and other players can decode this video using VA-API. Obviously, there's a bug either in clapper or one of its dependencies (gstreamer1-plugins-bad-free, it appears).
I was under the impression that offloading support was also removed a while ago due to patent issues: https://www.phoronix.com/news/Fedora-Disable-Bad-VA-API AFAIK there remain 0 ways to decode H265 in Fedora today that do not involve installing RPMFusion.
Your impression is correct, but I explicitly mentioned installing a package from RPM Fusion to enable such support. Anyway, I followed up on my suspicion that this is not a codec issue per se, but a color depth issue and managed to reproduce with an unencumbered VP9 Profile 2 video decoding using vavp9dec gstreamer codec. Take another video from Kodi samples wiki page: VP9 Profile 2 HDR 24fps The Redwoods (in MKV) (thanks @wesk05) https://mega.nz/#!pQEGgRwY!pD9whIlM-U9tJIA-LojxSt582BAZGfdSA5wAQLT06I4 This still crashes clapper and you should be able to reproduce it if your GPU supports hardware VP9 decoding. This could still be a bug in clapper if it's trying to send 10-bit color depth video as if it had only 8-bits. In particular, this upstream commit looks relevant: https://github.com/Rafostar/clapper/commit/8ebf4e3b2fe15ca8422f4f20d630f99a4996e6c1 I'll try building clapper from git HEAD and retrying.
FWIW, it's reproducible with AV1 (another patent-free codec) 10-bit as well. Sample video: yt-dlp -f 694+600 https://www.youtube.com/watch?v=CHSnz0bCaUk
I quickly tried your AV1 video and it works fine for me in Clapper. I'm on Fedora 39, though.
Can you confirm which decoder was used? GST_DEBUG=videodecoder*:4 clapper video-av1.webm For me it says: $ GST_DEBUG=videodecoder*:4 clapper 10-bit/Alaska\ in\ 8K\ 60p\ HDR\ \ \(Dolby\ Vision\).1440p.webm crocus: driver missing 0:00:00.367359251 34797 0x7f4098001430 INFO videodecoder gstvideodecoder.c:1640:gst_video_decoder_sink_event_default:<vaav1dec0> upstream tags: taglist, video-codec=(string)"AOM\ AV1", language-code=(string)und; 0:00:00.367490274 34797 0x7f4098001430 INFO videodecoder gstvideodecoder.c:1640:gst_video_decoder_sink_event_default:<vaav1dec0> upstream tags: taglist, video-codec=(string)"AOM\ AV1", language-code=(string)und; 0:00:00.367517024 34797 0x7f4098001430 INFO videodecoder gstvideodecoder.c:1640:gst_video_decoder_sink_event_default:<vaav1dec0> upstream tags: taglist, video-codec=(string)"AOM\ AV1", language-code=(string)und, extended-comment=(string){ "HANDLER_NAME\=ISO\ Media\ file\ produced\ by\ Google\ Inc.", "VENDOR_ID\=\[0\]\[0\]\[0\]\[0\]", "DURATION\=00:04:27.584000000" }; 0:00:00.495613402 34797 0x7f4098001430 INFO videodecoder gstvideodecoder.c:3731:gst_video_decoder_clip_and_push_buf:<vaav1dec0> First buffer since flush took 0:00:00.128766371 to produce 0:00:00.512225015 34797 0x7f4098001430 INFO videodecoder gstvideodecoder.c:1640:gst_video_decoder_sink_event_default:<vaav1dec0> upstream tags: taglist, video-codec=(string)"AOM\ AV1", language-code=(string)und, extended-comment=(string){ "HANDLER_NAME\=ISO\ Media\ file\ produced\ by\ Google\ Inc.", "VENDOR_ID\=\[0\]\[0\]\[0\]\[0\]", "DURATION\=00:04:27.584000000" }, minimum-bitrate=(uint)878002, maximum-bitrate=(uint)878002, bitrate=(uint)46185399; 0:00:00.514980278 34797 0x7f4098001430 INFO videodecoder gstvideodecoder.c:1640:gst_video_decoder_sink_event_default:<vaav1dec0> upstream tags: taglist, video-codec=(string)"AOM\ AV1", language-code=(string)und, extended-comment=(string){ "HANDLER_NAME\=ISO\ Media\ file\ produced\ by\ Google\ Inc.", "VENDOR_ID\=\[0\]\[0\]\[0\]\[0\]", "DURATION\=00:04:27.584000000" }, minimum-bitrate=(uint)284355, maximum-bitrate=(uint)878002, bitrate=(uint)42012577; Segmentation fault (core dumped)
A bunch of these while the movie is playing: 0:00:08.757256481 21429 0x7fdff40012c0 INFO videodecoder gstvideodecoder.c:1640:gst_video_decoder_sink_event_default:<vaav1dec0> upstream tags: taglist, video-codec=(string)"AOM\ AV1", language-code=(string)und, extended-comment=(string){ "HANDLER_NAME\=ISO\ Media\ file\ produced\ by\ Google\ Inc.", "VENDOR_ID\=\[0\]\[0\]\[0\]\[0\]", "DURATION\=00:04:27.583000000" }, minimum-bitrate=(uint)1438, maximum-bitrate=(uint)6324395, bitrate=(uint)72272; Verified with mpv that it is indeed 10 bit, which says it's yuv420p10. => I don't think clapper has a problem playing 10 bit files and there is a different issue.
Thanks for testing. What's your GPU? Could you provide your `vainfo` output?
Just tested this on my computer, installed clipper, libva-utils and gstreamer1-plugins-bad-free. Video runs fine. vainfo: ``` Trying display: wayland libva info: VA-API version 1.20.0 libva info: Trying to open /usr/lib64/dri/radeonsi_drv_video.so libva info: Found init function __vaDriverInit_1_20 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.20 (libva 2.20.1) vainfo: Driver version: Mesa Gallium driver 23.3.1 for AMD Radeon RX 6900 XT (radeonsi, navi21, LLVM 17.0.6, DRM 3.54, 6.6.8-200.fc39.x86_64) vainfo: Supported profile and entrypoints VAProfileMPEG2Simple : VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointVLD VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main : VAEntrypointVLD VAProfileVC1Advanced : VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice VAProfileH264Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointEncSlice VAProfileH264High : VAEntrypointVLD VAProfileH264High : VAEntrypointEncSlice VAProfileHEVCMain : VAEntrypointVLD VAProfileHEVCMain : VAEntrypointEncSlice VAProfileHEVCMain10 : VAEntrypointVLD VAProfileHEVCMain10 : VAEntrypointEncSlice VAProfileJPEGBaseline : VAEntrypointVLD VAProfileVP9Profile0 : VAEntrypointVLD VAProfileVP9Profile2 : VAEntrypointVLD VAProfileAV1Profile0 : VAEntrypointVLD VAProfileNone : VAEntrypointVideoProc ```
Oh, and: ❯ GST_DEBUG=videodecoder*:4 clapper 4K\ HEVC\ 59.940\ Broadcast\ Capture\ Sample.mkv (com.github.rafostar.Clapper:10027): Gtk-WARNING **: 09:14:16.424: Unknown key gtk-modules in /home/farchord/.config/gtk-4.0/settings.ini (com.github.rafostar.Clapper:10027): Adwaita-WARNING **: 09:14:16.434: Using GtkSettings:gtk-application-prefer-dark-theme with libadwaita is unsupported. Please use AdwStyleManager:color-scheme instead. 0:00:00.214264729 10027 0x7f59e40012c0 INFO videodecoder gstvideodecoder.c:1640:gst_video_decoder_sink_event_default:<vah265dec0> upstream tags: taglist, video-codec=(string)HEVC, language-code=(string)und;
Thanks to everyone who provided their test results. It seems, you are all testing on Fedora 39, while I'm experiencing this bug on Fedora 38. The main difference here is Mesa, which is at 23.1.9 on F38 and at 23.3.1 on F39.
Ok, one more bit of information: this crashes only in an Xorg session and it looks like a bug in Mesa. Linking possibly relevant Mesa MR and GStreamer work-around.
And https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5778 is the backport of https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5760 to 1.22 branch and I can confirm it fixes playback for me. No more crashes.
FEDORA-2024-c908c13d58 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-c908c13d58
FEDORA-2024-1ca8282d12 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2024-1ca8282d12
FEDORA-2024-84a4b48f03 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2024-84a4b48f03
FEDORA-2024-c908c13d58 has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-1ca8282d12 has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-1ca8282d12` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-1ca8282d12 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-84a4b48f03 has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-84a4b48f03` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-84a4b48f03 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-1ca8282d12 has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-84a4b48f03 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.