Rockchip MPP: the vendor media stack behind Rockchip's hardware video codecs

The four layer acronyms and what each one is for

The README opens with the four abbreviations the whole tree is organised around, and understanding them is what makes the directory listing readable.

MPP is Media Process Platform, which is the project itself and the top level library. MPI is Media Process Interface, and that is the API an application includes to talk to the platform. HAL is Hardware Abstract Layer, which is where the chip specific register programming lives. OSAL is Operation System Abstract Layer, which is the operating system portability shim.

That is a conventional and sensible layering for a vendor SDK. The application sees MPI, MPI is implemented in terms of HAL, and HAL is implemented in terms of the actual silicon. The OSAL sits underneath all of it so the same HAL code compiles on Linux and Android.

The rules section states the conventions the project holds itself to, and they are worth reading because they tell you what kind of codebase this is. On header file arrangement, the inc directory in each module folder is for external module usage, module internal header files should be put along with the implementation file, and header files should not contain any relative or absolute path with all include paths kept in the Makefile. On the compiling system, for cross platform compiling cmake is used as the compiling management system, with a cmake out-of-source build so the final binary and library is installed to the out/ directory. And on header file include order, the order is MODULE_TAG, then system header, then osal header, then module header.

That include order is a real constraint on anyone writing code against the library. Because headers are not self-contained with their own paths, a translation unit that includes them in the wrong order will not compile, and the failure will look like a missing declaration rather than a rule violation. This is the kind of convention that a project enforces by documentation rather than by tooling, and it means a new contributor has to follow it or the build will not tell them why.

The primary language is C, the topics are hardware-acceleration and media-library, and the default branch is develop rather than main. The repository is not archived, the last push was on 2026-09-21, and there are no GitHub releases, so there is no version reference beyond the tree itself and the CHANGELOG.md at the root.

The codec layer, where the parsers and encoders live

The mpp/ directory is where the actual media work happens, and its structure is a complete map of what the library supports.

Under mpp/ there is base/, which holds the base components including MppBuffer, MppFrame, MppPacket, MppTask and MppMeta. These are the data types the whole library is built on, and the names tell you the model: a buffer, a frame, a packet, a task and metadata are the vocabulary of a media pipeline.

Under mpp/common/ is the video codec protocol syntax interface for both the codec parser and the HAL. That is the key architectural idea in the library, and it is what makes the register generation below possible. A single description of the codec syntax is shared between the part that parses a bitstream and the part that programs the hardware decoder, so the two cannot drift apart.

Under mpp/codec/ are all the video codec parsers that convert a stream to the protocol structure. The decoder list is av1, avs, avs2, h263, h264, h265, m2v, mpg4, vp8, vp9 and jpeg, and the encoder list is dummy, which is described as an encoder controller workflow sample, plus h264, h265, jpeg and vp8.

The asymmetry is meaningful. There are more decoders than encoders, and that reflects the hardware, since encoders on these chipsets are far more constrained than decoders. The h263, m2v and mpg4 parsers exist without matching encoders, and the dummy encoder is explicitly a sample rather than a real encoder.

Under mpp/hal/ is the Hardware Abstract Layer, the modules used in MPI. There is a common/ directory for shared HAL code, then rkdec/ for Rockchip hardware decoder register generation and rkenc/ for the encoder side, and finally vpu/ for the VPU register generation library.

And within those, the pattern is uniform and is the part that makes the tree feel generated rather than written by hand. Under rkdec/ there is an h264d, h265d, vp9d, av1d, avsd and avs2d, each described as generating the register file from the relevant syntax information. Under rkenc/ there is h264e, h265e and jpege, with the same description. And under vpu/ there is a second, larger set: av1d, h263d, h264e, jpegd, jpege, m2vd, mpg4d, vp8d and vp8e.

So there are two levels of register generation, and they overlap. The vpu/ tree is the older generation library, and mpp/legacy/ exists to generate a new libvpu that includes the old vpuapi path and the new mpp path, which is how the project carries its own history without breaking users of the earlier API.

What runs on top: the video processor, the API and the public headers

The layer above the codec machinery is where the library becomes useful to an application.

Under mpp/vproc/ are the video process modules, and there are three of them. iep is the image enhancement processor and iep2 is the image enhancement processor v2, which is the kind of pairing you see when a hardware block has been replaced by a newer revision and both are still in the tree. vdpp is the video post processor.

The public surface is at the top level, outside mpp/. The inc/ directory is the header file for external usage, including the platform header and the MPI header, so that is what an application includes. The repository listing confirms the shape with an inc/ directory, an osal/ directory for the operating system abstraction layer, and a mpp/ directory for the implementation. There is also a kmpp/ directory in the actual tree, which the README's directory diagram does not show, so it is a newer addition.

The MPI interface itself is described in the README as the Media Process Interface, and the diagram notes that the mpp/ directory holds the mpi function private implementation and the MPP infrastructure, with vpu_api as the private layer. So the older vpu_api naming is still present underneath.

Under mpp/test/ is the mpp internal video protocol unit test and demo, and the top level test/ directory is the mpp buffer and packet component unit test and the mpp/mpi/vpu_api demo. Two separate test locations is slightly untidy, but it reflects that the protocol level tests and the component level tests were written at different times by different hands.

The output side of the build is the out/ directory, the final release binary output directory, with bin/ for executables, inc/ for header file output and lib/ for library files. The pkgconfig/ directory in the actual tree is what makes those libraries consumable from a build system that asks pkg-config, which is the normal way to consume a C library on Linux.

The build/ directory in the tree holds the platform build directories, and the diagram lists cmake, android, linux, vc10-x86_64 and vc12-x86_64. The Visual Studio directories are historical, and the note in the README is explicit: Windows support is NOT maintained any more. So the vc10 and vc12 directories are archaeology, and the current build targets are cmake for cross platform, android and linux.

The Android.bp file at the top of the tree is the Android build system blueprint, which is what makes this library build as part of an Android platform build rather than only as a standalone CMake project. That is the more likely integration path for a Rockchip Android device, and it is a reminder that this is a vendor SDK that ships inside a product rather than a library you add to a project.

Chipset coverage, the VC1 exception, and where the sources live

The support matrix is stated as a list, and it is worth reading carefully because the version numbers in it are the whole scope of the library.

MPP supports all Rockchip chipsets now, including RK29XX, RK30XX and RK31XX; RK3288, RK3368 and RK3399; RK3228, RK3229, RK3228H and RK3328; RK3528 and RK3528A; RK3562; RK3566 and RK3568; RK3588; and the RV series, RV1108, RV1107, RV1109 and RV1126.

So the coverage runs from the original RK29 generation through to RK3588, and the RV prefix covers the automotive and embedded parts. That span is why the codebase has a legacy/ directory and two generations of register generation under vpu/ and rkdec/ and rkenc/.

The one format exception is stated separately. MPP supports all format hardware can support except VC1. So the codecs in the parser tree, av1, avs, avs2, h263, h264, h265, mpeg2, mpeg4, vp8, vp9 and jpeg, map onto what the hardware does, and VC1 is the one thing in the family that is not covered.

Then there are the source locations, and this is a detail that will confuse anyone who goes looking for the canonical tree. The official GitHub is https://github.com/rockchip-linux/mpp, and the develop branch is at https://github.com/HermanChen/mpp, with a develop mirror on Gitee at https://gitee.com/hermanchen82/mpp. So the development branch lives in a personal repository, and the official repository is not where the active work necessarily is. The default branch of the official repository is develop, which is consistent with the official tree tracking the personal one.

That arrangement is a normal pattern in vendor SDKs, where a maintainer keeps the working tree in their own space and pushes to the vendor namespace, and it is worth knowing before you file an issue or try to understand why a change appears in one place and not the other.

The commit message format is also specified, and it is worth following if you plan to contribute. Commit messages should be based on the Keep a Changelog format, which is a specific convention rather than a generic one, and the CHANGELOG.md file at the repository root is the artefact it produces.

The licence is recorded as unknown in the repository metadata, and there is a LICENSES/ directory at the top of the tree, which is the newer SPDX style location for licence files. For a library whose purpose is to be linked into a product, that is the file to read before you ship anything, and the presence of a SECURITY.md at the root is a sign that the project takes disclosure seriously.

Editorial conclusion

Rockchip MPP fits a developer building on a Rockchip board, an Android device or an embedded product where you need the hardware codecs rather than a software fallback, and who can work with a vendor tree whose abstraction is the chip register set rather than a general media API. It is the wrong choice if you need a portable media library, since the HAL is chip specific by construction, and the wrong choice if you need Windows, which the project states is no longer maintained. Before adopting, check the supported chipset list against the board you have, read the header include order rules because they are enforced by convention rather than by the compiler, and plan for the fact that the primary language is C with no stable release tags.

Frequently asked questions

Official sources

1. Issues
2. README
3. rockchip-linux/mpp on GitHub