Rockchip Media Process Platform (MPP)

MPP decoders support three memory usage modes. Choosing the right one depends on your requirements for ease of use versus performance (zero-copy).

Mode 1: Pure Internal Mode

User does not call MPP_DEC_SET_EXT_BUF_GROUP. The decoder creates buffers internally.

• Pros: Easiest to use; quick to get a demo running.
• Cons: Potential memory leaks/crashes if buffers aren't released; memory usage is uncontrolled; difficult to implement zero-copy display.

Mode 2: Half Internal Mode

User creates an MppBufferGroup based on the returned info change MppFrame. This is the mode used in mpi_dec_test.

• Pros: Easy to use; memory can be safely released after the decoder closes; memory usage can be limited using mpp_buffer_group_limit_config.
• Cons: Buffer limitation is not 100% accurate; difficult to implement zero-copy display.

Mode 3: Pure External Mode

User creates an empty MppBufferGroup and imports memory from an external allocator via file handles (e.g., Android SurfaceFlinger).

• Pros: Most efficient way to achieve zero-copy display.
• Cons: High complexity; requires external parsers to determine correct buffer sizes for the allocator.

An MppFrame is the primary structure used to define 2D image buffer information, including the location and length of valid data. For decoders, MppFrame is the output structure containing pixel data, timestamps (pts, dts), and error information.

Key dimensions and strides:

• width: Horizontal pixel count.
• height: Vertical pixel count.
• hor_stride: Distance between adjacent rows in bytes.
• ver_stride: Interval between image components in number of rows.

Important status flags:

• pts: Present Time Stamp.
• dts: Decoding Time Stamp.
• eos: End Of Stream flag.
• errinfo: Error flag indicating decoding errors.
• discard: Discard flag; if set, the frame should not be displayed (e.g., due to broken reference relationships).
• info_change: If true, indicates a change in stream information (width, height, stride, or format). When this occurs, you must re-analyze and potentially resize your memory pool.
• fmt: MppFrameFormat representing color space and memory arrangement.
• buffer: The underlying MppBuffer containing the actual data.

/* Conceptual representation of MppFrame members */
struct MppFrame {
    RK_U32 width;
    RK_U32 height;
    RK_U32 hor_stride;
    RK_U32 ver_stride;
    RK_U32 mode;
    RK_U64 pts;
    RK_U64 dts;
    RK_U32 eos;
    RK_U32 errinfo;
    RK_U32 discard;
    size_t buf_size;
    RK_U32 info_change;
    MppFrameFormat fmt;
    MppFrameColorRange color_range;
    MppBuffer buffer;
};

MPP decoders support three modes for managing the memory used to store decoded pixel data. Choosing the right mode depends on your requirements for simplicity, memory control, and zero-copy performance.

Mode 1: Pure internal allocation mode

Memory is allocated directly by the MPP decoder. The user obtains the output image and must release it after use.

• How to use: Do not call MPP_DEC_SET_EXT_BUF_GROUP. Call MPP_DEC_SET_INFO_CHANGE_READY when the decoder reports an info change. The user must release each acquired frame's data directly.
• Pros: Simplest implementation; good for quick performance evaluation.
• Cons: Risk of memory leaks if not released before decoder destruction; no control over memory usage (can lead to exhaustion); difficult to achieve zero-copy display.

Mode 2: Semi-internal allocation mode (Default)

The user creates an MppBufferGroup based on the buf_size of the MppFrame returned by get_frame and configures it via MPP_DEC_SET_EXT_BUF_GROUP.

• How to use: Use mpp_buffer_group_limit_config to limit decoder memory usage.
• Pros: Simple and allows some memory usage limitations.
• Cons: Memory usage limits are not 100% accurate (usage fluctuates); difficult to achieve zero-copy display.

Mode 3: Pure external allocation mode

The decoder imports memory file handles (e.g., dmabuf, ion, or drm) from an external allocator provided by the user.

• How to use: Create an empty external mode MppBufferGroup, commit the external file handles (e.g., from Android's gralloc), and configure it via MPP_DEC_SET_EXT_BUF_GROUP.
• Pros: Enables easy zero-copy display by using memory directly from the external display system.
• Cons: Complex implementation; requires modifications to user program workflows.

The MPI uses specific data structures to handle the interaction between the application and the kernel driver. Most structures are accessed via void* handles and managed through mpp_xxx_set/get_xxx interfaces to ensure forward compatibility.

Key Abstractions:

• MppMem: Encapsulation of standard C malloc memory.
• MppBuffer: Encapsulation of dmabuf memory used for hardware interaction (supports ion/drm allocators).
• MppPacket: A one-dimensional buffer used primarily to represent bitstream data (e.g., encoded video packets).
• MppFrame: A two-dimensional buffer used primarily to represent image data (e.g., decoded video frames).

Typical Decoding Workflow:

1. Assign address and size to an MppPacket for the input bitstream.
2. Use the put_packet interface to input the bitstream.
3. Use the get_frame interface to retrieve the resulting MppFrame (image data).