Skip to content

[RK3588]Add H.265 Hardware Encoding Support & HDMIRX fix by @rcawston #10091

Open
pdapandapda wants to merge 39 commits into
armbian:mainfrom
pdapandapda:main
Open

[RK3588]Add H.265 Hardware Encoding Support & HDMIRX fix by @rcawston #10091
pdapandapda wants to merge 39 commits into
armbian:mainfrom
pdapandapda:main

Conversation

@pdapandapda

@pdapandapda pdapandapda commented Jun 30, 2026

Copy link
Copy Markdown
Contributor

Description

Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
As the mainline kernel haven't fixed the vepu580 hardware encoder and hdmirx for months, I think it is safe to port the patches by @rcawston from https://github.com/rcawston/rockchip-rk3588-mainline-patches. I have been using the patches as userpatch for months, from 6.18 to 7.2 rc1.

Documentation summary for feature / change

The following is just a copy-paste from https://github.com/rcawston/rockchip-rk3588-mainline-patches

This repository contains an out-of-tree patches for RK3588 to a near-mainline kernel (tested on v6.19-rc8)

Current Patches:

H.265 Hardware Encoding Support: 0001-rockchip-rk3588-vepu580-encoder-support-v2.patch
Set EDID Fix: 0002-rockchip-rk3588-hdmirx-edid-fix-v1.patch
Fix buffer overflow on repeated HDMIRX replug: 0003-rockchip-rk3588-hdmirx-plugout-fix-v1.patch
Testing is done on Rock 5B[+] and Orange Pi 5 Ultra.

VEPU580 H.265 Encoder Driver
Latest version: 0001-rockchip-rk3588-vepu580-encoder-support-v2.patch

This repository contains an out-of-tree patch series adding stateful H.265 (HEVC) encoding support for the Rockchip RK3588's VEPU580 encoder block to a near-mainline kernel (tested on v6.19-rc8).

Status: Functional dual-core encoding. Produces valid H.265 bitstreams at 4K@60. Multi-core load balancing works.

Goal: Provide a practical, high-performance encoder driver for RK3588 boards (Orange Pi 5 Ultra, Radxa Rock 5B[+], etc.) while staying as close to mainline as possible. Not intended for upstream merge — although feedback welcome on design and upstreamability.

Motivation: Enable low-latency hardware-accelerated H.265 encoding for applications like IPKVM (e.g., SentinelKVM project) on mainline kernels without full vendor BSP dependency.

Pre-Requisite: Build & Install MPP
Build directly on the RK3588 device (or cross-compile for faster results).

Install Dependencies:
sudo apt update
sudo apt install cmake build-essential libdrm-dev libva-dev
Clone & Build:
git clone https://github.com/tsukumijima/mpp-rockchip.git
cd mpp-rockchip
mkdir build && cd build
cmake .. -DCMAKE_INSTALL_PREFIX=/usr
make -j$(nproc)
sudo make install
sudo ldconfig # Update library cache
Verify
mpp_info # Should show MPP version and supported codecs (including HEVC encode)

Should enable rockchip-rk3588-rkvenc-mpp.dtbo in armbian-config

Set EDID Fix
Latest version: 0002-rockchip-rk3588-hdmirx-edid-fix-v1.patch

This patch addresses an issue where the EDID is not being written correctly to the HDMIRX block. The patch ensures that the EDID is correctly written and that the source device sees the newly set EDID.

Tested with various EDID including 4k@60hz support.

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration.

  • Functional dual-core encoding. Produces valid H.265 bitstreams at 4K@60. Multi-core load balancing works.
pda@orangepi5-ultra:~$ mpp_info
mpp[130374]: mpp_platform: client 1 driver is not ready!
mpp[130374]: mpp_platform: client 3 driver is not ready!
mpp[130374]: mpp_platform: client 4 driver is not ready!
mpp[130374]: mpp_platform: client 9 driver is not ready!
mpp[130374]: mpp_platform: client 12 driver is not ready!
mpp[130374]: mpp_platform: client 13 driver is not ready!
mpp[130374]: mpp_platform: client 18 driver is not ready!
mpp[130374]: mpp_platform: client 19 driver is not ready!
mpp[130374]: mpp_info_test: normal version log:
mpp[130374]: mpp_info: mpp version: 2e93ab79 author: Herman Chen   2026-04-28 fix: fix CHANGELOG.md
mpp[130374]: mpp_info_test: history version log:
mpp[130374]: mpp_info: mpp version history 10:
mpp[130374]: mpp_info: 2e93ab79 author: Herman Chen   2026-04-28 fix: fix CHANGELOG.md  (HEAD -> develop, origin/develop, origin/HEAD)
mpp[130374]: mpp_info: eeb89d7e author: Hongjin Li    2026-04-24 feat[vdpu384b]: Supports vdpu384b scaling down
mpp[130374]: mpp_info: 9a66cc6c author: Hongjin Li    2026-04-24 refactor[scale_down]: Thumbnail Frame Info.
mpp[130374]: mpp_info: 35811e92 author: Hongjin Li    2026-04-24 fix[sys_cfg]: For AFBC, fixed border extension of 8 pixels.
mpp[130374]: mpp_info: 045eb8ad author: Hongjin Li    2026-04-24 fix[vdpu38x]: YUV400 should be calculated as YUV420
mpp[130374]: mpp_info: d2d5f9d6 author: Herman Chen   2026-04-23 chore[inc]: Prepare for array refactoring
mpp[130374]: mpp_info: 264553f9 author: Yandong Lin   2026-04-23 fix[hal_h264e/h265e]: Fix the top address of bitstream buf
mpp[130374]: mpp_info: 2b7df1d7 author: Yandong Lin   2026-04-22 chore[git]: Add .claude to gitignore
mpp[130374]: mpp_info: 39468b5e author: Herman Chen   2026-04-22 chore[mpp_trie]: Add last info in add_entry
mpp[130374]: mpp_info: 8ccfd341 author: Herman Chen   2026-04-21 feat[mpp_trie]: Add progressive support
mpp[130374]: mpp_compat: id| name -- mpp compat info
mpp[130374]: mpp_compat: 0 | increase decoder fbc buffer size
mpp[130374]: mpp_compat: 1 | support encoder async input mode
pda@orangepi5-ultra:~$ 

  • Tested with various EDID including 4k@60hz support.

Checklist:

Please delete options that are not relevant.

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • My changes generate no new warnings

Summary by CodeRabbit

  • Bug Fixes
    • Improved HDMI RX hotplug/EDID handling with safer IRQ and HPD sequencing, improved signal-lock stabilization, and delayed hotplug completion.
    • Prevented user-space capture hangs during HDMI RX plug-out by erroring active streaming queues immediately.
  • New Features
    • Added an RK3588 VEPU580 (H.265/H.264) encoder device tree overlay via the MPP/rkvenc framework.
  • Chores
    • Updated Rockchip overlay build configuration to include the new encoder overlay.

@coderabbitai

coderabbitai Bot commented Jun 30, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

  • @coderabbitai resume to resume automatic reviews.
  • @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

  • ▶️ Resume reviews
  • 🔍 Trigger review

Walkthrough

HDMIRX handling is updated across three kernel branches to change EDID, hotplug, and signal-lock sequencing, and plugout now reports active V4L2 streaming errors. A new RK3588 rkvenc MPP overlay is also added and registered in the overlay Makefiles.

Changes

HDMIRX EDID/hotplug and signal-lock fixes

Layer / File(s) Summary
Timing constants, HPD sequencing, and EDID update path
patch/kernel/archive/rockchip64-6.18/0002-...patch, patch/kernel/archive/rockchip64-7.1/0002-...patch, patch/kernel/archive/rockchip64-7.2/0002-...patch
Adds timing constants, drives HPD low in plugout, disables HDMI and DMA IRQs during EDID handling, optionally calls plugout when 5V is present, keeps HPD low through EDID writes, re-enables IRQs, schedules delayed hotplug work, and asserts HPD high during plugin setup.
Signal-lock wait loop and DMA reset
patch/kernel/archive/rockchip64-6.18/0002-...patch, patch/kernel/archive/rockchip64-7.1/0002-...patch, patch/kernel/archive/rockchip64-7.2/0002-...patch
Updates the wait loop to use the new constants, adds a stability counter requiring sustained lock before exit, calls hdmirx_phy_config() periodically during retries, and replaces a short sleep with hdmirx_reset_dma() plus a longer delay before hdmirx_format_change().

HDMIRX plugout vb2 error signaling

Layer / File(s) Summary
vb2_queue_error on active streaming at plugout
patch/kernel/archive/rockchip64-6.18/0003-...patch, patch/kernel/archive/rockchip64-7.1/0003-...patch, patch/kernel/archive/rockchip64-7.2/0003-...patch
hdmirx_plugout() acquires stream_lock, checks vb2 buffer queue streaming state, and calls vb2_queue_error() so blocked DQBUF returns immediately instead of hanging until userspace timeout.

rkvenc MPP DT overlay for RK3588 VEPU580 encoder

Layer / File(s) Summary
Overlay Makefile registration
patch/kernel/archive/rockchip64-{6.18,7.1,7.2}/overlay/Makefile
Adds rockchip-rk3588-rkvenc-mpp.dtbo to the dtbo-$(CONFIG_ARCH_ROCKCHIP) list in all three kernel version Makefiles, fixing line continuation on the preceding entry.
rkvenc MPP overlay DT nodes
patch/kernel/archive/rockchip64-{6.18,7.1,7.2}/overlay/rockchip-rk3588-rkvenc-mpp.dtso
Defines the complete overlay: reserved-memory IOVA regions, aliases, mpp-srv service node, rkvenc-ccu coordination unit, two encoder core nodes with MMIO, IRQs, clocks/resets, SRAM, rcb-iova, power domains, and per-core IOMMU nodes.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Suggested reviewers

  • ColorfulRhino
  • HeyMeco
  • JohnTheCoolingFan
  • SuperKali
  • TheSnowfield
  • amazingfate
  • chainsx
  • efectn
  • igorpecovnik
  • rpardini
  • pyavitz
  • schwar3kat

Poem

🐇 I hop through HPD, low then high,
EDID waits while signals try.
A venty VEPU wakes to spin,
DQBUF stops hanging, let the fun begin!

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title matches the main changes: RK3588 H.265 encoding support and HDMIRX fixes.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@github-actions github-actions Bot added size/large PR with 250 lines or more 08 Milestone: Third quarter release Needs review Seeking for review Hardware Hardware related like kernel, U-Boot, ... Patches Patches related to kernel, U-Boot, ... labels Jun 30, 2026

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 7

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In
`@patch/kernel/archive/rockchip64-6.18/0002-rockchip-rk3588-hdmirx-edid-fix-v1.patch`:
- Around line 40-52: The delayed hotplug path is still being scheduled even when
EDID is cleared, which can let a stale worker reassert HPD after the clear-EDID
branch resets state. Update the hotplug scheduling and worker flow around
hdmirx_write_edid, delayed_work_hotplug, and the code that checks edid->blocks
so the delayed work is only queued for non-empty EDID and the worker/plugin path
also verifies edid_blocks_written before driving HPD. Keep the existing
enable_irq handling, but gate any HPD reassertion on valid written EDID state.

In
`@patch/kernel/archive/rockchip64-6.18/0003-rockchip-rk3588-hdmirx-plugout-fix-v1.patch`:
- Line 1: Remove the stray .DS_Store binary diff marker from the patch so the
archive only contains the intended Rockchip HDMIRX change; update the patch
content to exclude any .DS_Store references in all branch copies, keeping the
diff focused on the actual synopsys/HDMIRX modification.

In
`@patch/kernel/archive/rockchip64-6.18/overlay/rockchip-rk3588-rkvenc-mpp.dtso`:
- Around line 9-10: The usage example is referencing the wrong overlay filename,
so update the comment in the rk3588 rkvenc MPP overlay to match the actual
source name. In the overlay documentation block near the top of
rockchip-rk3588-rkvenc-mpp.dtso, change the armbian-add-overlay example to use
the .dtso filename or otherwise match the real artifact name, so users can copy
the command without hitting a missing-file error.

In
`@patch/kernel/archive/rockchip64-7.1/0002-rockchip-rk3588-hdmirx-edid-fix-v1.patch`:
- Around line 40-52: The hotplug delayed work is being queued unconditionally in
this EDID update path, so it also runs when edid->blocks is zero and can raise
HPD without a valid EDID. Update the logic around hdmirx_write_edid,
hdmirx_hpd_ctrl, and delayed_work_hotplug so the work is only queued after a
successful EDID write, and either cancel or skip it on the clear-EDID branch
where cec_phys_addr_invalidate and edid_blocks_written reset happen.

In `@patch/kernel/archive/rockchip64-7.1/overlay/rockchip-rk3588-rkvenc-mpp.dtso`:
- Around line 9-10: The usage example is inconsistent with the overlay source
filename and should match the actual .dtso name. Update the usage text in the
rockchip-rk3588-rkvenc-mpp overlay comments so the example refers to
rockchip-rk3588-rkvenc-mpp.dtso, keeping the documented invocation consistent
with the source file and the overlay’s real identifier.

In
`@patch/kernel/archive/rockchip64-7.2/0002-rockchip-rk3588-hdmirx-edid-fix-v1.patch`:
- Around line 40-52: Only schedule the delayed hotplug after a successful EDID
write in the EDID handling path around hdmirx_write_edid/hdmirx_hpd_ctrl, and do
not queue it when edid->blocks is zero. When EDID is cleared, also cancel any
pending delayed_work_hotplug so hdmirx_plugin() cannot reassert HPD against an
empty EDID; keep the IRQ enable calls separate from the hotplug queuing logic.

In `@patch/kernel/archive/rockchip64-7.2/overlay/rockchip-rk3588-rkvenc-mpp.dtso`:
- Around line 9-10: The usage example in the overlay header is inconsistent with
the actual source filename; update the Usage line in the
rockchip-rk3588-rkvenc-mpp overlay comment so it references the .dtso name used
by this file. Keep the example aligned with the overlay’s real basename so users
see the correct armbian-add-overlay target.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 066808d4-feab-4154-a137-4d3cc7e34338

📥 Commits

Reviewing files that changed from the base of the PR and between 8f0344a and 2fc3e8a.

📒 Files selected for processing (15)
  • patch/kernel/archive/rockchip64-6.18/0001-rockchip-rk3588-vepu580-encoder-support-v3.patch
  • patch/kernel/archive/rockchip64-6.18/0002-rockchip-rk3588-hdmirx-edid-fix-v1.patch
  • patch/kernel/archive/rockchip64-6.18/0003-rockchip-rk3588-hdmirx-plugout-fix-v1.patch
  • patch/kernel/archive/rockchip64-6.18/overlay/Makefile
  • patch/kernel/archive/rockchip64-6.18/overlay/rockchip-rk3588-rkvenc-mpp.dtso
  • patch/kernel/archive/rockchip64-7.1/0001-rockchip-rk3588-vepu580-encoder-support-v3.patch
  • patch/kernel/archive/rockchip64-7.1/0002-rockchip-rk3588-hdmirx-edid-fix-v1.patch
  • patch/kernel/archive/rockchip64-7.1/0003-rockchip-rk3588-hdmirx-plugout-fix-v1.patch
  • patch/kernel/archive/rockchip64-7.1/overlay/Makefile
  • patch/kernel/archive/rockchip64-7.1/overlay/rockchip-rk3588-rkvenc-mpp.dtso
  • patch/kernel/archive/rockchip64-7.2/0001-rockchip-rk3588-vepu580-encoder-support-v3.patch
  • patch/kernel/archive/rockchip64-7.2/0002-rockchip-rk3588-hdmirx-edid-fix-v1.patch
  • patch/kernel/archive/rockchip64-7.2/0003-rockchip-rk3588-hdmirx-plugout-fix-v1.patch
  • patch/kernel/archive/rockchip64-7.2/overlay/Makefile
  • patch/kernel/archive/rockchip64-7.2/overlay/rockchip-rk3588-rkvenc-mpp.dtso

Comment thread patch/kernel/archive/rockchip64-6.18/overlay/rockchip-rk3588-rkvenc-mpp.dtso Outdated
Comment thread patch/kernel/archive/rockchip64-7.1/0002-rockchip-rk3588-hdmirx-edid-fix-v1.patch Outdated
Comment thread patch/kernel/archive/rockchip64-7.1/overlay/rockchip-rk3588-rkvenc-mpp.dtso Outdated
Comment thread patch/kernel/archive/rockchip64-7.2/0002-rockchip-rk3588-hdmirx-edid-fix-v1.patch Outdated
Comment thread patch/kernel/archive/rockchip64-7.2/overlay/rockchip-rk3588-rkvenc-mpp.dtso Outdated
pdapandapda and others added 20 commits July 1, 2026 02:27
Removed usage instructions and added modifier credit.
…rx-plugout-fix-v1.patch

Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
This patch adds support for the VPU580 encoder in the Rockchip RK3588 kernel.
This patch adds support for the VPU580 encoder in the Rockchip RK3588 kernel.
This patch adds support for the VPU encoder in the Rockchip RK3588.
Add support for VPU580 encoder in Rockchip RK3588.
This patch updates the rockchip64 kernel files related to HDMI RX functionality.
This patch updates the rockchip64 kernel files to fix the HDMI RX plug-out issue.
@rpardini

Copy link
Copy Markdown
Member

Err... I don't think this belongs. Does it?

It seems to shoehorn pieces of mpp from vendor into mainline so one could use rkmpp userspace for encoding. A kind-of midstream (remember that...).

Might fit into a separate branch or such, but not for regular edge, much less current.

@pdapandapda

Copy link
Copy Markdown
Contributor Author

Err... I don't think this belongs. Does it?

It seems to shoehorn pieces of mpp from vendor into mainline so one could use rkmpp userspace for encoding. A kind-of midstream (remember that...).

Might fit into a separate branch or such, but not for regular edge, much less current.

Thank you for the feedback, @rpardini. You are right, I have mixed the HDMIRX plugout/EDID stability fixes with the VPU580 encoder support. I understand that the encoder support might be too experimental or out of scope for the regular edge kernel. For the VPU580 support, I realize it's out of scope for the stable/regular edge kernel. I'll maintain that separately as a user-level/DKMS module or an optional patch for those who need it. Could you please review the cleaned-up PR once I push the changes

@rcawston

rcawston commented Jul 1, 2026

Copy link
Copy Markdown

I am the author of these patches originally.

The EDID fix has been simplified and exists in mainline Linux kernel already - it probably should not be included.

The encoder does work in extensive testing, put is a stop-gap to using MPP on mainline - fine if desired, but I would suggest it might be best left as an optional patch.

This patch series is indeed stable in my own testing.

@rpardini

rpardini commented Jul 2, 2026

Copy link
Copy Markdown
Member

The encoder does work in extensive testing, put is a stop-gap to using MPP on mainline - fine if desired, but I would suggest it might be best left as an optional patch.

Hey @rcawston -- does the whole of rkmpp work (eg also decoding, h264, av1, vp9, etc) or is this only about the hevc encoding? I ask because ffmpeg-rockchip / kodi eg https://github.com/armsurvivors/kodi-rockchip-deb -- it would be fun to get it on mainline, even if a stop-gap.

@pdapandapda

pdapandapda commented Jul 2, 2026

Copy link
Copy Markdown
Contributor Author

The encoder does work in extensive testing, put is a stop-gap to using MPP on mainline - fine if desired, but I would suggest it might be best left as an optional patch.

Hey @rcawston -- does the whole of rkmpp work (eg also decoding, h264, av1, vp9, etc) or is this only about the hevc encoding? I ask because ffmpeg-rockchip / kodi eg https://github.com/armsurvivors/kodi-rockchip-deb -- it would be fun to get it on mainline, even if a stop-gap.

Here is my result with ffmpeg-rockchip https://github.com/nyanmisaka/ffmpeg-rockchip/tree/8.1

pda@orangepi5-ultra:~$ ffmpeg -decoders | grep rkmpp
mpp[822620]: mpp_platform: client 1 driver is not ready!
mpp[822620]: mpp_platform: client 3 driver is not ready!
mpp[822620]: mpp_platform: client 4 driver is not ready!
mpp[822620]: mpp_platform: client 9 driver is not ready!
mpp[822620]: mpp_platform: client 12 driver is not ready!
mpp[822620]: mpp_platform: client 13 driver is not ready!
mpp[822620]: mpp_platform: client 18 driver is not ready!
mpp[822620]: mpp_platform: client 19 driver is not ready!
ffmpeg version f66f2f8046 Copyright (c) 2000-2026 the FFmpeg developers
  built with gcc 13 (Ubuntu 13.4.0-10ubuntu1)
  configuration: --prefix=/usr/local --enable-gpl --enable-version3 --enable-nonfree --enable-static --enable-shared --enable-libdrm --enable-rkmpp --enable-rkrga --enable-v4l2-m2m --enable-libx264 --enable-libaom --enable-libass --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libopus --enable-libsvtav1 --enable-libdav1d --enable-libvorbis --enable-libvpx --enable-libx265 --extra-cflags='-march=armv8.2-a+crypto+fp16+rcpc+dotprod' --extra-libs='-lpthread -lm -lz -ldl'
  libavutil      60. 26.100 / 60. 26.100
  libavcodec     62. 28.100 / 62. 28.100
  libavformat    62. 12.100 / 62. 12.100
  libavdevice    62.  3.100 / 62.  3.100
  libavfilter    11. 14.100 / 11. 14.100
  libswscale      9.  5.100 /  9.  5.100
  libswresample   6.  3.100 /  6.  3.100
 V..... av1_rkmpp            Rockchip MPP (Media Process Platform) AV1 decoder (codec av1)
 V..... h263_rkmpp           Rockchip MPP (Media Process Platform) H263 decoder (codec h263)
 V..... h264_rkmpp           Rockchip MPP (Media Process Platform) H264 decoder (codec h264)
 V..... hevc_rkmpp           Rockchip MPP (Media Process Platform) HEVC decoder (codec hevc)
 V..... mjpeg_rkmpp          Rockchip MPP (Media Process Platform) MJPEG decoder (codec mjpeg)
 V..... mpeg1_rkmpp          Rockchip MPP (Media Process Platform) MPEG1VIDEO decoder (codec mpeg1video)
 V..... mpeg2_rkmpp          Rockchip MPP (Media Process Platform) MPEG2VIDEO decoder (codec mpeg2video)
 V..... mpeg4_rkmpp          Rockchip MPP (Media Process Platform) MPEG4 decoder (codec mpeg4)
 V..... vp8_rkmpp            Rockchip MPP (Media Process Platform) VP8 decoder (codec vp8)
 V..... vp9_rkmpp            Rockchip MPP (Media Process Platform) VP9 decoder (codec vp9)
pda@orangepi5-ultra:~$ ffmpeg -encoders | grep rkmpp
mpp[849330]: mpp_platform: client 1 driver is not ready!
mpp[849330]: mpp_platform: client 3 driver is not ready!
mpp[849330]: mpp_platform: client 4 driver is not ready!
mpp[849330]: mpp_platform: client 9 driver is not ready!
mpp[849330]: mpp_platform: client 12 driver is not ready!
mpp[849330]: mpp_platform: client 13 driver is not ready!
mpp[849330]: mpp_platform: client 18 driver is not ready!
mpp[849330]: mpp_platform: client 19 driver is not ready!
ffmpeg version f66f2f8046 Copyright (c) 2000-2026 the FFmpeg developers
  built with gcc 13 (Ubuntu 13.4.0-10ubuntu1)
  configuration: --prefix=/usr/local --enable-gpl --enable-version3 --enable-nonfree --enable-static --enable-shared --enable-libdrm --enable-rkmpp --enable-rkrga --enable-v4l2-m2m --enable-libx264 --enable-libaom --enable-libass --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libopus --enable-libsvtav1 --enable-libdav1d --enable-libvorbis --enable-libvpx --enable-libx265 --extra-cflags='-march=armv8.2-a+crypto+fp16+rcpc+dotprod' --extra-libs='-lpthread -lm -lz -ldl'
  libavutil      60. 26.100 / 60. 26.100
  libavcodec     62. 28.100 / 62. 28.100
  libavformat    62. 12.100 / 62. 12.100
  libavdevice    62.  3.100 / 62.  3.100
  libavfilter    11. 14.100 / 11. 14.100
  libswscale      9.  5.100 /  9.  5.100
  libswresample   6.  3.100 /  6.  3.100
 V..... h264_rkmpp           Rockchip MPP (Media Process Platform) H264 encoder (codec h264)
 V..... hevc_rkmpp           Rockchip MPP (Media Process Platform) HEVC encoder (codec hevc)
 V..... mjpeg_rkmpp          Rockchip MPP (Media Process Platform) MJPEG encoder (codec mjpeg)
pda@orangepi5-ultra:~$ 


@rcawston

rcawston commented Jul 3, 2026

Copy link
Copy Markdown

Hey @rcawston -- does the whole of rkmpp work (eg also decoding, h264, av1, vp9, etc) or is this only about the hevc encoding? I ask because ffmpeg-rockchip / kodi eg https://github.com/armsurvivors/kodi-rockchip-deb -- it would be fun to get it on mainline, even if a stop-gap.

The patch is specific to HEVC encoding on the VEPU580 IP. H264 would fairly easy to add, but I didn't have a use case personally. Most decoding functionality already exists in mainline (VP8. MPEG2, MPEG4, H264, HEVC) and VP9 is in-progress (dvab-sarma/android_kernel_rk_opi@aa00b89).

@rpardini

rpardini commented Jul 7, 2026

Copy link
Copy Markdown
Member

Ok, thanks.

The way I see it, if we

  1. clean this up (drop or split the hdmirx stuff, if still useful and not landed upstream yet)
  2. clean up the main encoder patch, so rk3588-base.dtsi is not touched (instead move everything to the overlay)
  3. cleanup Makefile / Kconfig so it's trivial to completely disable this via .config (and enable it in default .config)
  4. be explicit about this being a vendor/midstream-like port in the Kconfig description
  5. initially keep only 7.2 (bleedingedge) -- if it goes well it will trickle down to current naturally over time

Then only the rockchip-iommu.c changes would interfere with pure-mainline, but it's literally 2 lines.

With that, if and when there is any progress in the encoder upstream, we can easily switch this off and go mainline.

@amazingfate what do you think? did I miss something? I remember you also had a dkms or such for rkmpp-on-mainline in the past?

@amazingfate

Copy link
Copy Markdown
Contributor

I have some concerns:

  • It only provides HEVC, no H264. While adding H264 support should be not hard.
  • MPP is out-of-tree solution which will never go upstream, so it's better to let the driver stay in dkms, and devicetree node stay in devicetree overlay.

@rpardini

rpardini commented Jul 7, 2026

Copy link
Copy Markdown
Member

Indeed. Having the full encode+decode rkmpp in a dkms would justify the effort. Still, there's changes to rockchip-iommu.c -- maybe those could be avoided somehow?

@amazingfate

Copy link
Copy Markdown
Contributor

Indeed. Having the full encode+decode rkmpp in a dkms would justify the effort. Still, there's changes to rockchip-iommu.c -- maybe those could be avoided somehow?

Adding decoder would conflict with the current upstreamed decoder nodes. About the changes at rockchip-iommu.c, I don't see why it is necessary. Is there anywhere else calling get_resv_regions from iommu_ops?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

08 Milestone: Third quarter release Hardware Hardware related like kernel, U-Boot, ... Needs review Seeking for review Patches Patches related to kernel, U-Boot, ... size/large PR with 250 lines or more

Development

Successfully merging this pull request may close these issues.

5 participants