mirror of
https://github.com/HermanChen/mpp.git
synced 2026-04-13 15:07:45 +00:00
Rockchip MPP(Media Process Platfrom)
- C 97.1%
- CMake 1.5%
- C++ 1%
- Shell 0.3%
- Batchfile 0.1%
bbd62a3ea3
Platform: All
Spec: h265
Error case:
In h265d_combine_frame, when a frame is output via the accumulated
ring buffer path (p->data_size > 0), output_size is never set
(remains 0). After p->data_size is cleared, the overlap processing
loop uses output_size as scan_pos, causing data_ptr[scan_pos + next]
to read before the buffer when next < 0. This results in SIGSEGV
when the ring buffer start is at a page boundary.
After fixing the overlap scan, a second issue was found: when next < 0,
carry-over bytes are copied to ring[0] for the next frame, but
h265d_spliter_sync unconditionally advances data_start by the released
frame's size. When carry-over data exists at ring[0] (data_start = 0)
and the released frame is at a different position, this skips past the
carry-over data, causing the next frame to lose its start code prefix.
This leads to "missing ref poc" decode errors starting from the affected
frame.
Error log:
backtrace:
#00 pc 0000000000167aa0 /system/lib64/libmpp.so (h265d_spliter_frame+2124)
#01 pc 00000000001667e4 /system/lib64/libmpp.so (h265d_prepare+392)
#02 pc 0000000000135edc /system/lib64/libmpp.so (mpp_dec_parser_thread+2524)
#03 pc 00000000000cb6a8 /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+208)
#04 pc 000000000006821c /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64)
refs: cur_frm 329 missing ref poc 330
Solution:
1. Fix output_size to old_data_size for correct overlap scan position.
2. Copy carry-over bytes to ring[0] before clearing ring state, using
tmp[16] stack buffer to handle ring wrap-around without memcpy overlap.
3. Restore data_size and write_pos after overlap scan.
4. Fix h265d_spliter_sync to only advance data_start when it matches
the released frame's position, preventing carry-over data loss.
Source: test_video_640x360.h265
Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
Change-Id: I7c394f5f429da90e26838dcfed20b8baed19429a
|
||
|---|---|---|
| build | ||
| debian | ||
| doc | ||
| inc | ||
| kmpp | ||
| LICENSES | ||
| mpp | ||
| osal | ||
| pkgconfig | ||
| test | ||
| tools | ||
| utils | ||
| .gitignore | ||
| Android.bp | ||
| CHANGELOG.md | ||
| CMakeLists.txt | ||
| readme.txt | ||
| SECURITY.md | ||
Media Process Platform (MPP) module directory description:
MPP : Media Process Platform
MPI : Media Process Interface
HAL : Hardware Abstract Layer
OSAL : Operation System Abstract Layer
Rules:
1. header file arrange rule
a. inc directory in each module folder is for external module usage.
b. module internal header file should be put along with the implement file.
c. header file should not contain any relative path or absolute path, all
include path should be keep in Makefile.
2. compiling system rule
a. for cross platform compiling use cmake as the compiling management system.
b. use cmake out-of-source build, final binary and library will be install to
out/ directory.
3. header file include order
a. MODULE_TAG
b. system header
c. osal header
d. module header
NOTE:
1. Windows support is NOT maintained any more.
2. Mpp support all rockchip chipset now including:
RK29XX/RK30XX/RK31XX
RK3288/RK3368/RK3399
RK3228/RK3229/RK3228H/RK3328
RK3528/RK3528A
RK3562
RK3566/RK3568
RK3588
RV1108/RV1107
RV1109/RV1126
3. Mpp support all format hardware can support except VC1.
4. you can get demo about mpp applied to linux and android.
Liunx : https://github.com/WainDing/mpp_linux_cpp
https://github.com/MUZLATAN
https://github.com/nyanmisaka
Android : https://github.com/c-xh/RKMediaCodecDemo
5. offical github: https://github.com/rockchip-linux/mpp
develop github: https://github.com/HermanChen/mpp
develop gitee : https://gitee.com/hermanchen82/mpp
6. Commit message format should base on https://keepachangelog.com/en/1.0.0/
More document can be found at http://opensource.rock-chips.com/wiki_Mpp
---- top
|
|----- build CMake out-of-source build directory
| |
| |----- cmake cmake script directory
| |
| |----- android android build directory
| |
| |----- linux linux build directory
| |
| |----- vc10-x86_64 visual studio 2010 on x86_64 build directory
| |
| |----- vc12-x86_64 visual studio 2013 on x86_64 build directory
|
|----- doc design documents of mpp
|
|----- inc header file for external usage, including
| platform header and mpi header
|
|----- mpp Media Process Platform : mpi function private
| | implement and mpp infrastructure (vpu_api
| | private layer)
| |
| |----- base base components including MppBuffer, MppFrame,
| | MppPacket, MppTask, MppMeta, etc.
| |
| |----- common video codec protocol syntax interface for both
| | codec parser and hal
| |
| |----- codec all video codec parser, convert stream to
| | | protocol structure
| | |
| | |----- inc header files provided by codec module for
| | | external usage
| | |
| | |----- dec
| | | |
| | | |----- av1 av1 parser
| | | |
| | | |----- avs avs parser
| | | |
| | | |----- avs2 avs2 parser
| | | |
| | | |----- h263 h263 parser
| | | |
| | | |----- h264 h264 parser
| | | |
| | | |----- h265 h265 parser
| | | |
| | | |----- m2v mpeg2 parser
| | | |
| | | |----- mpg4 mpeg4 parser
| | | |
| | | |----- vp8 vp8 parser
| | | |
| | | |----- vp9 vp9 parser
| | | |
| | | |----- jpeg jpeg parser
| | |
| | |----- enc
| | |
| | |----- dummy encoder controllor work flow sample
| | |
| | |----- h264 h264 encoder
| | |
| | |----- h265 h265 encoder
| | |
| | |----- jpeg jpeg encoder
| | |
| | |----- vp8 vp8 encoder
| |
| |----- hal Hardware Abstract Layer (HAL): modules used in mpi
| | |
| | |----- inc header files provided by hal for external usage
| | |
| | |----- common shared HAL code
| | |
| | |----- rkdec rockchip hardware decoder register generation
| | | |
| | | |----- h264d generate register file from H.264 syntax info
| | | |
| | | |----- h265d generate register file from H.265 syntax info
| | | |
| | | |----- vp9d generate register file from vp9 syntax info
| | | |
| | | |----- av1d generate register file from AV1 syntax info
| | | |
| | | |----- avsd generate register file from AVS syntax info
| | | |
| | | |----- avs2d generate register file from AVS2 syntax info
| | |
| | |----- rkenc rockchip hardware encoder register generation
| | | |
| | | |----- h264e generate register file from H.264 syntax info
| | | |
| | | |----- h265e generate register file from H.265 syntax info
| | | |
| | | |----- jpege generate register file from jpeg syntax info
| | |
| | |----- vpu vpu register generation library
| | |
| | |----- av1d generate register file from AV1 syntax info
| | |
| | |----- h263d generate register file from H.263 syntax info
| | |
| | |----- h264e generate register file from H.264 syntax info
| | |
| | |----- jpegd generate register file from jpeg syntax info
| | |
| | |----- jpege generate register file from jpeg syntax info
| | |
| | |----- m2vd generate register file from mpeg2 syntax info
| | |
| | |----- mpg4d generate register file from mpeg4 syntax info
| | |
| | |----- vp8d generate register file from vp8 syntax info
| | |
| | |----- vp8e generate register file from vp8 syntax info
| |
| |----- vproc video process modules
| | |
| | |----- iep image enhancement processor
| | |
| | |----- iep2 image enhancement processor v2
| | |
| | |----- vdpp video post processor
| |
| |----- legacy generate new libvpu to include old vpuapi path
| | and new mpp path
| |
| |----- test mpp internal video protocol unit test and demo
|
|----- test mpp buffer/packet component unit test and
| mpp/mpi/vpu_api demo
|
|----- out final release binary output directory
| |
| |----- bin executable binary file output directory
| |
| |----- inc header file output directory
| |
| |----- lib library file output directory
|
|----- osal Operation System Abstract Layer: abstract layer
| | for different operation system
| |
| |----- allocator supported allocator including Android ion and
| | Linux drm
| |
| |----- android google's android
| |
| |----- inc osal header file for mpp modules
| |
| |----- linux mainline linux kernel
| |
| |----- windows microsoft's windows
| |
| |----- test OASL unit test
|
|----- tools coding style format tools
|
|----- utils small util functions
Here is the mpp implement overall framework:
+---------------------------------------+
| |
| OpenMax / gstreamer / libva |
| |
+---------------------------------------+
+-------------------- MPP ----------------------+
| |
| +-------------------------+ +--------+ |
| | | | | |
| | MPI / MPP | | | |
| | buffer queue manage | | | |
| | | | | |
| +-------------------------+ | | |
| | | |
| +-------------------------+ | | |
| | | | | |
| | codec | | OSAL | |
| | decoder / encoder | | | |
| | | | | |
| +-------------------------+ | | |
| | | |
| +-----------+ +-----------+ | | |
| | | | | | | |
| | parser | | HAL | | | |
| | recoder | | reg_gen | | | |
| | | | | | | |
| +-----------+ +-----------+ +--------| |
| |
+-------------------- MPP ----------------------+
+---------------------------------------+
| |
| kernel |
| RK vcodec_service / v4l2 |
| |
+---------------------------------------+
Here is the Media Process Interface hierarchical structure
MpiPacket and MpiFrame is the stream I/O data structure.
And MpiBuffer encapsulates different buffer implement like Linux's dma-buf and
Android's ion.
This part is learned from ff.
+-------------------+
| |
| MPI |
| |
+---------+---------+
|
|
v
+---------+---------+
| |
+---+ ctx +---+
| | | |
| +-------------------+ |
| |
v v
+-------+-------+ +-------+-------+
| | | |
| packet | | frame |
| | | |
+---------------+ +-------+-------+
| |
| |
| |
| +---------------+ |
| | | |
+---->+ buffer +<----+
| |
+---------------+
Take H.264 deocder for example. Video stream will first queued by MPI/MPP layer,
MPP will send the stream to codec layer, codec layer parses the stream header
and generates a protocol standard output. This output will be send to HAL to
generate register file set and communicate with hardware. Hardware will complete
the task and resend information back. MPP notify codec by hardware result, codec
output decoded frame by display order.
MPI MPP decoder parser HAL
+ + + + +
| | | | |
| open context | | | |
+----------------> | | | |
| | | | |
| init | | | |
+----------------> | | | |
| | | | |
| | init | | |
| +----------------> | | |
| | | | |
| | | init | |
| | +----------------> | |
| | | | |
| | | | open |
| | +-----------------------------------> |
| | | | |
| decode | | | |
+----------------> | | | |
| | | | |
| | send_stream | | |
| +----------------> | | |
| | | | |
| | | parse_stream | |
| | +----------------> | |
| | | | |
| | | | reg generation |
| | +-----------------------------------> |
| | | | |
| | | | send_regs |
| | +-----------------------------------> |
| | | | |
| | | | wait_regs |
| | +-----------------------------------> |
| | | | |
| | | notify_hw_end | |
| | +----------------> | |
| | | | |
| | get_picture | | |
| +----------------> | | |
| | | | |
| | | get_picture | |
| | +----------------> | |
| | | | |
| flush | | | |
+----------------> | | | |
| | | | |
| | flush | | |
| +----------------> | | |
| | | | |
| | | reset | |
| | +----------------> | |
| | | | |
| close | | | |
+----------------> | | | |
| | | | |
| | close | | |
| +----------------> | | |
| | | | |
| | | close | |
| | +----------------> | |
| | | | |
| | | | close |
| | +-----------------------------------> |
+ + + + +
There are three memory usage modes that decoder can support:
Mode 1: Pure internal mode
In the mode user will NOT call MPP_DEC_SET_EXT_BUF_GROUP control to decoder.
Only call MPP_DEC_SET_INFO_CHANGE_READY to let decoder go on. Then decoder will
use create buffer internally and user need to release each frame they get.
Advantage:
Easy to use and get a demo quickly
Disadvantage:
1. The buffer from decoder may not be return before decoder is close.
So memory leak or crash may happen.
2. The decoder memory usage can not be control. Decoder is on a free-to-run
status and consume all memory it can get.
3. Difficult to implement zero-copy display path.
Mode 2: Half internal mode
This is the mode current mpi_dec_test code using. User need to create
MppBufferGroup according to the returned info change MppFrame.
User can use mpp_buffer_group_limit_config to limit decoder memory usage.
Advantage:
1. Easy to use
2. User can release MppBufferGroup after decoder is closed.
So memory can stay longer safely.
3. Can limit the memory usage by mpp_buffer_group_limit_config
Disadvantage:
1. The buffer limitation is still not accurate. Memory usage is 100% fixed.
2. Also difficult to implement zero-copy display path.
Mode 3: Pure external mode
In this mode use need to create empty MppBufferGroup and import memory from
external allocator by file handle.
On Android surfaceflinger will create buffer. Then mediaserver get file handle
from surfaceflinger and commit to decoder's MppBufferGroup.
Advantage:
1. Most efficient way for zero-copy display
Disadvantage:
1. Difficult to learn and use.
2. Player work flow may limit this usage.
3. May need external parser to get the correct buffer size for the external
allocator.
The required buffer size caculation:
hor_stride * ver_stride * 3 / 2 for pixel data
hor_stride * ver_stride / 2 for extra info
Total hor_stride * ver_stride * 2 will be enough.
For H.264/H.265 20+ buffers will be enough.
For other codec 10 buffers will be enough.