Bug 2256693

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.