Bug 268416 - [GStreamer] Use m_videoSize for DMABuf dimensions if available
Summary: [GStreamer] Use m_videoSize for DMABuf dimensions if available
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Platform (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2024-01-30 15:13 PST by Marek Vasut
Modified: 2024-01-31 02:02 PST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marek Vasut 2024-01-30 15:13:55 PST
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")
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/0b648f9a2d1e
Comment 1 Marek Vasut 2024-01-30 15:17:44 PST
PR https://github.com/WebKit/WebKit/pull/23543
Comment 2 EWS 2024-01-31 02:01:23 PST
Committed 273819@main (b3d3dc5c2be0): <https://commits.webkit.org/273819@main>

Reviewed commits have been landed. Closing PR #23543 and removing active labels.
Comment 3 Radar WebKit Bug Importer 2024-01-31 02:02:15 PST
<rdar://problem/121999536>