在编码时加上 osd_enable=1 ./mpi_enc_test
编码后的图片没有出现任何反应正常吗?
RK3399

Hi

I'm trying to run mpi_dec_test on rock64 board with follow command:

./mpi_dec_test -i /home/rock64/bunny.h264 -w 1280 -h 720 -t 7 -o /home/rock64/out.yuv

But there're errors and the mpi_dec stop decoding:

mpi_dec_test: cmd parse result:
mpi_dec_test: input file name: /home/rock64/bunny.h264
mpi_dec_test: output file name: /home/rock64/out.yuv
mpi_dec_test: width : 1280
mpi_dec_test: height : 720
mpi_dec_test: type : 7
mpi_dec_test: debug flag : 0
mpi_dec_test: mpi_dec_test start
mpi_dec_test: input file size 226898646
mpi_dec_test: mpi_dec_test decoder test start w 1280 h 720 type 7
mpi: mpp version: 64b8cdc author: leo.ding [avsd]: add dpb error marking
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
Segmentation fault

Then I tried to use this build https://github.com/rockchip-linux/mpp. The mpi_dec start decoding, there're an .yuv but it's unuseable .

测试分支

develop

对应commit

d1e47f8

问题描述

jpeg持续编码，会出现除数为零的异常错误

测试命令

adb shell /app/bin/mpi_enc_test -i /tmp/1.yuv -o /tmp/1.jpg -t 8 -f 0 -w 1920 -h 1080

测试文件

1.yuv.zip

crash信息

11-18 01:43:31.772 5706 5706 F DEBUG : Build fingerprint: 'rockchip/rk3288/XL10:9/PQ3B.190801.002/111631.910.230.101.43:userdebug/dev-keys'
11-18 01:43:31.772 5706 5706 F DEBUG : Revision: '0'
11-18 01:43:31.772 5706 5706 F DEBUG : ABI: 'arm'
11-18 01:43:31.773 5706 5706 F DEBUG : pid: 5701, tid: 5703, name: mpp_enc >>> /app/bin/mpi_enc_test <<<
11-18 01:43:31.773 5706 5706 F DEBUG : signal 8 (SIGFPE), code -6 (SI_TKILL), fault addr --------
11-18 01:43:31.773 5706 5706 F DEBUG : r0 00000000 r1 00001647 r2 00000008 r3 083522a0
11-18 01:43:31.773 5706 5706 F DEBUG : r4 083522a0 r5 00000000 r6 b2d9bd50 r7 0000010c
11-18 01:43:31.773 5706 5706 F DEBUG : r8 b29c7000 r9 000000a0 r10 0005451c r11 00000000
11-18 01:43:31.773 5706 5706 F DEBUG : ip 00771078 sp b2941550 lr b2d5e504 pc b2be47c8
11-18 01:43:31.787 5706 5706 F DEBUG :
11-18 01:43:31.787 5706 5706 F DEBUG : backtrace:
11-18 01:43:31.787 5706 5706 F DEBUG : #00 pc 000557c8 /system/lib/libc.so (tgkill+12)
11-18 01:43:31.787 5706 5706 F DEBUG : #1 pc 000d6500 /vendor/lib/libmpp.so (__aeabi_idiv0+8)
11-18 01:43:31.787 5706 5706 F DEBUG : #2 pc 000b5658 /vendor/lib/libmpp.so (bits_model_alloc+68)
11-18 01:43:31.787 5706 5706 F DEBUG : #3 pc 000b5e50 /vendor/lib/libmpp.so (calc_vbr_ratio+124)
11-18 01:43:31.788 5706 5706 F DEBUG : #4 pc 000b7810 /vendor/lib/libmpp.so (rc_model_v2_start+508)
11-18 01:43:31.788 5706 5706 F DEBUG : #5 pc 00023938 /vendor/lib/libmpp.so (mpp_enc_thread(void*)+5988)
11-18 01:43:31.788 5706 5706 F DEBUG : #6 pc 00064303 /system/lib/libc.so (__pthread_start(void*)+22)
11-18 01:43:31.788 5706 5706 F DEBUG : #7 pc 0001df8d /system/lib/libc.so (__start_thread+32)

对应堆栈信息

bits_model_alloc
/home/justa/work/opensource/mpp-master/mpp/codec/rc/rc_model_v2.c:337

测试修改补丁

 diff --git a/mpp/codec/rc/rc_model_v2.c b/mpp/codec/rc/rc_model_v2.c
 index 731514db..a74b6076 100644
 --- a/mpp/codec/rc/rc_model_v2.c
 +++ b/mpp/codec/rc/rc_model_v2.c
 @@ -332,6 +332,8 @@ MPP_RET bits_model_alloc(RcModelV2Ctx *ctx, EncRcTaskInfo *cfg, RK_S64 total_bit
      RK_S32 vi_scale = ctx->vi_scale;
      RK_S32 alloc_bits = 0;
 +    // 这里是出错位置，除数为0，不确认是否能否这样子规避，这只是段错误的原点，但理论应该有逻辑错误
 +    // if (ctx->p_sumbits == 0)
 +    //     ctx->p_sumbits = 1;
      ctx->i_scale = 80 * ctx->i_sumbits / (2 * ctx->p_sumbits);
      i_scale = ctx->i_scale;
  
 diff --git a/test/mpi_enc_test.c b/test/mpi_enc_test.c
 index 4e7b45b8..03ad8a6f 100644
 --- a/test/mpi_enc_test.c
 +++ b/test/mpi_enc_test.c
 @@ -140,7 +140,7 @@ MPP_RET test_ctx_init(MpiEncTestData **data, MpiEncTestArgs *cmd)
      p->num_frames   = cmd->num_frames;
      if (cmd->type == MPP_VIDEO_CodingMJPEG && p->num_frames == 0) {
          mpp_log("jpege default encode only one frame. Use -n [num] for rc case\n");
 -        p->num_frames   = 1;
 +        p->num_frames   = 30*10;
      }
      p->gop_mode     = cmd->gop_mode;
      p->gop_len      = cmd->gop_len;
 @@ -500,6 +500,7 @@ MPP_RET test_mpp_run(MpiEncTestData *p)
                      clearerr(p->fp_input);
                      rewind(p->fp_input);
                      p->frm_eos = 0;
 +                    rewind(p->fp_output);
                      mpp_log("%p loop times %d\n", ctx, ++p->loop_times);
                      continue;
                  }

I am trying to encode an RGB888 raw image using mpi_enc_test.

Using the following command:
./mpi_enc_test -i raw.raw -o o.jpg -w 512 -h 512 -f 0x10006 -t 8

On rockchip3399, with kernel:
Linux 4.4.210-rockchip64 #1 SMP Sun Jan 19 19:56:09 CET 2020 aarch64 aarch64 aarch64 GNU/Linux

The raw.raw file has no header, is just packed (not planar) RGB bytes.

The process seems to run correctly:

mpi_enc_test: input  file name: raw.raw
mpi_enc_test: output file name: o.jpg
mpi_enc_test: width      : 512
mpi_enc_test: height     : 512
mpi_enc_test: format     : 0
mpi_enc_test: type       : 8
mpi_enc_test: debug flag : 0
mpi_enc_test: mpi_enc_test start
mpp_rt: NOT found ion allocator
mpp_rt: found drm allocator
mpi_enc_test: mpi_enc_test encoder test start w 512 h 512 type 8
mpi: mpp version: 313156e1 author: sayon.chen [h265e]: Fix compile warn & fixqp case not do rc flow path
mpi_enc_test: mpi_enc_test bps 983040 fps 30 gop 60
jpege_api: jpege: hardware return error status 40
mpi_enc_test: test_mpp_run encoded frame 0 size 33306
mpi_enc_test: test_mpp_run encode max 1 frames
mpi_enc_test: mpi_enc_test success total frame 1 bps 7993440
mpp_buffer: ~MppBufferService cleaning misc group

The resulting o.jpg, is apx 50% grey all over. No detail from the original input. Apx every 8x8 pixels is one slightly darker pixel, but this isn't consistent over the whole image. Attached are input and output (note: output isn't a well formed jpeg so may not display properly in the browser).

raw.zip

There are a significant number of items in dmesg:

`
.
.
.[ 4052.311343] rk-vcodec ff650000.vpu_service: reg[179] 00000000
[ 4052.311352] rk-vcodec ff650000.vpu_service: reg[180] 00000000
[ 4052.311361] rk-vcodec ff650000.vpu_service: reg[181] 00000000
[ 4052.311369] rk-vcodec ff650000.vpu_service: reg[182] 00000000
[ 4052.311378] rk-vcodec ff650000.vpu_service: reg[183] 00000000
[ 4052.311566] rk-vcodec ff650000.vpu_service: resetting...
[ 4052.311612] rk-vcodec ff650000.vpu_service: reset done
[ 4052.311655] rk-vcodec ff650000.vpu_service: reset done

Commit: 60f5fc2

Error when compiling:

mpp/osal/allocator/allocator_dma_heap.c:26:27: fatal error: linux/dma-buf.h: No such file or directory

We're cross-compiling with linux headers:

linux-libc-dev-arm64-cross 4.9.25-1cross1

I'm use mpp_linux_cpp to decode hevc and display.
when I used nvidia encode and use mpp to decode and then display. the Resolution is 2560x1440,the stride calc error。I have change hevc_hor_align to MPP_ALIGN(val, 32), and now it's displayed ok.
decoder require buffer w:h [2560:1440] stride [2560:1440]

hevc is used 32x32.
but when I change resolution to 800x600,the stride calc error too.and I change code to fix.

         mpp_frame_set_hor_stride(frame->frame,
-                                 (MPP_ALIGN(s->h265dctx->coded_width, 64) * s->h265dctx->nBitDepth) >> 3);
+                                 (MPP_ALIGN(s->h265dctx->coded_width, 32) * s->h265dctx->nBitDepth) >> 3);

the log shows as follow:
now decoder require buffer w:h [800:600] stride [800:608]
I think the stride is ok now,but it's still displayed execption.
the stride correspond to MppFrameImpl(hor_stride,ver_stride)
how can I fix it?
the log hevc.log

Hi, I've a problem when using MPP lib.
I can not understand what type of data to input for MPP encode.
When I feed data to mpi task, I always got the packet with same size.

android端解码profile-leve-id是42e01f，用的是constrainedbaseline h264，请问mpp编码如何设置支持42e01f的profile-level_id？

Hi

It seems latest mpp 21 Dec 2017(https://github.com/HermanChen/mpp/commits/develop) also have problems again with HDR video with SPMC but not with Kodi 18 on RK3328.

Can test this video, maybe a h264 codec problem?
http://hdrsamples.com/exodus-4k-uhd-hdr-sample-footage/

Video doesn't open at all with SPMC.
The logcat shows lots of errors for Mediacodec.
I attach the logs including SPMC log too.

If I use mpp from here, June 2017 then HDR is working again in SPMC.
https://github.com/ayufan-rock64/mpp/commits/develop

So somewhere between June - Dec, h264 HDR broke or an incompatibility formed.

SPMC is based on Krypton and made with Android NDK 14b.
Kodi 18 that works with HDR is based on Leila and compiled with NDK 16.
MPP I built I compiled with NDK 10d and also tried 13b(with arm-linux-androideabi-4.8 toolchain).
Can that cause a problem for video playback?

SPMC Log
https://pastebin.com/aMaWL0CQ

RK3328 Logcat(shows lots of Mediacodec errors)
https://pastebin.com/pkfAsA6V

I also sent to James to check.

Hope it can be solved.

firefly@firefly:~/mpp-release/build/linux/aarch64/test$ sudo mpi_enc_test -t 16777220 -w 640 -h 272 -i ds_480x272.yuv -o t.h264 -f 4 -n 10
mpi_enc_test: cmd parse result:
mpi_enc_test: input file name: ds_480x272.yuv
mpi_enc_test: output file name: t.h264
mpi_enc_test: width : 640
mpi_enc_test: height : 272
mpi_enc_test: format : 4
mpi_enc_test: type : 16777220
mpi_enc_test: debug flag : 0
mpi_enc_test: mpi_enc_test start
mpp_rt: NOT found ion allocator
mpp_rt: found drm allocator
mpi_enc_test: mpi_enc_test encoder test start w 640 h 272 type 16777220
mpi: mpp version: Without VCS info
mpp_device: mpp_device_init failed to open device /dev/h265e, errno 12, error msg: Cannot allocate memory
mpi_enc_test: mpi_enc_test bps 652800 fps 30 gop 60
mpp_device: mpp_device_send_reg_with_id ioctl VPU_IOC_WRITE failed ret -1 errno 9 Bad file descriptor
hal_h265e_vepu22: vepu22_set_cfg error: hal_h265e_set_param 0x9 fail
mpp: command 320007 param 0x2d4b11dc ret -1
mpi_enc_test: mpi control enc set codec cfg failed ret -1
mpi_enc_test: mpi_enc_test test mpp setup failed ret -1
mpp_device: mpp_device_deinit invalid negtive file handle,
mpi_enc_test: mpi_enc_test failed ret -1
mpp_buffer: MppBufferService cleaning misc group
firefly@firefly:/mpp-release/build/linux/aarch64/test$

请问kernel版本和mpp版本怎么对应的呢？ kernel 4.4.194，使用最新mpp代码解码jpeg报错，确认是版本兼容问题，这个内核heckout mpp到某个分支正常过，后来再也复现不回去了。

sudo ./test/mpi_dec_test -t 8 -n 1 -f 0 -i ~/test.jpg -w 640 -h 480 -o test.yuv
mpp[1236]: mpi_dec_utils: cmd parse result:
mpp[1236]: mpi_dec_utils: input file name: /home/firefly/test.jpg
mpp[1236]: mpi_dec_utils: output file name: test.yuv
mpp[1236]: mpi_dec_utils: config file name:
mpp[1236]: mpi_dec_utils: width : 640
mpp[1236]: mpi_dec_utils: height : 480
mpp[1236]: mpi_dec_utils: type : 8
mpp[1236]: mpi_dec_utils: debug flag : 0
mpp[1236]: mpi_dec_utils: max frames : 1
mpp[1236]: mpi_dec_test: mpi_dec_test start
mpp[1236]: mpi_dec_test: input file size 44055
mpp[1236]: mpp_rt: NOT found ion allocator
mpp[1236]: mpp_rt: found drm allocator
mpp[1236]: mpp_info: mpp version: ddcb278 author: Chen Jinsen 2021-08-19 [jpegd]: Remove stream copy_flag on rk3568
mpp[1236]: mpi_dec_test: 0x80351e60 mpi_dec_test decoder test start w 640 h 480 type 8
mpp[1236]: vcodec_service: vcodec_service_cmd_send ioctl VPU_IOC_SET_REG failed ret -1 errno 14 Bad address
mpp[1236]: HAL_JPEGD_VDPU1: hal_jpegd_vdpu1_start send cmd failed 14
mpp[1236]: vcodec_service: vcodec_service_cmd_poll ioctl VPU_IOC_GET_REG failed ret -1 errno 110 Connection timed out
mpp[1236]: HAL_JPEGD_VDPU1: hal_jpegd_vdpu1_wait poll cmd failed 110
mpp[1236]: mpi_dec_test: 0x80351e60 decoded frame 0
mpp[1236]: mpi_dec_test: 0x80351e60 input 0 pkt output 0 frm decode 0 frames
mpp[1236]: mpi_dec_test: test success max memory 0.00 MB

kernel 日志：
[ 49.073777] rk_vcodec: reg_init:1487: error: translate reg address failed, dumping regs
[ 49.081867] rk-vcodec ff9a0000.vpu-service: reg[00]: 00000000
[ 49.087609] rk-vcodec ff9a0000.vpu-service: reg[01]: 00000001
[ 49.093401] rk-vcodec ff9a0000.vpu-service: reg[02]: fff80510
[ 49.099152] rk-vcodec ff9a0000.vpu-service: reg[03]: 3000c000
[ 49.104979] rk-vcodec ff9a0000.vpu-service: reg[04]: 1400f000
[ 49.110765] rk-vcodec ff9a0000.vpu-service: reg[05]: 20001b7c
[ 49.116508] rk-vcodec ff9a0000.vpu-service: reg[06]: 00009cff
[ 49.122288] rk-vcodec ff9a0000.vpu-service: reg[07]: 0000003f
[ 49.128029] rk-vcodec ff9a0000.vpu-service: reg[08]: 00000000
[ 49.133796] rk-vcodec ff9a0000.vpu-service: reg[09]: 00000000
[ 49.139571] rk-vcodec ff9a0000.vpu-service: reg[10]: 00000000
[ 49.145313] rk-vcodec ff9a0000.vpu-service: reg[11]: 00000000
[ 49.151084] rk-vcodec ff9a0000.vpu-service: reg[12]: 003c6001
[ 49.156837] rk-vcodec ff9a0000.vpu-service: reg[13]: 00000000
[ 49.162610] rk-vcodec ff9a0000.vpu-service: reg[14]: 00000000
[ 49.168351] rk-vcodec ff9a0000.vpu-service: reg[15]: 00000000
[ 49.174103] rk-vcodec ff9a0000.vpu-service: reg[16]: 02031890
[ 49.179873] rk-vcodec ff9a0000.vpu-service: reg[17]: 05050304
[ 49.185619] rk-vcodec ff9a0000.vpu-service: reg[18]: 00000404
[ 49.191380] rk-vcodec ff9a0000.vpu-service: reg[19]: 10907d01
[ 49.197126] rk-vcodec ff9a0000.vpu-service: reg[20]: 04030404
[ 49.202906] rk-vcodec ff9a0000.vpu-service: reg[21]: 04040507
[ 49.208662] rk-vcodec ff9a0000.vpu-service: reg[22]: 77020100
[ 49.214408] rk-vcodec ff9a0000.vpu-service: reg[23]: 11111510
[ 49.220171] rk-vcodec ff9a0000.vpu-service: reg[24]: 00000001
[ 49.225915] rk-vcodec ff9a0000.vpu-service: reg[25]: 11111130
[ 49.231674] rk-vcodec ff9a0000.vpu-service: reg[26]: 00000111
[ 49.237419] rk-vcodec ff9a0000.vpu-service: reg[27]: 00000000
[ 49.243180] rk-vcodec ff9a0000.vpu-service: reg[28]: 00000000
[ 49.248940] rk-vcodec ff9a0000.vpu-service: reg[29]: 00000000
[ 49.254683] rk-vcodec ff9a0000.vpu-service: reg[30]: 00000000
[ 49.260447] rk-vcodec ff9a0000.vpu-service: reg[31]: 00000000
[ 49.266191] rk-vcodec ff9a0000.vpu-service: reg[32]: 00000000
[ 49.271950] rk-vcodec ff9a0000.vpu-service: reg[33]: 00000000
[ 49.277711] rk-vcodec ff9a0000.vpu-service: reg[34]: 00000000
[ 49.283456] rk-vcodec ff9a0000.vpu-service: reg[35]: 00000000
[ 49.289215] rk-vcodec ff9a0000.vpu-service: reg[36]: 00000000
[ 49.294964] rk-vcodec ff9a0000.vpu-service: reg[37]: 00000000
[ 49.300727] rk-vcodec ff9a0000.vpu-service: reg[38]: 00000000
[ 49.306472] rk-vcodec ff9a0000.vpu-service: reg[39]: 00000000
[ 49.312230] rk-vcodec ff9a0000.vpu-service: reg[40]: 00000003
[ 49.317994] rk-vcodec ff9a0000.vpu-service: reg[41]: 00000000
[ 49.323738] rk-vcodec ff9a0000.vpu-service: reg[42]: 00000000
[ 49.329495] rk-vcodec ff9a0000.vpu-service: reg[43]: 00000000
[ 49.335240] rk-vcodec ff9a0000.vpu-service: reg[44]: 00000000
[ 49.341002] rk-vcodec ff9a0000.vpu-service: reg[45]: 00000000
[ 49.346759] rk-vcodec ff9a0000.vpu-service: reg[46]: 00000000
[ 49.352504] rk-vcodec ff9a0000.vpu-service: reg[47]: 00000000
[ 49.358266] rk-vcodec ff9a0000.vpu-service: reg[48]: 00000000
[ 49.364010] rk-vcodec ff9a0000.vpu-service: reg[49]: 00000000
[ 49.369776] rk-vcodec ff9a0000.vpu-service: reg[50]: 00000000
[ 49.375527] rk-vcodec ff9a0000.vpu-service: reg[51]: 00000000
[ 49.381293] rk-vcodec ff9a0000.vpu-service: reg[52]: 00000000
[ 49.387054] rk-vcodec ff9a0000.vpu-service: reg[53]: 00000000
[ 49.392799] rk-vcodec ff9a0000.vpu-service: reg[54]: 00000000
[ 49.398562] rk-vcodec ff9a0000.vpu-service: reg[55]: 00000000
[ 49.404306] rk-vcodec ff9a0000.vpu-service: reg[56]: 00000000
[ 49.410065] rk-vcodec ff9a0000.vpu-service: reg[57]: 00000000
[ 49.415828] rk-vcodec ff9a0000.vpu-service: reg[58]: 00000000
[ 49.421572] rk-vcodec ff9a0000.vpu-service: reg[59]: 00000000
[ 49.427334] rk-vcodec ff9a0000.vpu-service: reg[60]: 00000002
[ 49.433079] rk-vcodec ff9a0000.vpu-service: reg[61]: 0000fef0
[ 49.438842] rk-vcodec ff9a0000.vpu-service: reg[62]: 00000000
[ 49.444585] rk-vcodec ff9a0000.vpu-service: reg[63]: 00000000
[ 49.450344] rk-vcodec ff9a0000.vpu-service: reg[64]: 00000000
[ 49.456118] rk-vcodec ff9a0000.vpu-service: reg[65]: 00000000
[ 49.461861] rk-vcodec ff9a0000.vpu-service: reg[66]: 00000000
[ 49.467623] rk-vcodec ff9a0000.vpu-service: reg[67]: 12c00000
[ 49.473372] rk-vcodec ff9a0000.vpu-service: reg[68]: 00000000
[ 49.479135] rk-vcodec ff9a0000.vpu-service: reg[69]: 00000000
[ 49.484879] rk-vcodec ff9a0000.vpu-service: reg[70]: 00000000
[ 49.490641] rk-vcodec ff9a0000.vpu-service: reg[71]: 00001000
[ 49.496403] rk-vcodec ff9a0000.vpu-service: reg[72]: 00243c28
[ 49.502147] rk-vcodec ff9a0000.vpu-service: reg[73]: 00000000
[ 49.507905] rk-vcodec ff9a0000.vpu-service: reg[74]: 00000000
[ 49.513652] rk-vcodec ff9a0000.vpu-service: reg[75]: 00000000
[ 49.519412] rk-vcodec ff9a0000.vpu-service: reg[76]: 00000000
[ 49.525169] rk-vcodec ff9a0000.vpu-service: reg[77]: 00000000
[ 49.530914] rk-vcodec ff9a0000.vpu-service: reg[78]: 00000000
[ 49.536678] rk-vcodec ff9a0000.vpu-service: reg[79]: 00000000
[ 49.542422] rk-vcodec ff9a0000.vpu-service: reg[80]: 00000000
[ 49.548180] rk-vcodec ff9a0000.vpu-service: reg[81]: 00000000
[ 49.553927] rk-vcodec ff9a0000.vpu-service: reg[82]: 00000000
[ 49.559690] rk-vcodec ff9a0000.vpu-service: reg[83]: 00000000
[ 49.565448] rk-vcodec ff9a0000.vpu-service: reg[84]: 00000000
[ 49.571192] rk-vcodec ff9a0000.vpu-service: reg[85]: 94f02800
[ 49.576956] rk-vcodec ff9a0000.vpu-service: reg[86]: 04800000
[ 49.582699] rk-vcodec ff9a0000.vpu-service: reg[87]: 00000000
[ 49.588462] rk-vcodec ff9a0000.vpu-service: reg[88]: 14000000
[ 49.594228] rk-vcodec ff9a0000.vpu-service: reg[89]: 00000000
[ 49.599971] rk-vcodec ff9a0000.vpu-service: reg[90]: 00000000
[ 49.605728] rk-vcodec ff9a0000.vpu-service: reg[91]: 00000000
[ 49.611479] rk-vcodec ff9a0000.vpu-service: reg[92]: 00000280
[ 49.617240] rk-vcodec ff9a0000.vpu-service: reg[93]: 00000000
[ 49.622984] rk-vcodec ff9a0000.vpu-service: reg[94]: 00000000
[ 49.628743] rk-vcodec ff9a0000.vpu-service: reg[95]: 00000000
[ 49.634505] rk-vcodec ff9a0000.vpu-service: reg[96]: 00000000
[ 49.640250] rk-vcodec ff9a0000.vpu-service: reg[97]: 00000000
[ 49.646007] rk-vcodec ff9a0000.vpu-service: reg[98]: 00000000
[ 49.651751] rk-vcodec ff9a0000.vpu-service: reg[99]: 00000000
[ 49.657512] rk-vcodec ff9a0000.vpu-service: reg[100]: 00000000
[ 49.663354] rk-vcodec ff9a0000.vpu-service: reg[101]: 00000000
[ 49.669180] rk-vcodec ff9a0000.vpu-service: reg[102]: 00000000
[ 49.675026] rk-vcodec ff9a0000.vpu-service: reg[103]: 00000000
[ 49.680851] rk-vcodec ff9a0000.vpu-service: reg[104]: 00000000
[ 49.686692] rk-vcodec ff9a0000.vpu-service: reg[105]: 00000000
[ 49.692521] rk-vcodec ff9a0000.vpu-service: reg[106]: 00000000
[ 49.698364] rk-vcodec ff9a0000.vpu-service: reg[107]: 00000000
[ 49.704208] rk-vcodec ff9a0000.vpu-service: reg[108]: 00000000
[ 49.710035] rk-vcodec ff9a0000.vpu-service: reg[109]: 00000000
[ 49.715887] rk-vcodec ff9a0000.vpu-service: reg[110]: 00000000
[ 49.721713] rk-vcodec ff9a0000.vpu-service: reg[111]: 00000000
[ 49.727555] rk-vcodec ff9a0000.vpu-service: reg[112]: 00000000
[ 49.733401] rk-vcodec ff9a0000.vpu-service: reg[113]: 00000000
[ 49.739227] rk-vcodec ff9a0000.vpu-service: reg[114]: 00000000
[ 49.745066] rk-vcodec ff9a0000.vpu-service: reg[115]: 00000000
[ 49.750897] rk-vcodec ff9a0000.vpu-service: reg[116]: 00000000
[ 49.756742] rk-vcodec ff9a0000.vpu-service: reg[117]: 00000000
[ 49.762582] rk-vcodec ff9a0000.vpu-service: reg[118]: 00000000
[ 49.768409] rk-vcodec ff9a0000.vpu-service: reg[119]: 00000000
[ 49.774253] rk-vcodec ff9a0000.vpu-service: reg[120]: 00000000
[ 49.780079] rk-vcodec ff9a0000.vpu-service: reg[121]: 00000000
[ 49.785919] rk-vcodec ff9a0000.vpu-service: reg[122]: 00000000
[ 49.791767] rk-vcodec ff9a0000.vpu-service: reg[123]: 00000000
[ 49.797592] rk-vcodec ff9a0000.vpu-service: reg[124]: 00000000
[ 49.803432] rk-vcodec ff9a0000.vpu-service: reg[125]: 00000000
[ 49.809261] rk-vcodec ff9a0000.vpu-service: reg[126]: 00000000
[ 49.815104] rk-vcodec ff9a0000.vpu-service: reg[127]: 00000000
[ 49.820932] rk-vcodec ff9a0000.vpu-service: reg[128]: 00000000
[ 49.826772] rk-vcodec ff9a0000.vpu-service: reg[129]: 00000000
[ 49.832617] rk-vcodec ff9a0000.vpu-service: reg[130]: 00000000
[ 49.838444] rk-vcodec ff9a0000.vpu-service: reg[131]: 00000000
[ 49.844283] rk-vcodec ff9a0000.vpu-service: reg[132]: 00000000
[ 49.850112] rk-vcodec ff9a0000.vpu-service: reg[133]: 00000000
[ 49.855957] rk-vcodec ff9a0000.vpu-service: reg[134]: 00000000
[ 49.861798] rk-vcodec ff9a0000.vpu-service: reg[135]: 00000000
[ 49.867624] rk-vcodec ff9a0000.vpu-service: reg[136]: 00000000
[ 49.873469] rk-vcodec ff9a0000.vpu-service: reg[137]: 00000000
[ 49.879294] rk-vcodec ff9a0000.vpu-service: reg[138]: 00000000
[ 49.885134] rk-vcodec ff9a0000.vpu-service: reg[139]: 00000000
[ 49.890981] rk-vcodec ff9a0000.vpu-service: reg[140]: 00000000
[ 49.896807] rk-vcodec ff9a0000.vpu-service: reg[141]: 00000000
[ 49.902645] rk-vcodec ff9a0000.vpu-service: reg[142]: 00000000
[ 49.908477] rk-vcodec ff9a0000.vpu-service: reg[143]: 00000000
[ 49.914321] rk-vcodec ff9a0000.vpu-service: reg[144]: 00000000
[ 49.920165] rk-vcodec ff9a0000.vpu-service: reg[145]: 00000000
[ 49.925991] rk-vcodec ff9a0000.vpu-service: reg[146]: 00000000
[ 49.931836] rk-vcodec ff9a0000.vpu-service: reg[147]: 00000000
[ 49.937662] rk-vcodec ff9a0000.vpu-service: reg[148]: 00000000
[ 49.943502] rk-vcodec ff9a0000.vpu-service: reg[149]: 00000000
[ 49.949331] rk-vcodec ff9a0000.vpu-service: reg[150]: 00000000
[ 49.955174] rk-vcodec ff9a0000.vpu-service: reg[151]: 00000000
[ 49.961014] rk-vcodec ff9a0000.vpu-service: reg[152]: 00000000
[ 49.966840] rk-vcodec ff9a0000.vpu-service: reg[153]: 00000000
[ 49.972690] rk-vcodec ff9a0000.vpu-service: reg[154]: 00000000
[ 49.978516] rk-vcodec ff9a0000.vpu-service: reg[155]: 00000000
[ 49.984360] rk-vcodec ff9a0000.vpu-service: reg[156]: 00000000
[ 49.990206] rk-vcodec ff9a0000.vpu-service: reg[157]: 00000000
[ 49.996032] rk-vcodec ff9a0000.vpu-service: reg[158]: 00000000
[ 50.001872] rk-vcodec ff9a0000.vpu-service: reg[159]: 00000000
[ 50.007701] rk-vcodec ff9a0000.vpu-service: reg[160]: 00000000
[ 50.013545] rk-vcodec ff9a0000.vpu-service: reg[161]: 00000000
[ 50.019385] rk-vcodec ff9a0000.vpu-service: reg[162]: 00000000
[ 50.025211] rk-vcodec ff9a0000.vpu-service: reg[163]: 00000000

I build @HermanChen mpp/build/linux/aarch64.

and install mpp/debian librockchip-mpp-dev.install, librockchip-mpp1.install, rockchip-mpp-demos.install, librockchip-vpu0.install

If I give all parameters it gives Seg fault

root@radxa-cm3-io:/home/rock# mpi_dec_test demo.h264 -w 10 -h 10 -t 7
Segmentation fault

if I do not give -t 7 parameters

root@radxa-cm3-io:/home/rock# mpi_dec_test 2022-06-18_15-15-54.mkv -w 10 -h 10
root@radxa-cm3-io:/home/rock#

It does not give any output

硬件平台

RK3566

android版本

Android 12.1 @ rk-r7

补丁

@@ -254,7 +255,7 @@ static int dec_simple(MpiDecLoopData *data)
                         data->first_frm = mpp_time();
 
                     log_len += snprintf(log_buf + log_len, log_size - log_len,
-                                        "decode get frame %d", data->frame_count);
+    

测试方法

mpi_dec_test -i /sdcard/1.264 -o /sdcard/Movies/1.yuv -w 1280 -h 720

测试后数据

32bit的程序，稳定在17~20帧左右

11-11 13:21:40.348 10243 10269 I mpi_dec_test: 0xe7880070 decode get frame 372 fps:19.40
11-11 13:21:40.380 10243 10269 I mpi_dec_test: 0xe7880070 decode get frame 373 fps:19.42
11-11 13:21:40.413 10243 10269 I mpi_dec_test: 0xe7880070 decode get frame 374 fps:19.44
11-11 13:21:40.443 10243 10269 I mpi_dec_test: 0xe7880070 decode get frame 375 fps:19.46
11-11 13:21:40.479 10243 10269 I mpi_dec_test: 0xe7880070 decode get frame 376 fps:19.47

64位的程序，稳定在35帧左右

11-11 13:22:21.429 10789 10793 I mpi_dec_test: 0xb400007c9a22d470 decode get frame 247 fps:37.22
11-11 13:22:21.450 10789 10793 I mpi_dec_test: 0xb400007c9a22d470 decode get frame 248 fps:37.25
11-11 13:22:21.471 10789 10793 I mpi_dec_test: 0xb400007c9a22d470 decode get frame 249 fps:37.29

详见redmine-383315

The MPP library currently only support hardware encoding for H.264, yet the RK3328 support both H.264 and H.265.

mpi_dec_mt_test h264.h264 -w 10 -h 10 -t 7
mpi_dec_mt_test: cmd parse result:
mpi_dec_mt_test: input file name:
mpi_dec_mt_test: output file name:
mpi_dec_mt_test: width : 10
mpi_dec_mt_test: height : 10
mpi_dec_mt_test: type : 7
mpi_dec_mt_test: debug flag : 0
mpi_dec_mt_test: mpi_dec_test start
mpi_dec_mt_test: mpi_dec_test decoder test start w 10 h 10 type 7
mpi: mpp version: 5ce1cb85 author: Caesar Wang debian: add rules for mpp with 20190626
mpp_log: can not found match soc name: radxa,radxa-cm3-io rockchip,rk3566
hal_h264d_api: Assertion vcodec_type & ((0x00000200) | (0x00000001) | (0x00000002)) failed at hal_h264d_init:104
hal_h264d_api: hal_h264d_init hard mode error, value=0
hal_h264d_api: Assertion 0 failed at hal_h264d_init:154
mpp_device: mpp_device_init failed to find device for coding 7 type 0
mpp_rt: NOT found ion allocator
mpp_rt: found drm allocator
Segmentation fault

主仓库的，jpeg编码质量过差
开发分支仓库（本仓库），jpeg编码完全异常掉

Android版本：9.0
平台：RK3288W

测试指令：
adb shell /app/bin/mpi_enc_test -i /tmp/1.yuv -o /tmp/1.jpg -t 8 -f 0 -w 1920 -h 1080 -u 1920 -v 1080
原图YUV：
1.yuv.zip

编码异常图片：
编码质量过差（主仓库），注意脸部分颜色异常：

你好，如题所述rk3399上用mppJpeg编码时如何调整压缩率？我现在用mpp编码yuv422格式的输入文件后，生成的jpg文件能正常显示，但是还是有些大，mpp中调整哪个参数可以提高压缩比？

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

4K@24/25/30fps all play correctly 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.

Is there a solution perhaps or frame-rates, bitrates too high for soc with Mediacodec support?

同一个APP，在使用摄像头作为输入源的情况下，连续挂机跑了1周，内存基本无变化。但是改为解码h264作为输入源，挂机跑了两天，内存从14%增长到了28.8%。所以mpp视频解码库存在内存泄漏问题。

您好，我希望给 webrtc 增加 h264 的硬件解码，模仿 mpi_dec_test.c 中的 decode_advanced() 实现，发现 poll(ctx_, MPP_PORT_OUTPUT, MPP_POLL_BLOCK) 时阻塞，没有返回 ...

   int mpp_dec(const EncodedImage &img, bool missing)
   {
         MppTask task = 0;
         void *ptr = mpp_buffer_get_ptr(pkt_buf_);  // pkt_buf_ 分配了1M字节空间
         memcpy(ptr, img.data(), img.size());    // 将 EncodedImage 中的压缩数据复制到缓冲.
                                                                      // 数据为IDR，00 00 00 01 67 ....
         mpp_packet_set_pos(packet_, ptr);
         mpp_packet_set_length(packet_, img.size()); 
         rc = mpi_->poll(ctx_, MPP_POPT_INPUT, MPP_POLL_BLOCK);
         rc = mpi_->dequeue(ctx_, MPP_PORT_INPUT, &task);
         mpp_task_meta_set_packet(task, KEY_INPUT_PACKET, &packet_);
         mpp_task_meta_set_frame(task, KEY_OUTPUT_FRAME, &frame_);  // frame_ 已经分配，并绑定到 frm_buf, 大小足够 ...
         mpi_->enqueue(ctx_, MPP_PORT_INPUT, task);
         __android_log_print(6, "mpp", "before poll out ...\n");
         mpi_->poll(ctx_, MPP_PORT_OUTPUT, MPP_POLL_BLOCK);  // << 这一行阻塞了 ...
         ....

Hi, I try to use mpi_dec_test.c in order to get RGB output (NV12->RGB).
I am using single-board computer OrangePi4 with Rockhip RK3399 SoC. Orange's Ubuntu Bionic Image v1.3. Linux kernel is 4.4.179.

My test video stream is h264 3072x2048 yuvj420p.
The decoding itself performs really fast, but post-processing kill all benefits.
It takes about 60 ms to copy data from the buffer to RAM.

void my_dump_mpp_frame_to_file(MppFrame frame, unsigned char *target)
{
    RK_U32 width    = 0;
    RK_U32 height   = 0;
    RK_U32 h_stride = 0;
    RK_U32 v_stride = 0;
    MppBuffer buffer    = NULL;
    RK_U8 *base = NULL;

    if (NULL == target||  NULL == frame)
        return ;

    width    = mpp_frame_get_width(frame);
    height   = mpp_frame_get_height(frame);
    h_stride = mpp_frame_get_hor_stride(frame);
    v_stride = mpp_frame_get_ver_stride(frame);  
    buffer  = mpp_frame_get_buffer(frame);

    if (NULL == buffer)
        return ;

    base = (RK_U8 *)mpp_buffer_get_ptr(buffer );
  
    RK_U8 *base_y = base;
    RK_U8 *base_c = base + h_stride * v_stride;

    memcpy(target, base, width*height+width*(height/2)); // this memcpy take ~60ms
}

...
unsigned char yv12DataBuffer[3072*1024*3]; //global var
...
// NV12-> RGB convertation
auto nWidth = cmd->width;
auto nHeight = cmd->height;
cv::Mat picYV12 = cv::Mat(nHeight * 3/2, nWidth, CV_8UC1, yv12DataBuffer);
cv::Mat picBGR;
cv::cvtColor(picYV12, picBGR, cv::COLOR_YUV2RGB_NV21 );

What is the best way to get RGB image after decoding?
Should I use a different buffer mode (external) to improve performance?

我们现在用mpp编码时遇到一个问题，如果游戏地图场景不移动，画面在整体变化较小情况下解码图像比较清晰，如果整体画面移动时候整体画面明显变模糊。我们现在用的VBR, 尝试过调大bps发现没效果还会是整体画面变卡顿，请问我们改做什么调整能改善这个问题呢？

在 RK3568 平台,使用编译出来最新的 mpp 库,解码对方发送的 hevc 码流时,一直报错如下:

mpp[873]: H265D_PARSER: PPS id out of range: 0
mpp[873]: H265D_PARSER: hls_slice_header error ret = -1004
mpp[873]: H265D_PARSER: Error parsing NAL unit #0,error ret = 0xd.
mpp[873]: H265D_PARSER: current stream is no right skip it (nil)

导致无法显示任何图像,请问可能是什么原因呢?

您好，最近尝试rk3999 android 开发，设备上无 /dev/ion，用 mpi_enc_test -f 4 -t 7 -w 1920 -h 1080 -o /sdcard/test.h264 -n 500 -b 2000000:1600000:2400000 测试，发现 mpp_enc_put_frame 大约耗时 23ms，mpp_enc_get_packet() 耗时很小

09-17 03:07:48.380 4290 4290 I mpi_enc_test: mpi_enc_test start
09-17 03:07:48.383 4290 4290 I mpp_rt : NOT found ion allocator
09-17 03:07:48.383 4290 4290 I mpp_rt : found drm allocator
09-17 03:07:48.393 4290 4290 I mpp_info: mpp version: 46a33b2 author: yandong.lin 2020-09-09 [mpi_enc_test]: add vp8e rc test demo
09-17 03:07:48.393 4290 4290 I mpi_enc_test: 0x7eacc42000 mpi_enc_test encoder test start w 1920 h 1080 type 7
09-17 03:07:48.393 4290 4290 I mpi_enc_test: type=1400 audit(0.0:78): avc: denied { read } for name="compatible" dev="sysfs" ino=75 scontext=u:r:shell:s0 tcontext=u:object_r:sysfs:s0 tclass=file permissive=1
09-17 03:07:48.393 4290 4290 I mpi_enc_test: type=1400 audit(0.0:79): avc: denied { open } for path="/sys/firmware/devicetree/base/compatible" dev="sysfs" ino=75 scontext=u:r:shell:s0 tcontext=u:object_r:sysfs:s0 tclass=file permissive=1
09-17 03:07:48.399 4290 4291 I h264e_api_v2: MPP_ENC_SET_PREP_CFG w:h [1920:1080] stride [1920:1080]
09-17 03:07:48.399 4290 4291 I h264e_api_v2: MPP_ENC_SET_RC_CFG bps 2000000 [1600000 : 2400000] fps [30:30] gop 60
09-17 03:07:48.399 4290 4291 I mpp_enc_v2: send header for set cfg change input/format
09-17 03:07:48.393 4290 4290 I mpi_enc_test: type=1400 audit(0.0:80): avc: denied { read write } for name="vpu_service" dev="tmpfs" ino=15873 scontext=u:r:shell:s0 tcontext=u:object_r:video_device:s0 tclass=chr_file permissive=1
09-17 03:07:48.403 4290 4291 I mpp_enc_v2: mode vbr bps [1600000:2000000:2400000] fps fix [30/1] -> fix [30/1] gop i [60] v [0]
09-17 03:07:48.393 4290 4290 I mpi_enc_test: type=1400 audit(0.0:81): avc: denied { open } for path="/dev/vpu_service" dev="tmpfs" ino=15873 scontext=u:r:shell:s0 tcontext=u:object_r:video_device:s0 tclass=chr_file permissive=1
09-17 03:07:48.393 4290 4290 I mpi_enc_test: type=1400 audit(0.0:82): avc: denied { ioctl } for path="/dev/vpu_service" dev="tmpfs" ino=15873 ioctlcmd=6c01 scontext=u:r:shell:s0 tcontext=u:object_r:video_device:s0 tclass=chr_file permissive=1
09-17 03:07:48.443 4290 4290 I mpi_enc_test: enc: total:0.04013, put frame:0.04012, get packet:0.00002
09-17 03:07:48.445 4290 4290 I mpi_enc_test: 0x7eacc42000 encoded frame 0 size 46213
09-17 03:07:48.483 4290 4290 I mpi_enc_test: enc: total:0.03147, put frame:0.03145, get packet:0.00002
09-17 03:07:48.483 4290 4290 I mpi_enc_test: 0x7eacc42000 encoded frame 1 size 12044
09-17 03:07:48.513 4290 4290 I mpi_enc_test: enc: total:0.02268, put frame:0.02266, get packet:0.00002
09-17 03:07:48.513 4290 4290 I mpi_enc_test: 0x7eacc42000 encoded frame 2 size 6644
09-17 03:07:48.543 4290 4290 I mpi_enc_test: enc: total:0.02286, put frame:0.02284, get packet:0.00002

代码中，修改 test_mpp_run() 统计 mpp_enc_put_frame() 和 mpp_enc_get_packet() 的时间。

感觉是数据传输的问题，是否有优化的方案？ 谢谢 :)

硬解码之后的数据拷贝很慢，大佬我该怎么解决

Hi, I download the latest version of mpp, and then I try to use the mpi_enc_test to encode JPG by a 422UYVY file, the output jpeg file is not ok, the jpg file seems half is right，half has no data. But I encode the same 422UYVY file to encode h264, the output h264 video is ok.

The testing commad information as below:
./mpi_enc_test -i ../ch0/20201103-234441/20201103-234441-0000.422uyvy -o t2020.jpg -w 2448 -h 2048 -f 10 -t 8

mpp[4797]: mpi_enc_utils: cmd parse result:
mpp[4797]: mpi_enc_utils: input file name: ../ch0/20201103-234441/20201103-234441-0000.422uyvy
mpp[4797]: mpi_enc_utils: output file name: t2020.jpg
mpp[4797]: mpi_enc_utils: width : 2448
mpp[4797]: mpi_enc_utils: height : 2048
mpp[4797]: mpi_enc_utils: format : 10
mpp[4797]: mpi_enc_utils: type : 8
mpp[4797]: mpi_enc_test: mpi_enc_test start
mpp[4797]: mpi_enc_test: jpege default encode only one frame. Use -n [num] for rc case
mpp[4797]: mpp_rt: NOT found ion allocator
mpp[4797]: mpp_rt: found drm allocator
mpp[4797]: mpp_info: mpp version: unknown mpp version for missing VCS info
mpp[4797]: mpi_enc_test: 0x558f6fbde0 mpi_enc_test encoder test start w 2448 h 2048 type 8
mpp[4797]: hal_jpege_vepu2_2: hal_jpege_vepu2_set_extra_info other format(10)
mpp[4797]: mpi_enc_test: test_mpp_run packet flag:0
mpp[4797]: mpi_enc_test: test_mpp_run FFFFFFFFFFFFFFFFFFFFF is_intra:1
mpp[4797]: mpi_enc_test: 0x558f6fbde0 encoded frame 0 size 202505
mpp[4797]: mpi_enc_test: 0x558f6fbde0 encode max 1 frames
mpp[4797]: mpi_enc_test: 0x558f6fbde0 mpi_enc_test success total frame 1 bps 48601200

So, what's wrong with the JPEG encoding by 422UYVY format ?

线程A 往mpp解码器送数据 调用函数 decode_put_packet（ffmpeg 拉流）
线程B 解码数据 调用函数 decode_get_frame 结果存放到std::list 中
线程C 正常从std::list 中读取并显示出来

显示正常，不丢帧，不报错，但是我想控制解码器的速度，有时候有用到解码后的数据做一些其他事情比较耗时
这样导致std::list 生产的快，消费的满，导致数据丢失，尝试在线程A中添加延时发现线程B mpp_frame_get_errinfo出错
尝试在B线程添加延时，发现线程A decode_put_packet 报错 MPP_ERR_BUFFER_FULL

请问如何控制mpp 解码的速度？？

mpp.cpp 中的 Mpp::start(),Mpp::stop(),Mpp::pause(),Mpp::resume() 是空实现，请问这个是为了控制速度么，什么时候可以实现

谢谢

使用的mpp版本: [mpp_packet]: Add segment info copy function commit d1da307
我使用的是rv1126录制的h264视频，然后在rv1126上进行视频解码测试，发现将解码的视频显示到屏幕上是不流畅的，一卡一卡的，但是偶尔会出现短暂时间的流畅。我解码时填入一帧解码4096字节，休眠30毫秒的周期性解码，使用的rkmedia中的vdec->rga->vo方式输出到屏幕(使用的摄像头的话，画面是非常流畅的，延时也小，就是使用h264解码视频就是一卡卡的)

Hi, I try to use mpi_dec_test.c in order to get YUV output from JPEG.
But the generated YUV file opens only in green.
The same code can generate correct YUV file on 3399.
The following is the log printed by running mpi_dec_test on 3288:

[mpi_dec_test_show_options:902]: cmd parse result:
[mpi_dec_test_show_options:903]: input  file name: ./testImage/testJPEG_640_480.jpeg
[mpi_dec_test_show_options:904]: output file name: ./testImage/output/testJPEG_640_480.yuv
[mpi_dec_test_show_options:905]: config file name: 
[mpi_dec_test_show_options:906]: width      :  640
[mpi_dec_test_show_options:907]: height     :  480
[mpi_dec_test_show_options:908]: type       : 8
[mpi_dec_test_show_options:909]: debug flag : 0
[mpi_dec_test_show_options:910]: max frames : 1
[mpi_dec_test_decode:523]: mpi_dec_test start
[mpi_dec_test_decode:536]: input file size 57512
[MppRuntimeService]-86: found ion allocator
[MppRuntimeService]-91: NOT found drm allocator
[check_sysfs_iommu]-245: vpu_service iommu_enabled 0
[allocator_ion_open]-345: using ion heap ION_HEAP_TYPE_DMA
[mpi_dec_test_decode:628]: 0xb8a33860 mpi_dec_test decoder test start w 640 h 480 type 8
[decode_advanced:476]: 0xb8a33860 decoded frame 0
[decode_advanced:415]: 0xb8a33860 found last packet
[decode_advanced:476]: 0xb8a33860 decoded frame 1
[decode_advanced:480]: 0xb8a33860 found eos frame
[main:944]: test success max memory 0.00 MB

[check_sysfs_iommu]-245: vpu_service iommu_enabled 0
[allocator_ion_open]-345: using ion heap ION_HEAP_TYPE_DMA
It seems that there are some problems with ion in the kernel environment

Can you please help me see how to solve this problem?

Dear @HermanChen, thanks for your great job.
I'm going to use mpp in my C++ Project to encode my stream frames.
every thing is clear and works pretty well in mpi_enc_test.c but I wonder which libraries and header files have to be linked and included in my project? for example libmpp.so or so on.
is there any api documentation for ?
I'm not utilizing CMake for my project and need to put everything in my makefile.

Hi, I have a problem decoding a RTSP video (h264) using h264_rkmpp decoder.

In this example, you have see one image using a Intel CPU (with h264_vaapi), which look perfect and the other, using Rock64 (4gb version), with h264_rkmpp:

Intel:

Rock64:

Here another Rock64. Just in case, using latest mpp:

FFmpeg compiled by myself, version 4.2.4 with, of course, h264_rkmpp enabled.
Kernel: Linux 4.4.213-rockchip64
OS: Armbian Focal - Ubuntu 20.04.1 LTS

35XX上测试RTP推流的功能，发现RK3568、3588系列的板子上硬件编码推流到播放端端无法被解码。
抓包H264裸流测试分析，RK3588 H264硬件编码出来的帧都是I帧，是什么原因呢，编码器需要做什么特殊配置吗？

相同的配置代码，Google的软编码器则正常。

MediaCodec配置：

MediaFormat mediaFormat = MediaFormat.createVideoFormat(MIME_TYPE_VIDEO, 720, 1280);
mediaFormat.setInteger(MediaFormat.KEY_BIT_RATE, 2500000);
mediaFormat.setInteger(MediaFormat.KEY_FRAME_RATE, 10);
mediaFormat.setInteger(MediaFormat.KEY_COLOR_FORMAT,
        MediaCodecInfo.CodecCapabilities.COLOR_FormatSurface);
mediaFormat.setInteger(MediaFormat.KEY_I_FRAME_INTERVAL, 10);

3588日志信息如下：

12-10 22:21:00.076   107 29610 I C2RKMpiEnc: IDR frame produced
12-10 22:21:00.084 291657 29603 W MediaCodec: mapFormat: no mediaType information
12-10 22:21:00.178   107 29610 I C2RKMpiEnc: IDR frame produced
12-10 22:21:00.181 291657 29603 W MediaCodec: mapFormat: no mediaType information
12-10 22:21:00.279   107 29610 I C2RKMpiEnc: IDR frame produced
12-10 22:21:00.282 291657 29603 W MediaCodec: mapFormat: no mediaType information
12-10 22:21:00.378   107 29610 I C2RKMpiEnc: IDR frame produced
12-10 22:21:00.381 291657 29603 W MediaCodec: mapFormat: no mediaType information
12-10 22:21:00.480   107 29610 I C2RKMpiEnc: IDR frame produced
12-10 22:21:00.483 291657 29603 W MediaCodec: mapFormat: no mediaType information
12-10 22:21:00.548 291854 29721 W System  : A resource failed to call close.
12-10 22:21:00.549 291854 29721 W System  : A resource failed to call close.
12-10 22:21:00.579   107 29610 I C2RKMpiEnc: IDR frame produced
12-10 22:21:00.582 291657 29603 W MediaCodec: mapFormat: no mediaType information
12-10 22:21:00.681   107 29610 I C2RKMpiEnc: IDR frame produced
12-10 22:21:00.683 291657 29603 W MediaCodec: mapFormat: no mediaType information
12-10 22:21:00.781   107 29610 I C2RKMpiEnc: IDR frame produced
12-10 22:21:00.784 291657 29603 W MediaCodec: mapFormat: no mediaType information
12-10 22:21:00.879   107 29610 I C2RKMpiEnc: IDR frame produced
12-10 22:21:00.881 291657 29603 W MediaCodec: mapFormat: no mediaType information

Hi，rk3399 linux平台使用最新版本的mpp进行jpeg解码输出yuv420sp格式的jpg文件，发现在连续解码时，头两帧都是正常输出，但是从第3帧开始开始出现异常打印错误，而且从第4帧开始输出的文件全部都是和第3帧的jpg输出文件一样，出错日志如下：
mpp[22973]: mpi_dec_test: mpi_dec_test_decode the 1 decode
mpp[22973]: mpi_dec_test: decode_advanced 0x5592c2c0a0 decoded frame 0
mpp[22973]: mpi_dec_test: mpi_dec_test_decode the 2 decode
mpp[22973]: mpi_dec_test: decode_advanced 0x5592c2c0a0 decoded frame 1
mpp[22973]: mpi_dec_test: mpi_dec_test_decode the 3 decode
mpp[22973]: mpi_dec_test: decode_advanced 0x5592c2c0a0 decoded frame 2
mpp[22973]: mpi_dec_test: mpi_dec_test_decode the 4 decode
mpp[22973]: HAL_JPEG_VDPU2: hal_jpegd_vdpu2_wait IRQ TIMEOUT!
mpp[22973]: mpi_dec_test: decode_advanced 0x5592c2c0a0 decoded frame 3
mpp[22973]: mpi_dec_test: mpi_dec_test_decode the 5 decode
mpp[22973]: HAL_JPEG_VDPU2: hal_jpegd_vdpu2_wait IRQ TIMEOUT!
mpp[22973]: mpi_dec_test: decode_advanced 0x5592c2c0a0 decoded frame 4
mpp[22973]: mpi_dec_test: mpi_dec_test_decode the final decode over

就是从第3帧开始，一旦出现打印HAL_JPEG_VDPU2: hal_jpegd_vdpu2_wait IRQ TIMEOUT!后，解码输出的文件就不对了，请问这个错误该怎么解决。

mpp[3707]: mpp_info: mpp version: 5132a49 author: Yandong Lin 2022-07-29 [mpi_enc_test]: add sei_mode env to control sei mode

mpp[3707]: mpp_soc: Assertion soc_info->vcodec_type == vcodec_type failed at MppSocService:794

[New LWP 3740]
[New LWP 3741]
[15924.175158] pgd = 4c046533
[15924.175197] [8ce25000] *pgd=2cb7c835, *pte=27098787, *ppte=27098e37
[15924.175227] CPU: 0 PID: 3740 Comm: mpp_dec_parser Tainted: G O 4.19.111 #1
[15924.175240] Hardware name: Generic DT based system
[15924.175256] PC is at 0x96d2f140
[15924.175268] LR is at 0xa13fea50
[15924.175280] pc : [<96d2f140>] lr : [] psr: 200d0010
[15924.175293] sp : 8c9da944 ip : 8ce25000 fp : 0000ab20
[15924.175306] r10: 8c9da9e0 r9 : 8cd0bed4 r8 : 0000a860
[15924.175345] r7 : a14e1ca8 r6 : 8ce25000 r5 : 8cd0bdc0 r4 : 0000ab20
[15924.175371] r3 : 00000000 r2 : 0000ab20 r1 : 8c9dc040 r0 : 8ce25000
[15924.175394] Flags: nzCv IRQs on FIQs on Mode USER_32 ISA ARM Segment user
[15924.175414] Control: 10c5387d Table: 2cbf006a DAC: 00000055
[15924.175437] CPU: 0 PID: 3740 Comm: mpp_dec_parser Tainted: G O 4.19.111 #1
[15924.175452] Hardware name: Gene
Thread 14 "mpp_dec_parser" received signal SIGSEGV, Segmentation fault.
ic DT based syst[Switching to LWP 3740]
em
[15924.175488] [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[15924.175515] [] (show_stack) from [] (dump_stack+0x90/0xa4)
[15924.175546] [] (dump_stack) from [] (__do_user_fault+0x130/0x134)
[15924.175573] [] (__do_user_fault) from [] (do_page_fault+0x240/0x348)
[15924.175600] [] (do_page_fault) from [] (do_DataAbort+0x4c/0xec)
[15924.175626] [] (do_DataAbort) from [] (__dabt_usr+0x3c/0x40)
[15924.175643] Exception stack(0xdc077fb0 to 0xdc077ff8)
[15924.175664] 7fa0: 8ce25000 8c9dc040 0000ab20 00000000
[15924.175686] 7fc0: 0000ab20 8cd0bdc0 8ce25000 a14e1ca8 0000a860 8cd0bed4 8c9da9e0 0000ab20
[15924.175706] 7fe0: 8ce25000 8c9da944 a13fea50 96d2f140 200d0010 ffffffff
0x96d2f140 in ?? () from /lib/libc.so.6
(gdb) ========== app:[rvrpem] online ==========

(gdb) bt
#0 0x96d2f140 in ?? () from /lib/libc.so.6
#1 0xa13fea50 in jpegd_prepare () from /usr/lib/librockchip_mpp.so.1
#2 0x8cd062e0 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

Hello.

I'm building mpp into a Qt program and facing difficulties while importing the necessary header files. I'm building my program on a Linux distribution and the media library struggles to find header files located in other folders of the library.

Here is a picture illustrating what I am talking about.

My code finds every header file, but the header files can't find other header files that are not located in the same folder. As shown in the picture, mpp-develop\mpp\base\mpp_buf_slot.cpp is looking for mpp_log.h, but it crashes since it is not in the same folder.

So, what is actually the correct way of handling the library files? Where do I place the folders from this API?

Using latest compiled mpp of 19 Dec on RK3328 Android:

When I try to play a H265 1280x720p video inside a .TS container file then SPMC 17.6a2 just shows a black screen. Looking at the logs, it seems it fails to play with MediaCodec.
http://download.semperpax.com/spmc/android-aarch64/SPMC-spmc-krypton-4993870-aarch64.apk

Playing the same file on Kodi 18 nightly has no problems and plays fine with MediaCodec acceleration.

Is there something that can be changed/fixed in mpp or maybe SPMC's side perhaps?
Kodi 18 has lots of bugs like mouse support not working correct in 4K and also displaying GUI in 4K instead of 1080p(since frame buffer only support 1080p) resulting in menus looking corrupt while 4K video is playing. SPMC doesn't have any of these bugs that is why I try with it instead.

When I play a mpeg2 inside a .TS file, it plays fine in SPMC.

Kodi 18 log(working)
https://pastebin.com/PRpuYcyB
SPMC 17.6a2 log(not working)
http://pasted.co/ae8fe0c5

Sample video - http://www.elecard.com/assets/files/other/clips/bbb_720p_c.ts

Lots of .TS videos that are not mpeg2, are hevc or h264 in .TS files also don't play on Android with SPMC Kodi using latest compiled mpp files but work fine in Kodi 18.

When I use the following mpp then .TS files can all play in SPMC but have no support for deinterlacing.
Is source code available for this mpp, I just want to fix deinterlacing support in it, then it can perhaps still work with .TS files with SPMC?
Thu Oct 26 09:52:40 2017 +0800
e1cfd07 author: Xuhanrui
libmpp.so 2.6MB (double file size)

Thanks

I am having trouble running mpp on RK3328. OS: Ubuntu 18.04.5 LTS. I have been runing different versions of mpp, but no one seems to work in my situation. I have runned some of the examples located in the /test folder. Here is a picture of my results after installing the latest develop branch from this fork and running mpi_test. Here is also an issue I think is related, rockchip-linux/mpp#182.

运行命令解码input13.jpeg，mpi_dec_test -i input13.jpeg -t 8 -o t3.yuv -w 1920 -h 1080
提示错误:HAL_JPEG_VDPU2: hal_jpegd_vdpu2_wait IRQ STREAM ERROR!
input13.jpeg.zip

如题

HI,

i'm trying to enable smart GOP but cannot find how to do so. It seems that setting the gop_mode to 4 should enable this feature but then what should be the values of gop_len and vi_len ? Where is this feature documented ?

Thanks

[h264e_vepu580]: Add dpb hal func and more buffer
这一个实现也应该在h264e_vepu541上面类似实现，不然在rv1126上update_vepu541_syntax函数会执行default条件了，就会一直打印mpp_log_f("invalid syntax type %d\n", desc->type);

Hi,

Which kernel implements the VPU_IOC_WRITE ioctl that is being used in this library.

I couldn't find it in the rockchip-linux/kernel (tried different branches).

Could someone throw some light?

Thanks,
San

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.
Is there a solution perhaps as lots of anime videos are in 10-bit and it would be nice to have support for it.

Thanks

hardware: RK3328-PC
os: Android 7.1
problem: all of the mpp_log mpp_err can not print, no log output.

so I have to change

#ifdef mpp_err
#undef mpp_err
#endif
#define mpp_err printf

#ifdef mpp_log
#undef mpp_log
#endif
#define mpp_log printf

and the printf can print success.

how should I use mpp_log?

Repo https://github.com/rockchip-linux/mpp currently get "Page 404", is it deleted or hidden?
Do this two repo have same contents?

Hi,

i have issue getting a good FPS out of a video pipeline that encode video acquired through the ISP. The RAW images are acquired through the v4l2 driver for the ISP and then sent to the MPP encoder. Is there a way to do encoding straight from the ISP without the raw video data ever going to userspace ?

Thanks

PS: why did the mpp repository on linux-rockchip was removed ?

irefly@firefly:~/mpp-release/build/linux/aarch64/test$ sudo mpi_enc_test -t 7 -w 640 -h 272 -i ds_480x272.yuv -o t.h264 -f 4
mpi_enc_test: cmd parse result:
mpi_enc_test: input file name: ds_480x272.yuv
mpi_enc_test: output file name: t.h264
mpi_enc_test: width : 640
mpi_enc_test: height : 272
mpi_enc_test: format : 4
mpi_enc_test: type : 7
mpi_enc_test: debug flag : 0
mpi_enc_test: mpi_enc_test start
mpp_rt: NOT found ion allocator
mpp_rt: found drm allocator
mpi_enc_test: mpi_enc_test encoder test start w 640 h 272 type 7
mpi: mpp version: Without VCS info
mpi_enc_test: mpi_enc_test bps 652800 fps 30 gop 60
h264e_api: h264e_config MPP_ENC_SET_RC_CFG bps 652800 [612000 : 693600]
mpi_enc_test: test_mpp_run encoded frame 0 size 0
mpi_enc_test: test_mpp_run encoded frame 1 size 0
mpi_enc_test: test_mpp_run encoded frame 2 size 0
mpi_enc_test: test_mpp_run encoded frame 3 size 0
mpi_enc_test: test_mpp_run encoded frame 4 size 0
mpi_enc_test: test_mpp_run encoded frame 5 size 0
mpi_enc_test: test_mpp_run encoded frame 6 size 0
mpi_enc_test: test_mpp_run encoded frame 7 size 0
mpi_enc_test: test_mpp_run encoded frame 8 size 0
mpi_enc_test: test_mpp_run encoded frame 9 size 0
mpi_enc_test: test_mpp_run encoded frame 10 size 0

在Rock pi 3A(RK3568)上，跑 mpp_dec_test 失败，提示：
mpp[39110]: vcodec_service: open vcodec_service /dev/mpp_service failed
存在/dev/mpp_service设备节点，请问是什么原因呢？

rock@rock-3a:~/work/test$ ./mpi_dec_test -t 7 -w 1920 -h 1080 -i /work/test_1080.264
mpp[39110]: mpp_opt: setup:real node 18:22 info 11:11
mpp[39110]: mpi_dec_utils: input file /home/rock/work/test_1080.264 size 98864264
mpp[39110]: mpi_dec_utils: cmd parse result:
mpp[39110]: mpi_dec_utils: input file name: /home/rock/work/test_1080.264
mpp[39110]: mpi_dec_utils: output file name:
mpp[39110]: mpi_dec_utils: width : 1920
mpp[39110]: mpi_dec_utils: height : 1080
mpp[39110]: mpi_dec_utils: type : 7
mpp[39110]: mpi_dec_utils: max frames : 0
mpp[39110]: mpi_dec_test: mpi_dec_test start
mpp[39110]: mpp_info: mpp version: 8a85dc5 author: Herman Chen 2022-03-14 [mpp_enc]: Fix stuck on reset async mode encoder
mpp[39110]: mpi_dec_test: 0x55ad428860 mpi_dec_test decoder test start w 1920 h 1080 type 7
mpp[39110]: mpp_rt: NOT found ion allocator
mpp[39110]: mpp_rt: found drm allocator
mpp[39110]: vcodec_service: open vcodec_service /dev/mpp_service failed
mpp[39110]: hal_h264d_api: mpp_dev_init failed ret: -1
mpp[39110]: mpp_hal: mpp_hal_init hal h264d_rkdec init failed ret -1
mpp[39110]: mpp_hal: mpp_hal_init could not found coding type 7
mpp[39110]: mpp_dec: mpp_dec_init could not init hal
mpp[39110]: mpp_time: mpp_clock_put invalid clock (nil)
mpp[39110]: mpp_time: mpp_clock_put invalid clock (nil)
mpp[39110]: mpp_time: mpp_clock_put invalid clock (nil)
mpp[39110]: mpp_time: mpp_clock_put invalid clock (nil)
mpp[39110]: mpp_time: mpp_clock_put invalid clock (nil)
mpp[39110]: mpp_time: mpp_clock_put invalid clock (nil)
mpp[39110]: mpp_time: mpp_clock_put invalid clock (nil)
mpp[39110]: mpp_time: mpp_clock_put invalid clock (nil)
mpp[39110]: mpp_time: mpp_clock_put invalid clock (nil)
mpp[39110]: mpp_time: mpp_clock_put invalid clock (nil)
mpp[39110]: mpp_time: mpp_clock_put invalid clock (nil)
mpp[39110]: mpp: error found on mpp initialization
mpp[39110]: mpi_dec_test: 0x55ad428860 mpp_init failed
mpp[39110]: mpi_dec_test: test failed ret -1
mpi_dec_test[39110]: mpp_mem_pool: put_pool found 1 used buffer size 80
mpi_dec_test[39110]: mpp_mem_pool: put_pool found 4 used buffer size 192
rock@rock-3a:/work/test$