Branch: refs/heads/webkitglib/2.54
Home: https://github.com/WebKit/WebKit
Commit: 771c4aa23e855b1a0ee9cd852bd7fc04affc430a
https://github.com/WebKit/WebKit/commit/771c4aa23e855b1a0ee9cd852bd7fc04affc430a
Author: Philippe Normand <[email protected]>
Date: 2026-10-14 (Wed, 14 Oct 2026)
Changed paths:
M Source/WebCore/platform/audio/gstreamer/WebKitWebAudioSourceGStreamer.cpp
M Source/WebCore/platform/gstreamer/GStreamerQuirkOpenMAX.cpp
M Source/WebCore/platform/gstreamer/GStreamerQuirkOpenMAX.h
M Source/WebCore/platform/gstreamer/GStreamerQuirks.cpp
M Source/WebCore/platform/gstreamer/GStreamerQuirks.h
Log Message:
-----------
Cherry-pick 323446@main (db2523163fd4).
https://bugs.webkit.org/show_bug.cgi?id=326494
[GStreamer][WebAudio] Remove gap buffer handling from webaudiosrc element
https://bugs.webkit.org/show_bug.cgi?id=326494
Reviewed by Xabier Rodriguez-Calvar.
Gap buffers are specially misleading the audio sink's ring-buffer at
startup and this is affecting
all sinks with a ring-buffer implementation, not only RPi platforms.
* Source/WebCore/platform/audio/gstreamer/WebKitWebAudioSourceGStreamer.cpp:
(webKitWebAudioSrcRenderAndPushFrames):
* Source/WebCore/platform/gstreamer/GStreamerQuirkOpenMAX.cpp:
(WebCore::GStreamerQuirkOpenMAX::processWebAudioSilentBuffer const):
Deleted.
* Source/WebCore/platform/gstreamer/GStreamerQuirkOpenMAX.h:
* Source/WebCore/platform/gstreamer/GStreamerQuirks.cpp:
(WebCore::GStreamerQuirksManager::processWebAudioSilentBuffer const):
Deleted.
* Source/WebCore/platform/gstreamer/GStreamerQuirks.h:
(WebCore::GStreamerQuirk::processWebAudioSilentBuffer const): Deleted.
Canonical link: https://commits.webkit.org/323446@main
Canonical link: https://commits.webkit.org/317695.448@webkitglib/2.54
Commit: 0d64e0804c002732a57658bf7603fd1d0dfe49f6
https://github.com/WebKit/WebKit/commit/0d64e0804c002732a57658bf7603fd1d0dfe49f6
Author: Philippe Normand <[email protected]>
Date: 2026-10-14 (Wed, 14 Oct 2026)
Changed paths:
M
Source/WebCore/platform/mediastream/libwebrtc/gstreamer/GStreamerVideoDecoderFactory.cpp
Log Message:
-----------
Cherry-pick 323201@main (4612ff747bea).
https://bugs.webkit.org/show_bug.cgi?id=326516
[GStreamer][LibWebRTC] Ignore incoming video buffers without duration
https://bugs.webkit.org/show_bug.cgi?id=326516
Reviewed by Xabier Rodriguez-Calvar.
In some cases the H.264 parser fails to find a frame to parse in its
incoming buffer, and it sets
a zero duration on the output buffer. As this buffer also doesn't have a
valid PTS, most decoders
will fail to process it and this would result in potentially frozen video
rendering.
This was observed on GeForce Now running on a device where the Qualcomm
video decoder is used.
*
Source/WebCore/platform/mediastream/libwebrtc/gstreamer/GStreamerVideoDecoderFactory.cpp:
Canonical link: https://commits.webkit.org/323201@main
Canonical link: https://commits.webkit.org/317695.449@webkitglib/2.54
Commit: c1c1526f28485ef85fa854de1a46f73177824e38
https://github.com/WebKit/WebKit/commit/c1c1526f28485ef85fa854de1a46f73177824e38
Author: Daniel Golle <[email protected]>
Date: 2026-10-14 (Wed, 14 Oct 2026)
Changed paths:
M Source/WebCore/platform/graphics/gstreamer/VideoFrameGStreamer.cpp
Log Message:
-----------
Cherry-pick 323197@main (f3ef8627533a).
https://bugs.webkit.org/show_bug.cgi?id=326829
[GStreamer] DMABuf video frames are sized from the padded GstVideoMeta,
decoder padding rows show on screen
https://bugs.webkit.org/show_bug.cgi?id=326829
Reviewed by Philippe Normand.
VideoFrameGStreamer::getDMABuf() sizes the imported DMABuf from the
GstVideoMeta width and height. The meta describes the buffer's memory
layout; a V4L2 stateless decoder fills it with the coded size of the
capture format (gst_v4l2_codec_pool_acquire_buffer), so a 1080-line
stream decoded into 1088-line buffers is imported as 1920x1088 and
scaled into the 1080-line layer. The eight padding lines show up as a
green stripe along the bottom of every frame.
The caps carry the display size. Take the frame size from the
GstVideoInfo and keep only the plane strides and offsets from the meta,
as GStreamer's own dmabuf upload does for its display path. Bug 268416
made the same correction for the previous DMABuf path; the DMA-BUF video
sink from bug 279672 sized from the meta again.
* Source/WebCore/platform/graphics/gstreamer/VideoFrameGStreamer.cpp:
(WebCore::VideoFrameGStreamer::getDMABuf):
Canonical link: https://commits.webkit.org/323197@main
Canonical link: https://commits.webkit.org/317695.450@webkitglib/2.54
Commit: de6d5cfefc83cb02e7e3aaaa8df72a90c5d90f2d
https://github.com/WebKit/WebKit/commit/de6d5cfefc83cb02e7e3aaaa8df72a90c5d90f2d
Author: Philippe Normand <[email protected]>
Date: 2026-10-14 (Wed, 14 Oct 2026)
Changed paths:
M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp
Log Message:
-----------
Cherry-pick 323725@main (32bddab963d0).
https://bugs.webkit.org/show_bug.cgi?id=327391
[GStreamer][MSE] Disable webkitthunderparser auto-plugging in non-MSE
players
https://bugs.webkit.org/show_bug.cgi?id=327391
Reviewed by Xabier Rodriguez-Calvar.
The webkitthunderparser element is useful only for MSE (and EME). In other
cases it triggers issues,
specially because it exposes a single source pad, so it cannot handle muxed
content containing more
than one content type.
*
Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
(WebCore::MediaPlayerPrivateGStreamer::configureParsebin):
Canonical link: https://commits.webkit.org/323725@main
Canonical link: https://commits.webkit.org/317695.451@webkitglib/2.54
Commit: ad3eda9a0206362f129189f90509f3b3660ea54c
https://github.com/WebKit/WebKit/commit/ad3eda9a0206362f129189f90509f3b3660ea54c
Author: Gatolocoses <[email protected]>
Date: 2026-10-14 (Wed, 14 Oct 2026)
Changed paths:
M Source/WebCore/platform/graphics/gstreamer/VideoDecoderGStreamer.cpp
Log Message:
-----------
Cherry-pick 323703@main (5d9a0f5ccb2c).
https://bugs.webkit.org/show_bug.cgi?id=327481
[GStreamer][WebCodecs] AV1 VideoDecoder: every decode() fails, no av1parse
before the decoder
https://bugs.webkit.org/show_bug.cgi?id=327481
Reviewed by Philippe Normand.
The AV1 input caps were pushed directly to the decoder. vaav1dec requires a
profile
field and av1dec (libaom) requires TU alignment, so both rejected the caps
and every
decode() call failed. Insert av1parse in front of the decoder when it
cannot sink the
caps, as already done for H.264, H.265 and VP9.
No new tests: the failure depends on which AV1 decoder elements are
installed.
Tested manually with vaav1dec and av1dec on WebKitGTK 2.54.0.
* Source/WebCore/platform/graphics/gstreamer/VideoDecoderGStreamer.cpp:
(WebCore::GStreamerInternalVideoDecoder::GStreamerInternalVideoDecoder):
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Canonical link: https://commits.webkit.org/323703@main
Canonical link: https://commits.webkit.org/317695.452@webkitglib/2.54
Compare: https://github.com/WebKit/WebKit/compare/643093f75b1a...ad3eda9a0206
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
