rockchip-linux / mpp Goto Github PK
View Code? Open in Web Editor NEWMedia Process Platform (MPP) module
Media Process Platform (MPP) module
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/ffmpeg_rtsp_mpp https://github.com/nyanmisaka/ffmpeg-rockchip 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 | | | | | | | |----- dummy decoder parser work flow sample | | | | | | | |----- h263 | | | | | | | |----- h264 | | | | | | | |----- h265 | | | | | | | |----- m2v mpeg2 parser | | | | | | | |----- mpg4 mpeg4 parser | | | | | | | |----- vp8 | | | | | | | |----- vp9 | | | | | | | |----- jpeg | | | | | |----- enc | | | | | |----- dummy encoder controllor work flow sample | | | | | |----- h264 | | | | | |----- h265 | | | | | |----- jpeg | | | |----- hal Hardware Abstract Layer (HAL): modules used in mpi | | | | | |----- inc header files provided by hal for external usage | | | | | |----- iep iep user library | | | | | |----- pp post-processor user library | | | | | |----- rga rga user library | | | | | |----- deinter deinterlace function module including pp/iep/rga | | | | | |----- 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 | | | | | |----- vpu vpu register generation library | | | | | |----- h263d generate register file from H.263 syntax info | | | | | |----- h264d generate register file from H.264 syntax info | | | | | |----- h265d generate register file from H.265 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 | | | |----- 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: +---------------------------------------+ | | | ffmpeg / 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 ffmpeg. +-------------------+ | | | 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.
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?
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
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
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.
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?
- 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文件系统中编译
注释掉
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:
## 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*)
# 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:
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.
#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)
#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)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.