When using latest 18 December 2017 libmpp.so on Android then HDR videos cease to work on SPMC 17 - http://download.semperpax.com/spmc/android-arm/SPMC-spmc-krypton-1f9a682-armeabi-v7a.apk
When I use mpp from before July 2017 then HDR videos can play correctly in HDR mode in SPMC 17.
Kodi 18 seem to still play HDR videos.
Please also include the latest Android kernel patches and other video codec lib files that work together with mpp to be able to have full compatibility with latest mpp for RK3328 Android 7.1 too in separate folder in mpp project.

In patch 3df2fb8 h264d_flush() was replaced by h264d_reset(),
it clears all flags including EOS and EOS flags are lost forever. EOS flags should be set after reset.

issue: mpi_dec_test doesn't output raw yuv data as expected

chip: RK3288 armv71
os: linux
decoder: mpi_dec_test doesn't output raw yuv data as expected
input file: 1.out.h264 was encoded by mpi_enc_test type 7 (only 1 frame)
code changlist: today (2018/09/11)

root@linaro-alip:/home/linaro# ./mpi_dec_test -i 1.out.h264 -o 1.out.yuv -w 1920 -h 1080 -t 7 -d 1
mpi_dec_test: cmd parse result:
mpi_dec_test: input file name: 1.out.h264
mpi_dec_test: output file name: 1.out.yuv
mpi_dec_test: width : 1920
mpi_dec_test: height : 1080
mpi_dec_test: type : 7
mpi_dec_test: debug flag : 1
mpi_dec_test: max frames : 0
mpi_dec_test: mpi_dec_test start
mpi_dec_test: input file size 102072
mpi_dec_test: mpi_dec_test decoder test start w 1920 h 1080 type 7
mpi: mpp version: 598cae3 author: Jacob Chen DEBIAN: update rules for release_20171218-2
hal_h264d_api: hal_h264d_init mpp_buffer_group_get_internal used ion In
mpp_rt: NOT found ion allocator
mpp_rt: found drm allocator
mpi: mpp_init leave ret 0
mpi: mpi_decode_put_packet enter ctx 0x672320 packet 0x6722c0
mpi: mpi_decode_put_packet leave ret 0
mpi: mpi_decode_get_frame enter ctx 0x672320 frame 0xbeb6b8b0
mpi: mpi_decode_get_frame leave ret 0
mpi: mpi_decode_put_packet enter ctx 0x672320 packet 0x6722c0
mpi: mpi_decode_put_packet leave ret 0
mpi: mpi_decode_get_frame enter ctx 0x672320 frame 0xbeb6b8b0
mpi: mpi_decode_get_frame leave ret 0
mpi: mpi_decode_put_packet enter ctx 0x672320 packet 0x6722c0
mpi: mpi_decode_put_packet leave ret 0
mpi: mpi_decode_get_frame enter ctx 0x672320 frame 0xbeb6b8b0
mpi: mpi_decode_get_frame leave ret 0
mpi: mpi_decode_put_packet enter ctx 0x672320 packet 0x6722c0
mpi: mpi_decode_put_packet leave ret 0
mpi: mpi_decode_get_frame enter ctx 0x672320 frame 0xbeb6b8b0
mpi: mpi_decode_get_frame leave ret 0
mpi: mpi_decode_put_packet enter ctx 0x672320 packet 0x6722c0
mpi: mpi_decode_put_packet leave ret 0
mpi: mpi_decode_get_frame enter ctx 0x672320 frame 0xbeb6b8b0
mpi: mpi_decode_get_frame leave ret 0
mpi: mpi_decode_put_packet enter ctx 0x672320 packet 0x6722c0
mpi: mpi_decode_put_packet leave ret 0
mpi: mpi_decode_get_frame enter ctx 0x672320 frame 0xbeb6b8b0
mpi: mpi_decode_get_frame leave ret 0
mpi: mpi_decode_put_packet enter ctx 0x672320 packet 0x6722c0
mpi: mpi_decode_put_packet leave ret 0
mpi: mpi_decode_get_frame enter ctx 0x672320 frame 0xbeb6b8b0
mpi: mpi_decode_get_frame leave ret 0
mpi: mpi_decode_put_packet enter ctx 0x672320 packet 0x6722c0
mpi: mpi_decode_put_packet leave ret 0
mpi: mpi_decode_get_frame enter ctx 0x672320 frame 0xbeb6b8b0
mpi: mpi_decode_get_frame leave ret 0
mpi: mpi_decode_put_packet enter ctx 0x672320 packet 0x6722c0
mpi: mpi_decode_put_packet leave ret 0
mpi: mpi_decode_get_frame enter ctx 0x672320 frame 0xbeb6b8b0
mpi: mpi_decode_get_frame leave ret 0
mpi: mpi_decode_put_packet enter ctx 0x672320 packet 0x6722c0
mpi: mpi_decode_put_packet leave ret 0
mpi: mpi_decode_get_frame enter ctx 0x672320 frame 0xbeb6b8b0
mpi: mpi_decode_get_frame leave ret 0
mpi: mpi_decode_put_packet enter ctx 0x672320 packet 0x6722c0
mpi: mpi_decode_put_packet leave ret 0
mpi: mpi_decode_get_frame enter ctx 0x672320 frame 0xbeb6b8b0
mpi: mpi_decode_get_frame leave ret 0
mpi: mpi_decode_put_packet enter ctx 0x672320 packet 0x6722c0
mpi: mpi_decode_put_packet leave ret 0
mpi: mpi_decode_get_frame enter ctx 0x672320 frame 0xbeb6b8b0
mpi: mpi_decode_get_frame leave ret 0
mpi: mpi_decode_put_packet enter ctx 0x672320 packet 0x6722c0
mpi: mpi_decode_put_packet leave ret 0
mpi: mpi_decode_get_frame enter ctx 0x672320 frame 0xbeb6b8b0
mpi: mpi_decode_get_frame leave ret 0
mpi: mpi_decode_put_packet enter ctx 0x672320 packet 0x6722c0
mpi: mpi_decode_put_packet leave ret 0
mpi: mpi_decode_get_frame enter ctx 0x672320 frame 0xbeb6b8b0
mpi: mpi_decode_get_frame leave ret 0
mpi: mpi_decode_put_packet enter ctx 0x672320 packet 0x6722c0
mpi: mpi_decode_put_packet leave ret 0
mpi: mpi_decode_get_frame enter ctx 0x672320 frame 0xbeb6b8b0
mpi: mpi_decode_get_frame leave ret 0
mpi: mpi_decode_put_packet enter ctx 0x672320 packet 0x6722c0
mpi: mpi_decode_put_packet leave ret 0
mpi: mpi_decode_get_frame enter ctx 0x672320 frame 0xbeb6b8b0
mpi: mpi_decode_get_frame leave ret 0
mpi: mpi_decode_put_packet enter ctx 0x672320 packet 0x6722c0
mpi: mpi_decode_put_packet leave ret 0
mpi: mpi_decode_get_frame enter ctx 0x672320 frame 0xbeb6b8b0
mpi: mpi_decode_get_frame leave ret 0
mpi: mpi_decode_put_packet enter ctx 0x672320 packet 0x6722c0
mpi: mpi_decode_put_packet leave ret 0
mpi: mpi_decode_get_frame enter ctx 0x672320 frame 0xbeb6b8b0
mpi: mpi_decode_get_frame leave ret 0
mpi: mpi_decode_put_packet enter ctx 0x672320 packet 0x6722c0
mpi: mpi_decode_put_packet leave ret 0
mpi: mpi_decode_get_frame enter ctx 0x672320 frame 0xbeb6b8b0
mpi: mpi_decode_get_frame leave ret 0
mpi: mpi_decode_put_packet enter ctx 0x672320 packet 0x6722c0
mpi: mpi_decode_put_packet leave ret 0
mpi: mpi_decode_get_frame enter ctx 0x672320 frame 0xbeb6b8b0
mpi: mpi_decode_get_frame leave ret 0
mpi: mpi_decode_put_packet enter ctx 0x672320 packet 0x6722c0
mpi: mpi_decode_put_packet leave ret 0
mpi: mpi_decode_get_frame enter ctx 0x672320 frame 0xbeb6b8b0
mpi: mpi_decode_get_frame leave ret 0
mpi: mpi_decode_put_packet enter ctx 0x672320 packet 0x6722c0
mpi: mpi_decode_put_packet leave ret 0
mpi: mpi_decode_get_frame enter ctx 0x672320 frame 0xbeb6b8b0
mpi: mpi_decode_get_frame leave ret 0
mpi: mpi_decode_put_packet enter ctx 0x672320 packet 0x6722c0
mpi: mpi_decode_put_packet leave ret 0
mpi: mpi_decode_get_frame enter ctx 0x672320 frame 0xbeb6b8b0
mpi: mpi_decode_get_frame leave ret 0
mpi: mpi_decode_put_packet enter ctx 0x672320 packet 0x6722c0
mpi: mpi_decode_put_packet leave ret 0
mpi: mpi_decode_get_frame enter ctx 0x672320 frame 0xbeb6b8b0
mpi: mpi_decode_get_frame leave ret 0
mpi_dec_test: found last packet
mpi: mpi_decode_put_packet enter ctx 0x672320 packet 0x6722c0
mpi: mpi_decode_put_packet leave ret 0
mpi: mpi_decode_get_frame enter ctx 0x672320 frame 0xbeb6b8b0
mpi: mpi_decode_get_frame leave ret 0
mpi_dec_test: decode_get_frame get frame 1
mpi_dec_test: found last frame
mpi: mpi_reset enter ctx 0x672320
mpi: mpi_reset leave ret 0
mpi: mpp_destroy enter ctx 0x672320
[75800.270282] rk-vcodec ff9a0000.vpu-service: closed
mpi: mpp_destroy leave ret 0
*** Error in `./mpi_dec_test': free(): invalid pointer: 0x00016c98 ***
Aborted
root@linaro-alip:/home/linaro#

Hello!

I am trying to use gstreamer EXTRA rockchip plugins rgaconvert . According to sources it requires /dev/video10 device, but in mine rk3328 there is no such device. Also I checked mpp sources and seems
mpp lib using /dev/rga, and I also don`t have such device.

What is proper way to use rgaconvert?

Hi

I wonder if a hardware based scaler is available in mpp. My use case is to decode a HD stream and then run some analysis on down scaled raw frame. I see that there is an abandoned ffmpeg repo here. Did it use hardware resizer in any way?

Thnx

I tried lots of different video samples of 4K@50hz or 4K@60hz (3840x2160) but none can play in that resolution on Android. Most of the time the videos don't open or they play in slow motion, slideshow in 1080p@60hz in Kodi 18 or SPMC.

4K@24/25/30fps all play correct in 4K and their correct frame-rate in Kodi 18/SPMC 17.6a2.

Test video not working, 4K 60fps - http://4ksamples.com/ses-astra-uhd-test-1-2160p-uhdtv/

It also fails this test video, 4K 50fps - https://forum.kodi.tv/showthread.php?tid=261768
The background of the video must be grey with lots of small white squares on the background.
It plays correct in RKMC that uses libstagefright and bypasses mpp but in Kodi 18, SPMC it shows vertical black and white bars and downscaled to 1080p and plays incorrect with auto frame-rate switching on.

Lots of .TS videos that are not mpeg2, are hevc or h264 in .TS files also don't play on Android.

Hello.

The code seems to be prepared to deal with paths with "_" and "-" in device path see https://github.com/rockchip-linux/mpp/blob/develop/osal/mpp_platform.cpp#L66
But there are many places with hardcoded variant (# find . -type f -exec grep -n 'vpu_service"' {} /dev/null ;):
./mpp/hal/worker/libvpu/vpu.c:49:static const char *name_vpu_service = "/dev/vpu_service";
./mpp/hal/worker/libvpu/vpu.c:217: fd = open("/dev/vpu_service", O_RDWR);
./osal/allocator/allocator_ion.c:197: "vpu_service",

TinkerOS (4.4.16) uses "-" variant and it is incompatible.

M.C>

I cannot build debian package ("DEB_BUILD_OPTIONS=nocheck debuild -i -us -uc -b -d -aarmhf") on native platform (not cross-build). CMakeCross.txt is missing (see https://github.com/rockchip-linux/mpp/blob/for_linux/debian/rules#L27). Other sources like libdrm-rockchip, libmali, gstreamer-rockchip works okay.

This patch works of course (for_linux branch):

diff --git a/debian/rules b/debian/rules
index 8f68a7c..eafbec3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -24,7 +24,6 @@ include /usr/share/dpkg/default.mk
 # This is example for Cmake (See http://bugs.debian.org/641051 )
 override_dh_auto_configure:
        dh_auto_configure -- \
-       -DCMAKE_TOOLCHAIN_FILE=/etc/dpkg-cross/cmake/CMakeCross.txt \
        -DCMAKE_BUILD_TYPE=Release \
        -DRKPLATFORM=ON \
        -DHAVE_DRM=ON

Hello.

There is explicit msleep() in https://github.com/rockchip-linux/mpp/blob/develop/mpp/mpp.cpp#L289
Can it be removed or moved to non MPP_POLL_BLOCK (cv wait) branch ?

Thanks, M.C>

Hello!

Does h.264/h.265 decoder supports Intra refresh?

程序在解码时到ret = mpi->decode_get_frame(ctx, &frame)在这里返回0，但是去不了frame，一读取frame，系统崩溃，frame返回为NULL，明明返回时0,成功，为何不能读取，

Do you have plan to add these decoders / encoders to ffmpeg?

MPP decoded video stream from WFD of APPLE's device, memory leak arise while APPLE's video resolution changed.

below is screenshot for this issue:

1. when try to "make" linux arm version mpp,i meet following error:

Linking CXX executable h265d_parser_test
../../../../librockchip_mpp.so.1: undefined reference to `allocator_drm'
collect2: error: ld returned 1 exit status
make[2]: *** [mpp/codec/dec/h265/test/h265d_parser_test] Error 1
make[1]: *** [mpp/codec/dec/h265/test/CMakeFiles/h265d_parser_test.dir/all] Error 2
make: *** [all] Error 2

2. when i execute 'nm librockchip_mpp.so.1',i can see 'allocator_drm'

0002494c t add_empty_nalu
U __aeabi_atexit@@CXXABI_ARM_1.3.3
U __aeabi_idiv@@GCC_3.5
U __aeabi_idivmod@@GCC_3.5
U __aeabi_l2f@@GCC_3.5
U __aeabi_ldivmod@@GCC_3.5
U __aeabi_uidiv@@GCC_3.5
U __aeabi_uidivmod@@GCC_3.5
U __aeabi_uldivmod@@GCC_3.5
U __aeabi_unwind_cpp_pr0@@GCC_3.5
U __aeabi_unwind_cpp_pr1@@GCC_3.5
U allocator_drm

3. where is wrong?

how to use mpp as a libva or vdpau backend?

LibreELEC/Kodi users are reporting crashes when trying to open some Tvheadend streams.

I was able to capture the following backtrace using a debug build:

Thread 1 (Thread 0xdbe86370 (LWP 823)):
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0xf55b9150 in __GI_abort () at abort.c:79
#2  0xf494405c in mpp_buf_slot_get_prop (slots=0xf03f4c60, index=index@entry=-1, type=type@entry=SLOT_FRAME_PTR, val=0xdbe85b8c, val@entry=0xdbe85b84) at ../mpp/base/mpp_buf_slot.cpp:875
#3  0xf48f4b14 in check_ref_dbp_err (p_Dec=p_Dec@entry=0xf1add5c0, pref=<optimized out>, active_refs=active_refs@entry=2) at ../mpp/codec/dec/h264/h264d_init.c:1391
#4  0xf48f6ecc in check_refer_picture_lists (currSlice=0xf03f8270) at ../mpp/codec/dec/h264/h264d_init.c:1422
#5  init_picture (currSlice=0xf03f8270) at ../mpp/codec/dec/h264/h264d_init.c:1970
#6  0xf48ea69c in parse_loop (p_Dec=p_Dec@entry=0xf1add5c0) at ../mpp/codec/dec/h264/h264d_parse.c:907
#7  0xf48e8050 in h264d_parse (decoder=0xf1add5c0, in_task=0xdbe85cf0) at ../mpp/codec/dec/h264/h264d_api.c:599
#8  0xf48e150c in try_proc_dec_task (task=0xdbe85ccc, mpp=0xf0362e88) at ../mpp/codec/mpp_dec.cpp:608
#9  mpp_dec_parser_thread (data=0xf0362e88) at ../mpp/codec/mpp_dec.cpp:783
#10 0xf75c4314 in start_thread (arg=0xdbe86370) at pthread_create.c:486
#11 0xf5670498 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:73 from /usr/lib/libc.so.6

Looks like index=index@entry=-1 is the culprit.

Using the following patch seems to mitigate the crash in mpp, please validate this workaround.

diff --git a/mpp/codec/dec/h264/h264d_init.c b/mpp/codec/dec/h264/h264d_init.c
--- a/mpp/codec/dec/h264/h264d_init.c
+++ b/mpp/codec/dec/h264/h264d_init.c
@@ -1387,7 +1387,11 @@ static RK_U32 check_ref_dbp_err(H264_DecCtx_t *p_Dec, H264_RefPicInfo_t *pref, R
     for (i = 0; i < MAX_REF_SIZE; i++) {
         if (pref[i].valid) {
             MppFrame mframe = NULL;
-            RK_U32 slot_idx = p_Dec->dpb_info[pref[i].dpb_idx].slot_index;
+            RK_S32 slot_idx = p_Dec->dpb_info[pref[i].dpb_idx].slot_index;
+            if (slot_idx < 0) {
+                dpb_error_flag |= 1;
+                break;
+            }
             mpp_buf_slot_get_prop(p_Dec->frame_slots, slot_idx, SLOT_FRAME_PTR, &mframe);
             if (mframe) {
                 if (i < active_refs) {

Hi

Please confirm if md_buf array in https://github.com/rockchip-linux/mpp/blob/develop/test/mpi_enc_test.c will be filled with motion vector information after encoding a given frame (h.264 of course ).

Is this buffer exposed up above in mpph264enc gstreamer plugin? Is there any other way I could get this data in gstreamer (sink or shared memory transfer from driver etc.,)

Thnx

Hello!

I have rk3328 system, I built all related sources from rockchip-linux repos, rockchip kernel.
I can decode video via gst-launch-1.0 util using kmssink (my system is without X/Wayland).
But video is overlaying in fullscreen mode.

What is proper way to scale video to some smaller size and show on the part of screen?
Also I built rk-qt-video repo and testing player example, that somehow suppose to show video as I want.
But it is not working properly.

# ./player /root/test2.mp4
mpi: mpp version: Without VCS, under bleeding
QMetaObject::indexOfSignal: signal setFullScreen(bool) from QVideoWidget redefined in VideoWidget
mpp_buffer: mpp_group 0x7f68009a40 tag unknown caller gst_mpp_allocator_drm_buf mode external type ion deinit with 4177920 bytes not released
mpp_buffer:
dumping buffer group 0x7f68009a40 id 3
mpp_buffer: mode external
mpp_buffer: type ion
mpp_buffer: limit size 0 count 0
mpp_buffer: used buffer count 1
mpp_buffer: buffer 0x7f6800c460 fd   74 size    4177920 ref_count   1 discard 0 caller gst_mpp_allocator_drm_buf
mpp_buffer: unused buffer count 0
[ 2109.317484] rk-vcodec ff360000.rkvdec: closed
Error: "Internal data stream error."
QMetaObject::indexOfSignal: signal setFullScreen(bool) from QVideoWidget redefined in VideoWidget
mpi: mpp version: Without VCS, under bleeding
QMetaObject::indexOfSignal: signal setFullScreen(bool) from QVideoWidget redefined in VideoWidget
[ 2114.159702] rockchip-pm-domain ff100000.syscon:power-controller: failed to get ack on domain 'pd_video', val=0x10040
^C[ 2116.173425] rk-vcodec ff360000.rkvdec: closed
# ./player /root/test.mp4
mpi: mpp version: Without VCS, under bleeding
QMetaObject::indexOfSignal: signal setFullScreen(bool) from QVideoWidget redefined in VideoWidget
Warning: "A lot of buffers are being dropped."
Warning: "A lot of buffers are being dropped."
[ 2138.896773] rk-vcodec ff360000.rkvdec: closed
QMetaObject::indexOfSignal: signal setFullScreen(bool) from QVideoWidget redefined in VideoWidget
[ 2142.783737] rockchip-pm-domain ff100000.syscon:power-controller: failed to get ack on domain 'pd_video', val=0x10040

Video is not playing, I can see only first frame in all combinations FullScreen EGL/DRM or not FullScreen EGL/DRM modes.

The following line appears to incorrectly calculate the size:
https://github.com/rockchip-linux/mpp/blob/release/osal/allocator/allocator_drm.c#L189

dmcb.size = dmcb.width * dmcb.bpp;
should probably be:
dmcb.size = dmcb.width * (dmcb.bpp / 8);

bpp=bits per pixel. there are 8bits in a byte. size is in bytes.

Hello.
TinkerOS identifies itself as "uname -r -v -m" -> "4.4.16 #25 SMP Thu Feb 23 17:59:58 CST 2017 armv7l". "armv7l" is not prepared in CMakeLists.txt. I do not known the right solution, but following patch works for me:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index c3aa78c..68a0c96 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -92,6 +92,11 @@ elseif(${SYSPROC} STREQUAL "armv7-a")
     set(ARM true)
     set(ARMEABI_V7A true)
     add_definitions(-DARCH_ARM=1 -DDHAVE_ARMV7=1)
+elseif(${SYSPROC} STREQUAL "armv7l")
+    message(STATUS "Detected ARMv7 system processor")
+    set(ARM true)
+    set(ARMEABI_V7L true)
+    add_definitions(-DARCH_ARM=1 -DDHAVE_ARMV7=1)
 elseif(${SYSPROC} STREQUAL "armv7-a_hardfp")
     message(STATUS "Detected ARMv7 system processor")
     set(ARM true)
@@ -173,6 +178,8 @@ if(GCC)
             add_definitions(-march=armv6 -mfloat-abi=hard -mfpu=vfp)
         elseif(ARMEABI_V7A)
             add_definitions(-march=armv7-a -mfloat-abi=softfp -mfpu=neon)
+        elseif(ARMEABI_V7L)
+            add_definitions(-march=armv7-a -mfloat-abi=hard -mfpu=neon -fPIC)
         elseif(ARMEABI_V7A_HARDFP)
             add_definitions(-march=armv7-a -mfloat-abi=hard -mfpu=neon)
         endif()

(see http://tinkerboarding.co.uk/forum/showthread.php?tid=51 )
Can you resolve right support ?

Thanks, M.C>

Hello,
I have this erros with mpp compilation on a Tinkerboard

Scanning dependencies of target rockchip_mpp_static
[ 71%] Building CXX object mpp/CMakeFiles/rockchip_mpp_static.dir/mpp_impl.cpp.o
[ 71%] Building CXX object mpp/CMakeFiles/rockchip_mpp_static.dir/mpp.cpp.o
[ 71%] Building CXX object mpp/CMakeFiles/rockchip_mpp_static.dir/mpp_info.cpp.o
[ 72%] Building CXX object mpp/CMakeFiles/rockchip_mpp_static.dir/mpi.cpp.o
/home/tinker/mpp/mpp/mpp_impl.cpp: In function ‘MPP_RET mpp_dump_init(MppDumpInf o*, MppCtxType)’:
/home/tinker/mpp/mpp/mpp_impl.cpp:40:34: error: ‘memset’ was not declared in thi s scope
memset(info, 0, sizeof(*info));
^
mpp/CMakeFiles/rockchip_mpp_static.dir/build.make:110: recipe for target 'mpp/CM akeFiles/rockchip_mpp_static.dir/mpp_impl.cpp.o' failed
make[2]: *** [mpp/CMakeFiles/rockchip_mpp_static.dir/mpp_impl.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
CMakeFiles/Makefile2:772: recipe for target 'mpp/CMakeFiles/rockchip_mpp_static. dir/all' failed
make[1]: *** [mpp/CMakeFiles/rockchip_mpp_static.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2

Hello,
the decoded frames are in wrong order. PresentationTimeStamp are ordered but the frames not. The picture on the screen jumps forward and backward. The packet from stream (decoder in) are not in the order for presentation. There is an tutorial that explain that.
This are the pts in and out decoder:

CodecVideoDecode: pts decoder in 1476218481 pts decoder out 1476186081
CodecVideoDecode: pts decoder in 1476211281 pts decoder out 1476187881
CodecVideoDecode: pts decoder in 1476205881 pts decoder out 1476189681
CodecVideoDecode: pts decoder in 1476207681 pts decoder out 1476191481
CodecVideoDecode: pts decoder in 1476209481 pts decoder out 1476193281
CodecVideoDecode: pts decoder in 1476213081 pts decoder out 1476195081
CodecVideoDecode: pts decoder in 1476214881 pts decoder out 1476196881
CodecVideoDecode: pts decoder in 1476216681 pts decoder out 1476198681
CodecVideoDecode: pts decoder in 1476232881 pts decoder out 1476200481
CodecVideoDecode: pts decoder in 1476225681 pts decoder out 1476202281
CodecVideoDecode: pts decoder in 1476220281 pts decoder out 1476204081
CodecVideoDecode: pts decoder in 1476222081 pts decoder out 1476205881

The frames should be sorted by pts not sorted the pts to the frames in incoming order. Or leave the pts to the decoded frame. Then can sorting in user space.

Best regards zillevdr

When I test mpi_enc_test -i small.yuv -w 560 -h 320 -f 4 -t 7 -d 3 -o output.mp4
I've got that error in output log:
mpp_dev_ioctl:545: unknow mpp ioctl cmd 40086c03
mpp_dev_ioctl:545: unknow mpp ioctl cmd 40086c04
I run mpp with RK3328 on rock64 board.
I've used the newest code mpp version.

在3328-CC進行測試
mpi_dec_test test.264->test.raw正常
mpi_enc_test test.raw->new.264一直會報length 0

是什麼問題？

I'm trying to get mpeg4 decoding running on a RK3188 via gstreamer. Without luck, though.

• mpp compiles fine
• /dev/vpu_service is present
• gstreamer mppvideodec compiles fine

Stream run fine through the decoder, but no frames are produced. Is mpp mpeg4 decoding known to work on RK3188?

What does the following mean. What parts are supported and what parts are not?

2. Current MPP fully support chipset RK3228/RK3229/RK3399/RK3328/RV1108.
   Old chipset like RK29xx/RK30xx/RK31XX/RK3288/RK3368 is partly supported due
   to lack of some hardware register generation module.

cmake = 3.52
在rk3399 debian文件系统中编译
注释掉

This is example for Cmake (See http://bugs.debian.org/641051 )

override_dh_auto_configure:
dh_auto_configure --
// -DCMAKE_TOOLCHAIN_FILE=/etc/dpkg-cross/cmake/CMakeCross.txt
-DCMAKE_BUILD_TYPE=Release
-DRKPLATFORM=ON
-DHAVE_DRM=ON
-DARM_MIX_32_64=ON

DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -rfakeroot -b -d -uc -us -aarmhf

最后出现

dh_install: cannot run debian/librockchip-mpp-dev.install: No such file or directory
debian/rules:21: recipe for target 'binary' failed
make: *** [binary] Error 2
该怎么解决呢？？？

RK3399 spec states that it supports hardware VP8 encoding but I didn't find relevant code in MPP release branch. Is there any plans to add it and if yes when can it be expected? If there are no plans - what another stack can be used for VP8 encoding on RK3399?

Thank you

I am interested to add mpp to yocto for a sofia-3gr target.

A mpp recipe for yocto is already exisiting here:
https://git.phytec.de/meta-phytec/tree/recipes-multimedia/rockchip-mpp

This recipe that targets rk3288 seems to use very few CMAKE options (RKPLATFORM=ON & HAVE_DRM=ON)

I would like to know if these options are still valid for a sofia-3gr target or some other options must be used

According these files
https://github.com/rockchip-linux/mpp/blob/release/build/linux/x86/sofia-3gr
RKPLATFORM must be ON and SOFIA_3GR_LINUX must be set

Could you confirm?

Regards

As I am having performance issues with my experimental usage of MPP in our in-house app, I have started to replicate what I did in the form of an example, by extending the official decoder test, in https://github.com/BladeGroup/mpp - in the hope that a complete example may also help others to gain time (when it is correct, obviously ;).

This example is slightly different from our app (where SDL already initializes a lot of graphics stuff), and I went into DRI2 initialization manually, but I'm apparently missing something, as drmPrimeFDToHandle() is still failing with EPERM on all frames. Use "-m 2" to activate display using DRI2.

Hello.
There is problems with HDR metadata decodings:

• problem 1 - colorspace error

## TESTING ENVIRONMENT
## kernel https://github.com/rockchip-linux/kernel.git (commit 50b2d1bb0f6455db61391ef94b813e53bf0d6986)
## + minimum patches from https://github.com/Kwiboo/linux-rockchip.git to get video working
## 	clk: rockchip: fix round rate
## 	phy: rockchip-inno-hdmi-phy: add vesa dmt pixel clocks
## 	rockchip: vop: force skip lines if image too big
##    ...
## mpp/drm from https://launchpad.net/~ayufan/+archive/ubuntu/rock64-ppa
##	mpp 	1.4.0-1ayufan3 or today "git clone" (commit 1c7586932cbdd4bcc30f599f303c4a3a03061201)
##	libdrm 	2.4.89-1ayufan1 
 
# ffmpeg -i "LG Chess 4K Demo.mp4" -c:v copy -an -bsf:v hevc_mp4toannexb 2k60hdr.hevc

### CODE sniplet:
    // compute HDR metadata
    MppFrameColorTransferCharacteristic colorTrc = mpp_frame_get_color_trc(frame);
    MppFrameColorPrimaries colorPri = mpp_frame_get_color_primaries(frame);
    MppFrameColorSpace colorSpc = mpp_frame_get_colorspace(frame);
    printf("COLOR primaries %d transfer %d space %d\n", colorPri, colorTrc, colorSpc);

### OUTPUT for 2k60hdr.hevc:
COLOR primaries 9 transfer 16 space 0

# colorPri(9) = MPP_FRAME_PRI_BT2020 = OK 
# colorTrc(16) = MPP_FRAME_TRC_SMPTEST2084 = OK
# colorSpc(0) = MPP_FRAME_SPC_RGB = ERROR !!! (should be *BT2020*)

• problem 2 - HDR_HLG not recognized

# ffmpeg -i "LG Cymatic Jazz 4K Demo.ts" -c:v copy -an -bsf:v hevc_mp4toannexb 2k60hdr_hlg.hevc

### OUTPUT for 2k60hdr_hlg.hevc:
COLOR primaries 9 transfer 14 space 0

# colorPri(9) = MPP_FRAME_PRI_BT2020 = OK 
# colorTrc(16) = MPP_FRAME_TRC_BT2020_10 = ERROR (should be MPP_FRAME_TRC_ARIB_STD_B67)
# colorSpc(0) = MPP_FRAME_SPC_RGB = ERROR (should be *BT2020*)

If DRM buffer type is used the program getting asserts on ION buffer service.
https://github.com/rockchip-linux/mpp/blob/develop/mpp/base/mpp_buffer_impl.cpp#L641
The code should return for all other types than MPP_BUFFER_TYPE_ION.

根据 MPP开发参考_v0.3 编译及运行：
[root@rockchip:~]# mpi_dec_test -t 7 -i /root/Tennis1080p.h264 -n 10
mpi_dec_test: cmd parse result:
mpi_dec_test: input file name: /root/Tennis1080p.h264
mpi_dec_test: output file name:
mpi_dec_test: width : 0
mpi_dec_test: height : 0
mpi_dec_test: type : 7
mpi_dec_test: debug flag : 0
mpi_dec_test: max frames : 10
mpi_dec_test: mpi_dec_test start
mpi_dec_test: input file size 10786528
mpi_dec_test: mpi_dec_test decoder test start w 0 h 0 type 7
mpi: mpp version: Without VCS info
hal_h264d_api: Assertion vcodec_type & ((0x00000200) | (0x00000001) | (0x00000002)) failed at hal_h264d_init:119
hal_h264d_api: hal_h264d_init hard mode error, value=0
hal_h264d_api: Assertion 0 failed at hal_h264d_init:169
mpp_device: mpp_device_init failed to find device for coding 7 type 0
hal_h264d_api: hal_h264d_init mpp_buffer_group_get_internal used ion In
mpp_rt: NOT found ion allocator
mpp_rt: found drm allocator
Segmentation fault

Please add aarch64 options for gcc.

I was trying to build mpp for RK1108, my arm.linux.cross.cmake just like following
_cmake_minimum_required( VERSION 2.6.3 )

SET(CMAKE_SYSTEM_NAME Linux)
SET(CMAKE_C_COMPILER "arm-linux-gcc")
SET(CMAKE_CXX_COMPILER "arm-linux-g++")
SET(CMAKE_SYSTEM_PROCESSOR "armv7-a")

add_definitions(-fPIC)
add_definitions(-DARMLINUX)
add_definitions(-D__gnu_linux__)_

when make the source code I came across errors like below...Did I do something wrong?

[ 70%] Building CXX object mpp/CMakeFiles/rockchip_mpp.dir/mpi.cpp.o
Linking CXX shared library librockchip_mpp.so
arm-rkcvr-linux-uclibcgnueabihf/bin/ld: error: librockchip_mpp.so.0 uses VFP register arguments, CMakeFiles/rockchip_mpp.dir/mpp_info.cpp.o does not
arm-rkcvr-linux-uclibcgnueabihf/bin/ld: failed to merge target specific data of file CMakeFiles/rockchip_mpp.dir/mpp_info.cpp.o
arm-rkcvr-linux-uclibcgnueabihf/bin/ld: error: librockchip_mpp.so.0 uses VFP register arguments, CMakeFiles/rockchip_mpp.dir/mpp.cpp.o does not
arm-rkcvr-linux-uclibcgnueabihf/bin/ld: failed to merge target specific data of file CMakeFiles/rockchip_mpp.dir/mpp.cpp.o
:
:
:
arm-rkcvr-linux-uclibcgnueabihf/bin/ld: error: librockchip_mpp.so.0 uses VFP register arguments, vproc/iep/libvproc_iep.a(iep.cpp.o) does not
arm-rkcvr-linux-uclibcgnueabihf/bin/ld: failed to merge target specific data of file vproc/iep/libvproc_iep.a(iep.cpp.o)

I want to implement a zero-copy EGL/GLES h264 player, it looks like I should use pure external mode.
Could your team provide a sample for demonstrating how to use "pure external mode"?
Thanks.

Hello,

I am porting MPP Framework in linux kernel 3.0.36.
and my AP is RK 3188.
I know MPP does not support linux kernel 3.0.36.
but, I made some changes and it works a little bit.

when i encode H.264, I see an unknown lines in the video file.
please check the link below.
screenshot

and, when the image is not move, it is fine.
screenshot

The link below is actually encoded video.
movie

I don't know where to look in this case.

Please give me a hint.

Thank you.

On Android, mpp don't support 10-bit H264 even if limitation was removed in Kodi 18.
https://github.com/xbmc/xbmc/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/Video/DVDVideoCodecAndroidMediaCodec.cpp#L470-L475
It plays with MediaCodec instead of ffmpeg if limitation is removed but still in 8-bit not 10-bit h264 with lots of color banding.

RK3328有支持H265硬編碼
有相關的源碼嗎？

Since the last additions on the git, it is impossible for me to compile mpp and I can not understand the error.

My operating system is Armbian Debian Stretch Kernel 4.4.120-rockchip.

Here is the error:

Scanning dependencies of target vproc_rga
[ 75%] Building CXX object mpp/vproc/rga/CMakeFiles/vproc_rga.dir/rga.cpp.o
/home/tinker/mpp/mpp/vproc/rga/rga.cpp: In function ‘MPP_RET rga_deinit(RgaCtx)’:
/home/tinker/mpp/mpp/vproc/rga/rga.cpp:131:27: error: ‘close’ was not declared in this scope
close(impl->rga_fd);
^
mpp/vproc/rga/CMakeFiles/vproc_rga.dir/build.make:62: recipe for target 'mpp/vproc/rga/CMakeFiles/vproc_rga.dir/rga.cpp.o' failed
make[2]: *** [mpp/vproc/rga/CMakeFiles/vproc_rga.dir/rga.cpp.o] Error 1
CMakeFiles/Makefile2:1997: recipe for target 'mpp/vproc/rga/CMakeFiles/vproc_rga.dir/all' failed
make[1]: *** [mpp/vproc/rga/CMakeFiles/vproc_rga.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2

Hi

It's not possible to play 10-bit H264 in Kodi 18 on Nougat anymore if using mpp after April 2018 on RK3328, RK3229.

mpp_dec_parser_thread的线程堆栈：
#0 0x0000007b3ad3ccec in syscall () from target:/system/lib64/libc.so
#1 0x0000007b3ad88e7c in pthread_cond_wait () from target:/system/lib64/libc.so
#2 0x0000007b3af851e8 in Condition::wait(Mutex&) () from target:/system/lib64/libmpp.so
#3 0x0000007b3af85210 in MppMutexCond::wait() () from target:/system/lib64/libmpp.so
#4 0x0000007b3af852f4 in MppThread::wait(MppThreadSignal_e) () from target:/system/lib64/libmpp.so
#5 0x0000007b3af88a80 in mpp_dec_parser_thread () from target:/system/lib64/libmpp.so
#6 0x0000007b3ad8974c in __pthread_start(void*) () from target:/system/lib64/libc.so
#7 0x0000007b3ad3ea80 in __start_thread () from target:/system/lib64/libc.so
#8 0x0000000000000000 in ?? ()

mpp_dec_hal_thread的堆栈：
#0 0x0000007b3ad3ccec in syscall () from target:/system/lib64/libc.so
#1 0x0000007b3ad88e7c in pthread_cond_wait () from target:/system/lib64/libc.so
#2 0x0000007b3af851e8 in Condition::wait(Mutex&) () from target:/system/lib64/libmpp.so
#3 0x0000007b3af85210 in MppMutexCond::wait() () from target:/system/lib64/libmpp.so
#4 0x0000007b3af852f4 in MppThread::wait(MppThreadSignal_e) () from target:/system/lib64/libmpp.so
#5 0x0000007b3af88d78 in mpp_dec_hal_thread () from target:/system/lib64/libmpp.so
#6 0x0000007b3ad8974c in __pthread_start(void*) () from target:/system/lib64/libc.so
#7 0x0000007b3ad3ea80 in __start_thread () from target:/system/lib64/libc.so
#8 0x0000000000000000 in ?? ()
送码流的线程日志信息：
01-01 16:02:08.261 7257 7258 D Player.Binder.Server.WFD: PlayerBinderServerWFD::onTransact(2) 16
01-01 16:02:08.261 7257 7258 I Player.Binder.Server.WFD: m_nATimestamp:3068719077885, m_nVTimestamp:3068719078185, , m_nLastFrameTimestamp:57728224, nCurTimestamp:57728261, m_nTimestampBase:3068719078185
01-01 16:02:08.261 7257 7258 I Player.Binder.Server.WFD: emMediaCodecID:2, emMediaSource:1, emMediaType:0, emStreamID:12,uPresentTimestamp:87210045, uReserve:0
01-01 16:02:08.261 7257 7258 D Player.Binder.Server.WFD: device/ruijie/player/./Player_Binder_Server.cpp:1506, uFrameLen:A8E-2702
01-01 16:02:08.261 7257 7258 I Player.Binder.Server.WFD: 00
01-01 16:02:08.261 7257 7258 I Player.Binder.Server.WFD: 00
01-01 16:02:08.261 7257 7258 I Player.Binder.Server.WFD: 01
01-01 16:02:08.261 7257 7258 I Player.Binder.Server.WFD: 21
01-01 16:02:08.261 7257 7258 I Player.Binder.Server.WFD: E4
01-01 16:02:08.261 7257 7258 E Player.Binder.Server.WFD: device/ruijie/player/./Player_Binder_Server.cpp:1698, it failed to get video time statistics node
01-01 16:02:08.261 7257 7258 I Player.Binder.Server.WFD: device/ruijie/player/./Player_Binder_Server.cpp:1713, nIsSPSorPPS:0, uPresentTimestamp:(before conversion:87210045-after conversion:3068719078236)
01-01 16:02:08.276 7257 7258 E VIDEO CODEC: device/ruijie/player/./Player_Video_Codec.cpp:937 it fail to put packet to mpp decoder(error code = -1012)
01-01 16:02:08.276 7257 7258 E Player.Binder.Server.WFD: device/ruijie/player/./Player_Binder_Server.cpp:1737, video decoder put Packet(seq:13782) fail

获取码流线程的日志提示信息：
01-01 15:49:35.442 7257 7271 D Player.Binder.Server.WFD: device/ruijie/player/./Player_Binder_Server.cpp:303, stLastMppFrame(0x0)
01-01 15:49:35.509 7257 7271 D VIDEO CODEC: decode_get_frame failed too much time
01-01 15:49:35.509 7257 7271 E VIDEO CODEC: decode_get_frame failed ret -8
01-01 15:49:35.509 7257 7271 D Player.Binder.Server.WFD: device/ruijie/player/./Player_Binder_Server.cpp:303, stLastMppFrame(0x0)
01-01 15:49:35.575 7257 7271 D VIDEO CODEC: decode_get_frame failed too much time
01-01 15:49:35.575 7257 7271 E VIDEO CODEC: decode_get_frame failed ret -8
01-01 15:49:35.575 7257 7271 D Player.Binder.Server.WFD: device/ruijie/player/./Player_Binder_Server.cpp:303, stLastMppFrame(0x0)

1、设置输出超时时
pParam = &nBlockTimeout;
stRet = m_pMppApi->control(m_stMppCtx, MPP_SET_OUTPUT_BLOCK_TIMEOUT, pParam);
if (MPP_OK != stRet) {
ALOGE("%s:%d it failed to set blocking mode on MPI (code = %d)\n",
FILE, LINE, stRet);
goto ERROR_EXIT;
}
发现：mpp_dec_parser_thread在等待一个消息：
if (check_task_wait(dec, &task)) {
mpp_timer_start(dec->timers[DEC_PRS_WAIT]);
parser->wait();
mpp_timer_pause(dec->timers[DEC_PRS_WAIT]);
}

mpp_dec_parser_thread不工作时，check_task_wait,里面的相关参数（十进制）：
notify:2279178328;last_wait:135, curr_wait:1, wait_chg:0

2、不设置输出超时时
check_task_wait的最后一条打印消息：
Line 15096: 0x7d24ae6100 last_wait:00000000 -> curr_wait:00004000 [wait_chg:00000000] notify 00000080 -> wait
mpp_dec_notify的状态打印：
Line 15101: 0x7d24ae6100 status 00004000 notify 00000000 signal, old_flag:00000000
Line 15106: 0x7d24ae6100 status 00004000 notify 00000001 signal, old_flag:00000001
Line 15117: 0x7d24ae6100 status 00004000 notify 00000001 signal, old_flag:00000001
Line 15128: 0x7d24ae6100 status 00004000 notify 00000001 signal, old_flag:00000001
Line 15139: 0x7d24ae6100 status 00004000 notify 00000001 signal, old_flag:00000001
Line 15150: 0x7d24ae6100 status 00004000 notify 00000001 signal, old_flag:00000001
Line 15164: 0x7d24ae6100 status 00004000 notify 00000001 signal, old_flag:00000001
Line 15175: 0x7d24ae6100 status 00004000 notify 00000001 signal, old_flag:00000001

My device is a SCISHION V88 Mini III ( RK3328 ) ( procedure : https://forum.armbian.com/topic/6658-rk3328-scishion-v88-piano-and-v88-mini-iii-tv-boxes/ ) so 4.4.132 Ubuntu 18.04.1 LTS
I have the vpu device
root@rock64:~# ls -l /dev/ | grep vpu
crw-rw-rw- 1 root video 247, 0 Jul 26 09:08 vpu_service

With this version i have compiled last ffmpeg
When i launch ffmpeg with h264_rkmpp i have allways this error (all video file)

Impossible to convert between the formats supported by the filter 'Parsed_null_0' and the filter 'auto_scaler_0'
Error reinitializing filters!
Failed to inject frame into filter network: Function not implemented

how i have compiled ::
sudo apt-get update -qq && sudo apt-get -y install autoconf automake build-essential cmake git-core libass-dev libfreetype6-dev libsdl2-dev libtool libva-dev libvdpau-dev libvorbis-dev libxcb1-dev libxcb-shm0-dev libxcb-xfixes0-dev pkg-config texinfo wget zlib1g-dev yasm libx264-dev libx265-dev libnuma-dev libvpx-dev libfdk-aac-dev libmp3lame-dev libopus-dev
of course :
apt install librockchip-mpp-dev
compiling ffmpeg
cd ~/ffmpeg_sources &&
wget -O ffmpeg-snapshot.tar.bz2 https://ffmpeg.org/releases/ffmpeg-snapshot.tar.bz2 &&
tar xjvf ffmpeg-snapshot.tar.bz2 &&
cd ffmpeg &&
PATH="$HOME/bin:$PATH" PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" ./configure
--prefix="$HOME/ffmpeg_build"
--pkg-config-flags="--static"
--extra-cflags="-I$HOME/ffmpeg_build/include"
--extra-ldflags="-L$HOME/ffmpeg_build/lib"
--extra-libs="-lpthread -lm"
--bindir="$HOME/bin"
--enable-hardcoded-tables --enable-gpl --enable-libaom --enable-libass --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265
--enable-rkmpp
--enable-version3
--enable-libdrm
--enable-nonfree &&
PATH="$HOME/bin:$PATH" make -j4 &&
make install && \

Hello,

I have RK3399
I built mpp using by commands:

mpp/build/linux/aarch64/make-Makefiles.bash
make
sudo make install`
and try to start build/linux/aarch64/test/mpi_test

I receive output:

mpi_test: mpi_test start
mpi_test: mpi_test decoder test start
mpi: mpp version: b186d04 author: Herman Chen [cmake]: Change to shorter RKPLATFORM macro
mpp: unable to create unsupported type 0 coding 0
mpi: mpp_init leave ret -1
mpi_test: mpp_init failed
mpi: mpp_destroy enter ctx 0x2b2d2140
mpi: mpp_destroy leave ret 0
mpi_test: mpi_test failed

If I'm not mistaken it means that something works incorrect. How can i find problem of this error?
What are the reasons for this behavior?

@hizukiayaka
When we built mpp with new code (release branch), we had this error:
video/rk_vpu_service.h: No such file or directory

I just found your gstreamer-rockchip plugin may not work without h264parse, when I debug the gstreamer programs, each time I played the video , the error blow printed:

mpp_buf_slot: mpp_slots_set_prop found invalid input slots 0xa78822a0 type 3 val (nil)

I don't know how to debug gstreamer with mpp, and I'll give the current log I got here:
With the --gst-debug=vpudec:5,vpubufferpool:5,h264parse:5 , I got the debug log as blow:
one is normal when the video switched: http://paste.fedoraproject.org/525878/41931441/
another is stoped playing at the last frame 239: http://paste.fedoraproject.org/525879/14841932/
The video is looped again and again, and It's 239 frames, I don't know why it didn't got an eos message at the last frame?

i think imx219 still not coded for tinkerboard :( very well thank you... we cant use openCV too.
did you think, implement this driver for tinkerboard gpu mpp (like rpi MMAL) ???
we can use mmal for accelerated camera image processing on Rpi !!!
https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/drivers/media/video/sunxi-vfe/device/imx219.c
WHY csi port is un usable????????????

Hello,

todays git branch for_linux got an error:
[h264_rkmpp @ 0xa96025d0] Initializing RKMPP decoder.
mpi: mpp version: 0e51a98 author: Randy Li [build]: update the android build rules
hal_h264d_api: Assertion vcodec_type & ((0x00000200) | (0x00000001) | (0x00000002)) failed at hal_h264d_init:118
hal_h264d_api: hal_h264d_init hard mode error, value=0
hal_h264d_api: Assertion 0 failed at hal_h264d_init:165

I can't find why and need help.

cat /proc/device-tree/compatible
rockchip,rk3288-miniarmrockchip,rk3288

ls /dev/*service
/dev/hevc-service /dev/vpu-service

Regards zillevdr

When running mpi_enc_test h264 test with linux kernel release-4.4 (03d6a38), mpp_device_init() ioctl error. RK3328 MPP (unsigned long) / Kernel (u32) not match.

• MPP: mpp/hal/worker/mpp_device/mpp_device.c

#define VPU_IOC_MAGIC 'l'
#define VPU_IOC_SET_CLIENT_TYPE _IOW(VPU_IOC_MAGIC, 1, unsigned long)
#define VPU_IOC_GET_HW_FUSE_STATUS _IOW(VPU_IOC_MAGIC, 2, unsigned long)
#define VPU_IOC_SET_REG _IOW(VPU_IOC_MAGIC, 3, unsigned long)
#define VPU_IOC_GET_REG _IOW(VPU_IOC_MAGIC, 4, unsigned long)
#define VPU_IOC_PROBE_IOMMU_STATUS _IOR(VPU_IOC_MAGIC, 5, unsigned long)

• Kernel: drivers/video/rockchip/vpu/mpp_dev_common.h

#define MPP_IOC_MAGIC 'l'
#define MPP_IOC_SET_CLIENT_TYPE _IOW(MPP_IOC_MAGIC, 1, u32)
#define MPP_IOC_GET_HW_FUSE_STATUS _IOW(MPP_IOC_MAGIC, 2, u32)
#define MPP_IOC_SET_REG _IOW(MPP_IOC_MAGIC, 3, u32)
#define MPP_IOC_GET_REG _IOW(MPP_IOC_MAGIC, 4, u32)
#define MPP_IOC_PROBE_IOMMU_STATUS _IOR(MPP_IOC_MAGIC, 5, u32)