Branch: refs/heads/webkitglib/2.40
Home: https://github.com/WebKit/WebKit
Commit: ea7c20dfa5aa52dff6d8f740f37e7872177dc835
https://github.com/WebKit/WebKit/commit/ea7c20dfa5aa52dff6d8f740f37e7872177dc835
Author: Žan Doberšek <[email protected]>
Date: 2023-03-03 (Fri, 03 Mar 2023)
Changed paths:
M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp
Log Message:
-----------
Cherry-pick 261072@main (5c473b4124bf).
https://bugs.webkit.org/show_bug.cgi?id=253244
[GStreamer] Establish locking when mapping gbm_bo objects for
software-decoded data upload
https://bugs.webkit.org/show_bug.cgi?id=253244
Reviewed by Philippe Normand.
When separate GStreamer pipelines are established for different video
elements,
mapping the gbm_bo objects in parallel across different threads can lead to
crashes and GPU memory corruption.
The different gbm_bo objects originate from a single gbm_device, which is
fine.
Spawning gbm_bo objects and retrieving different attributes from them isn't
showing as problematic, but libgbm thread safety guarantees still need
research.
Mapping gbm_bo objects in parallel is proving as problematic, and the
length of
the upload of software-decoded data into the mapped memory regions takes
long
enough for these problems to inhibit stability. To avoid that, a global
lock is
provided on the gbm_bo-mapping Destination class inside the
MediaPlayerPrivateGStreamer::pushDMABufToCompositor() method. This lock is
activated whenever data for a given plane is moved over from the
GStreamer-based
software decoder into the gbm_bo object.
*
Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
(WebCore::MediaPlayerPrivateGStreamer::pushDMABufToCompositor):
Canonical link: https://commits.webkit.org/261072@main
Commit: 49971be69094bede8d25c2129b98eaf33dcb85c4
https://github.com/WebKit/WebKit/commit/49971be69094bede8d25c2129b98eaf33dcb85c4
Author: Žan Doberšek <[email protected]>
Date: 2023-03-03 (Fri, 03 Mar 2023)
Changed paths:
M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp
Log Message:
-----------
Cherry-pick 261077@main (9b1c8b87c0a4).
https://bugs.webkit.org/show_bug.cgi?id=253245
[GStreamer] Improve GBM swapchain buffer handling
https://bugs.webkit.org/show_bug.cgi?id=253245
Reviewed by Philippe Normand.
In MediaPlayerPrivateGStreamer::pushDMABufToCompositor(), when allocating
buffer objects from the GBMBufferSwapchain to upload the software-decoded
video data, do a null check on the retrieved buffer. This avoids proceeding
with
a null object that would be returned when for whatever perverse reason the
swapchain is drained of available buffers.
One such reason is when allocating, retrieving and locking buffers from the
swapchain under an inactive proxy. In that case, the buffer doesn't end up
being pushed into the composition, and it's then also never released and
made
available for reuse, effectively draining the swapchain.
This case is avoidable through earlier detection of an inactive proxy. The
proxy
lock and is-active check are unified between different codepaths and done
before
deciding which codepath is taken.
*
Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
(WebCore::MediaPlayerPrivateGStreamer::pushDMABufToCompositor):
Canonical link: https://commits.webkit.org/261077@main
Compare: https://github.com/WebKit/WebKit/compare/90e92d2420f1...49971be69094
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
