Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backport HEVC decoder as submitted to linux-media as v2 #6666

Open
wants to merge 19 commits into
base: rpi-6.12.y
Choose a base branch
from

Conversation

6by9
Copy link
Contributor

@6by9 6by9 commented Feb 12, 2025

This PR:

  • reverts the downstream HEVC driver and supporting patches
  • backports the driver as submitted as v2 (https://lore.kernel.org/r/[email protected]) with DT binding fixup requested by Rob H, and dependencies.
  • adds in the new SAND handling for DRM
  • reinstates the downstream single planar pixel formats for decode
  • reinstates being able to set the /dev/videoN node

This doesn't work against the existing FFmpeg as it is looking for extra flags to identify a device that it thinks can decode HEVC. @jc-kynesim was going to release his updated FFmpeg that handles this, otherwise I can look at whether we can expose a second /dev/videoN node that adds in those flags as an interim.

This wants more thorough testing, hence looking to push it to rpi-6.12.y.

6by9 and others added 19 commits February 11, 2025 15:34
By default when the last request object is completed, the whole
request completes as well.

But sometimes you want to manually complete a request in a driver,
so add a manual complete mode for this.

In req_queue the driver marks the request for manual completion by
calling media_request_mark_manual_completion, and when the driver
wants to manually complete the request it calls
media_request_manual_complete().

Signed-off-by: Hans Verkuil <[email protected]>
Manually complete the requests: this tests the manual completion
code.

Signed-off-by: Hans Verkuil <[email protected]>
Keep track of the number of requests and request objects of a media
device. Helps to verify that all request-related memory is freed.

Signed-off-by: Hans Verkuil <[email protected]>
The Raspberry Pi HEVC decoder uses a tiled format based on
columns for 8 and 10 bit YUV images, so document them as
NV12MT_COL128 and NV12MT_10_COL128.

Signed-off-by: Dave Stevenson <[email protected]>
Add V4L2_PIXFMT_NV12MT_COL128 and V4L2_PIXFMT_NV12MT_10_COL128
to describe the Raspberry Pi HEVC decoder NV12 multiplanar formats.

Signed-off-by: Dave Stevenson <[email protected]>
Adds a binding for the HEVC decoder found on the BCM2711 / Raspberry Pi 4,
and BCM2712 / Raspberry Pi 5.

Signed-off-by: Dave Stevenson <[email protected]>
The BCM2711 and BCM2712 SoCs used on Rapsberry Pi 4 and Raspberry
Pi 5 boards include an HEVC decoder block. Add a driver for it.

Signed-off-by: John Cox <[email protected]>
Signed-off-by: Dave Stevenson <[email protected]>
Add the configuration information for the HEVC decoder.

Signed-off-by: Dave Stevenson <[email protected]>
For downstream only, add back in the legacy single planar
SAND formats.

Signed-off-by: Dave Stevenson <[email protected]>
Upstream will take the multi-planar SAND format, but add back
in the downstream single planar variant for backwards compatibility

Signed-off-by: Dave Stevenson <[email protected]>
The SAND handling had been using what was believed to be a runtime
parameter in the modifier, however that has been clarified that
all permitted variants of the modifier must be advertised, so
making it variable wasn't practical.

With a rationalisation of how the producers of this format are
configured, we can switch to a variant that doesn't have as much
variation, and can be configured such that only 2 options are
required.

Add a modifier with value 0 to denote that the height of the luma
column matches the buffer height, and chroma column will be half
that due to YUV420.
A modifier of 1 denotes that the height of the luma column still
matches the buffer height, but the chroma column height is the same.
This can be used to replicate the previous behaviour.

Signed-off-by: Dave Stevenson <[email protected]>
To avoid user complaints that /dev/video0 isn't their USB
webcam, add downstream patch that allows setting the preferred
video device number.

Signed-off-by: Dave Stevenson <[email protected]>
@popcornmix
Copy link
Collaborator

I think we want ffmpeg update public (or the second /dev/videoN node) before merging this.

@6by9
Copy link
Contributor Author

6by9 commented Feb 12, 2025

I think we want ffmpeg update public (or the second /dev/videoN node) before merging this.

I'd asked @jc-kynesim whether the FFmpeg side had been released on Friday, and he'd replied

Not yet - but that is only the work of an hour or two. I'll do that today

I don't know if that happened.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants