03-29-2017, 08:43 AM
Hello.
I prepared and tested some application to test low level access video decoders (attached) for everyone interested
.
Decoder results first (and @end) witch CPU load <20%:
This demo is for lowlevel API rockchip MPI/MPP with zero copy output to DRM and display as DRM FB overlay plane with ASUS Tinker (and other) without Xserver directly from console. MPP is low level API for ffmpeg/OpenMax/gstreamer/libva.
TinkerBoard/RK3288 has two video coprocessors VPU1 (for h264 and other decoders and encoders) (/dev/vpu-service) and HEVC_DEC (for HEVC decoder) (/dev/hevc-service).
MPP is https://github.com/rockchip-linux/mpp works on [https://github.com/rockchip-linux/mpp/bl...ard/RK3288[/url].
This demo uses MPP buffers (frames) "Mode 3: Pure external mode" with zero copy DRM buffers. DRM (/dev/dri/card0) is used with some problems (see patch).
DRM buffers works in "Commit flow group" DRM buffes mode.
The demo use "Split standard mode". Warning - do not use "advanced mode" works only with MJPEG now.
0) prepare board / download os
I used ASUS Tinker Board with TinkerOS_Debian V1.4 (https://www.asus.com/uk/Single-board-Com..._Download/).
Many build dependencies like autoconf automake libdrm-dev libtool cmake git ...
1) build MPP not needed in most newer distributions, already installed
(installed in /usr/local/...)
2) build application (mpi_dec)
3) prepare h264 and/or hevc(h265) raw streams
4) test it
NOTES:
CPU:
- RK CPU power management is active (interactive mode) and CPU very slow reacts to load it leads to drops frame due to high CPU loads peaks.
SEE:
grep '' /sys/devices/system/cpu/cpufreq/policy0/*
TEST:
echo userspace > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
echo 216000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed
./mpi_dec 4k.hevc 16777220
and compute frame rate "FRAME 57157.321400 first 43613795 previous 1253 frid 2024" == frameid/first(usec) = 2024/43.613795 = 46 FPS
RESULTS (4k.hevc):
Be aware of CPU power management, it has negative impact on FPS (scaling_min_freq is 0.1GHz by default).
Fix CPU to 0.4GHz or higher like:
echo userspace > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
echo 1008000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed
OR:
echo interactive > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
echo 1008000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
DECODER:
- decoder running at maximum realtime speed (eg. no clock synchronization from sources) and DRM FB displays at vsync rate (eg. some decoded frames are dropped/skipped).
RESULTS (with fixed 1GHz CPU):
Happy hacking,
M.C>
I prepared and tested some application to test low level access video decoders (attached) for everyone interested

Decoder results first (and @end) witch CPU load <20%:
Code:
hevc(h265) h264
2k (1080p, FHD) 240 FPS 69 FPS
4k (2160p, UHD) 71 FPS 32 FPS
This demo is for lowlevel API rockchip MPI/MPP with zero copy output to DRM and display as DRM FB overlay plane with ASUS Tinker (and other) without Xserver directly from console. MPP is low level API for ffmpeg/OpenMax/gstreamer/libva.
TinkerBoard/RK3288 has two video coprocessors VPU1 (for h264 and other decoders and encoders) (/dev/vpu-service) and HEVC_DEC (for HEVC decoder) (/dev/hevc-service).
MPP is https://github.com/rockchip-linux/mpp works on [https://github.com/rockchip-linux/mpp/bl...ard/RK3288[/url].
This demo uses MPP buffers (frames) "Mode 3: Pure external mode" with zero copy DRM buffers. DRM (/dev/dri/card0) is used with some problems (see patch).
DRM buffers works in "Commit flow group" DRM buffes mode.
The demo use "Split standard mode". Warning - do not use "advanced mode" works only with MJPEG now.
0) prepare board / download os
I used ASUS Tinker Board with TinkerOS_Debian V1.4 (https://www.asus.com/uk/Single-board-Com..._Download/).
Many build dependencies like autoconf automake libdrm-dev libtool cmake git ...
1) build MPP not needed in most newer distributions, already installed
Code:
# git clone https://github.com/rockchip-linux/mpp.git
# cd mpp
# ### partch not neede now ## git apply ../mpp_for_tinkeros_drm.patch
# cmake -DRKPLATFORM=ON -DHAVE_DRM=ON -DCMAKE_BUILD_TYPE=Debug .
# make -j4
# make install
(installed in /usr/local/...)
2) build application (mpi_dec)
Code:
make
3) prepare h264 and/or hevc(h265) raw streams
Code:
ffmpeg -i bbb_sunflower_2160p_30fps_normal.mp4 -c:v copy -an -bsf:v h264_mp4toannexb 4k.h264
ffmpeg -i bbb-1920x1080-cfg06.mkv -c:v copy -an -bsf:v hevc_mp4toannexb 2k.hevc
ffmpeg -i bbb-3840x2160-cfg02.mkv -c:v copy -an -bsf:v hevc_mp4toannexb 4k.hevc
4) test it
Code:
./mpi_dec
./mpi_dec "filename" "type"
./mpi_dec 4k.h264 7
./mpi_dec 2k.hevc 16777220
NOTES:
CPU:
- RK CPU power management is active (interactive mode) and CPU very slow reacts to load it leads to drops frame due to high CPU loads peaks.
SEE:
grep '' /sys/devices/system/cpu/cpufreq/policy0/*
TEST:
echo userspace > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
echo 216000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed
./mpi_dec 4k.hevc 16777220
and compute frame rate "FRAME 57157.321400 first 43613795 previous 1253 frid 2024" == frameid/first(usec) = 2024/43.613795 = 46 FPS
RESULTS (4k.hevc):
Code:
freqency GHz 0.1 0.2 0.4 0.8 1.0 1.2
CPU load % <65 <60 <30 <20 <16 <14
FPS 36 46 62 68 71 72
TEMPERATURE C ~55 ~60 ~62
Be aware of CPU power management, it has negative impact on FPS (scaling_min_freq is 0.1GHz by default).
Fix CPU to 0.4GHz or higher like:
echo userspace > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
echo 1008000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed
OR:
echo interactive > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
echo 1008000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
DECODER:
- decoder running at maximum realtime speed (eg. no clock synchronization from sources) and DRM FB displays at vsync rate (eg. some decoded frames are dropped/skipped).
RESULTS (with fixed 1GHz CPU):
Code:
hevc(h265) h264
2k (1080p, FHD) 240 FPS 69 FPS
4k (2160p, UHD) 71 FPS 32 FPS
Happy hacking,
M.C>