Bug 260654 - [Nvidia][GStreamer][GTK] Unable to play any video whatsoever
Summary: [Nvidia][GStreamer][GTK] Unable to play any video whatsoever
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: WebKit Nightly Build
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords:
: 260456 (view as bug list)
Depends on:
Blocks:
 
Reported: 2023-08-24 05:28 PDT by Kdwk
Modified: 2024-04-04 16:39 PDT (History)
3 users (show)

See Also:


Attachments
Videos are now green (105.19 KB, image/png)
2024-03-03 18:45 PST, Kdwk
no flags Details
Compressed dots folder (215.57 KB, application/zip)
2024-03-05 02:13 PST, Kdwk
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kdwk 2023-08-24 05:28:10 PDT
Supersedes https://bugs.webkit.org/show_bug.cgi?id=260456

With Epiphany 45.beta-40-g17c238bbb+/ WebKitGTK 2.41.91, no matter what environment variable set, no video can be played (without crashing).

With no environment variable set, the web view cannot be shown.

With WEBKIT_DISABLE_DMABUF_RENDERER=1, sites with video crash.

With WEBKIT_GST_DMABUF_SINK_DISABLED=1, sites don't crash but videos are black or refuse to be played.

Disabling the GL sink (forgot the environment variable), the video plays for a few seconds then Epiphany receives SIGSEGV, with backtrace that looks like "??()".

GST_PLUGIN_FEATURE_RANK=nvav1dec:MAX,nvh264dec:MAX,nvh265dec:MAX,nvjpegdec:MAX,nvmpeg2videodec:MAX,nvmpeg4videodec:MAX,nvmpegvideodec:MAX,nvvp8dec:MAX,nvvp9dec:MAX does not appear to make any difference.

This only happens in Epiphany Technology Preview/ WebKitGTK 2.41.x, but not in Gnome Web/ WebKitGTK 2.40.x, where video playback works and hardware-accelerated decode works as well.
Comment 1 Kdwk 2023-08-24 05:28:51 PDT
*** Bug 260456 has been marked as a duplicate of this bug. ***
Comment 2 Erik Kurzinger 2023-11-08 12:21:46 PST
Based on the discussion from https://bugs.webkit.org/show_bug.cgi?id=261874 at least part of the problem is that current versions of the NVIDIA driver do not support allocating GBM buffers with the R8 format. However, the next release (550) will support this. So it may be worth re-testing when that goes public later this year.
Comment 3 Kdwk 2024-03-03 18:45:58 PST
Created attachment 470157 [details]
Videos are now green

Erik, I have retested this with the 550.54.14 driver and videos became green instead
Comment 4 Philippe Normand 2024-03-04 13:14:14 PST
It would be interesting to know which format the video decoder outputs and which format the video sink negotiates... Can you share pipeline dumps?
Comment 5 Kdwk 2024-03-05 01:47:59 PST
How can I get that information?
Comment 7 Kdwk 2024-03-05 02:13:01 PST
Created attachment 470179 [details]
Compressed dots folder

Thanks. Here's the compressed dot directory after running the command with youtube.com and playing a few videos there.
Comment 8 Philippe Normand 2024-03-05 02:36:17 PST
So the decoder outputs raw NV12 and for rendering we convert that to DMABufs within WebKit. That might be where the problem is.
Comment 9 Philippe Normand 2024-03-06 12:38:27 PST
> With WEBKIT_GST_DMABUF_SINK_DISABLED=1, sites don't crash but videos are black or refuse to be played.

Is this still happening?
Comment 10 Kdwk 2024-03-07 04:35:03 PST
Currently, with WEBKIT_GST_DMABUF_SINK_DISABLED=1 videos aren't black but simply don't play. Without this environment variable, videos seemingly can play, but they are green.
Comment 11 Kdwk 2024-04-01 21:18:02 PDT
Erik, this issue still persists with Nvidia driver 550. Though GBM buffers with R8 formats are now supported, there remains a problem with converting raw NV12 to DMABufs. Nvidia users cannot view any video in WebKitGTK apps until this is resolved.
Comment 12 Erik Kurzinger 2024-04-04 16:39:50 PDT
> there remains a problem with converting raw NV12 to DMABufs

Could you clarify what you mean by this? With the 550 driver it should be possible to allocate an NV12 GBM buffer and export it as a pair of DMA-BUFs. Note, though, that support for this format in our EGL driver is "external only". So if an NV12 buffer is imported as an EGLImage, that image can only be bound to GL_TEXTURE_EXTERNAL_OES (not, for example, GL_TEXTURE_2D). Could that maybe be the problem?