Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: b3d3dc5c2be0d1836ef3feba7680721399109725
https://github.com/WebKit/WebKit/commit/b3d3dc5c2be0d1836ef3feba7680721399109725
Author: Marek Vasut <ma...@denx.de>
Date: 2024-01-31 (Wed, 31 Jan 2024)
Changed paths:
M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp
Log Message:
-----------
[GStreamer] Use m_videoSize for DMABuf dimensions if available
https://bugs.webkit.org/show_bug.cgi?id=268416
Reviewed by Philippe Normand.
In case of hardware decoding of H.264 video with dimensions that are
not macroblock aligned, e.g. 1080x1920, the VideoMeta might indicate
the actual physical dimensions of the buffer containing the decoded
video data, as written by the hardware decoder, that is 1088x1920
instead of 1080x1920 . This leads to an 8px wide stripe of corrupted
pixels at the edge of the displayed video.
The valid video data are a subset of that buffer content and their
dimensions can be obtained from caps. The code already stores those
dimensions in m_videoSize, so in case m_videoSize is not empty, use
dimensions from m_videoSize instead of the buffer dimensions.
This happens on NXP i.MX8M Plus with Hantro G1 VPU .
This fix is similar to GStreamer commit:
0b648f9a2d1e ("waylandsink: Crop surfaces to their display width height")
* Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
(WebCore::MediaPlayerPrivateGStreamer::pushDMABufToCompositor):
Canonical link: https://commits.webkit.org/273819@main
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
