Bug 288464 – REGRESSION(283836@main): [GStreamer] Degraded video rendering performance on RPi5 devices

• Status: NEW
• Component: Platform

[Pablo Saavedra]

Created attachment 474340 [details]
GST .dot and logs from a main webkit

I’m investigating a **performance regression** in **WPEWebKit main** compared to **2.46** on **RPi5 (Mesa)**.

The summary is the following:

- In **WPEWebKit 2.46.6** (with `WEBKIT_GST_DMABUF_SINK_ENABLED=1`), **Big Buck Bunny 1080p** plays smoothly at **30 FPS**.
- On **main** (even ensuring `WEBKIT_GST_DMABUF_SINK_DISABLED=0`), FPS drops to **3 FPS**, with significantly higher CPU usage.
- **Pipeline graphs** show differences between versions:
    - **2.46:**: https://matrix.igalia.com/_matrix/media/v3/download/igalia.com/nzYKgbezBXYCxMHlwGQMGmRH?allow_redirect=true
    - **main:**: https://matrix.igalia.com/_matrix/media/v3/download/igalia.com/YxxpVmEnbdoJrvTViVPHzcQT?allow_redirect=true

### Debugging So Far:

- **No hardware decoding** support for **RPi5**, but playback was working fine up to **2.46** with **GST DMABuf video sink enabled**.
- **Checked:** `USE(GBM) is ON`.
- **Verified:** `s_isDMABufDisabled` in `initializeDMABufAvailability()` is set correctly (to **0**).
- It is not clear to me whether the video is producing DMA-BUF or GL textures. The fact that the DMABUF sink is enabled does not necessarily mean that DMABUF is being used; it depends on the video.
- Regression in 2.48.X since registered since:  [GStreamer] Add support for DMA-BUF to GL video sink https://bugs.webkit.org/show_bug.cgi?id=279672

[Pablo Saavedra]

Created attachment 474343 [details]
.DOT files for  gst-launch-1.0  videotestsrc ! glimagesink

Attached the .dot generated for this gst pipeline:

$ gst-launch-1.0  videotestsrc ! glimagesink 
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got context from element 'sink': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayWayland\)\ gldisplaywayland0";
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
Redistribute latency...
New clock: GstSystemClock
^Chandling interrupt.
Interrupt: Stopping pipeline ...
Execution ended after 0:00:03.581214802
Setting pipeline to NULL ...
Freeing pipeline ...
weston@raspberrypi5:~$ cd /tmp/gst-out/
weston@raspberrypi5:/tmp/gst-out$ ls
0.00.00.065416520-gst-launch.NULL_READY.dot  0.00.00.156887566-gst-launch.READY_PAUSED.dot  0.00.00.157498416-gst-launch.PAUSED_PLAYING.dot  0.00.03.738639366-gst-launch.PLAYING_PAUSED.dot  0.00.03.739411068-gst-launch.PAUSED_READY.dot

[Philippe Normand]

This is not what I asked.

Please try this: gst-play-1.0 --videosink glimagesink /some/file.mp4

[Pablo Saavedra]

Created attachment 474355 [details]
.DOT files for  gst-play-1.0 --videosink glimagesink bbb_sunflower_1080p_30fps_normal.mp

here the right .dot files

[Pablo Saavedra]

Some notes about the execution of the previous command:

During the execution of gst-play  (using the same video as I used for wpewebkit) , the video playback is almost smooth. CPU in use in undercontrol , none of the cores goes higher to 50%, however I noticed some freezes what their are also reported in by gst: 

WARNING A lot of buffers are being dropped.
WARNING debug information: /usr/src/debug/gstreamer1.0/1.24.12/libs/gst/base/gstbasesink.c(3147): gst_base_sink_is_too_late (): /GstPlayBin3:playbin/GstPlaySink:playsink/GstBin:vbin/GstGLImageSinkBin:glimagesinkbin0/GstGLImageSink:sink:
There may be a timestamping problem, or this computer is too slow.
WARNING A lot of buffers are being dropped.
WARNING debug information: /usr/src/debug/gstreamer1.0/1.24.12/libs/gst/base/gstbasesink.c(3147): gst_base_sink_is_too_late (): /GstPlayBin3:playbin/GstPlaySink:playsink/GstBin:vbin/GstGLImageSinkBin:glimagesinkbin0/GstGLImageSink:sink:
There may be a timestamping problem, or this computer is too slow.
WARNING A lot of buffers are being dropped.
WARNING debug information: /usr/src/debug/gstreamer1.0/1.24.12/libs/gst/base/gstbasesink.c(3147): gst_base_sink_is_too_late (): /GstPlayBin3:playbin/GstPlaySink:playsink/GstBin:vbin/GstGLImageSinkBin:glimagesinkbin0/GstGLImageSink:sink:
There may be a timestamping problem, or this computer is too slow.
WARNING A lot of buffers are being dropped.
WARNING debug information: /usr/src/debug/gstreamer1.0/1.24.12/libs/gst/base/gstbasesink.c(3147): gst_base_sink_is_too_late (): /GstPlayBin3:playbin/GstPlaySink:playsink/GstBin:vbin/GstGLImageSinkBin:glimagesinkbin0/GstGLImageSink:sink:
There may be a timestamping problem, or this computer is too slow.
WARNING A lot of buffers are being dropped.
WARNING debug information: /usr/src/debug/gstreamer1.0/1.24.12/libs/gst/base/gstbasesink.c(3147): gst_base_sink_is_too_late (): /GstPlayBin3:playbin/GstPlaySink:playsink/GstBin:vbin/GstGLImageSinkBin:glimagesinkbin0/GstGLImageSink:sink:
There may be a timestamping problem, or this computer is too slow.

[Philippe Normand]

The negotiated video caps are the same in both cases, so I'm not sure we can do much about this on WebKit side...

If playback isn't smooth either with gst-play-1.0 (was it ever? with software decoding?) then i'm afraid this could be a GStreamer bug.