Updated FFMpeg with mpp

@boogiepop
Hi, perhaps you have also came across this mpp, ffmpeg problem with H265 playback with rkmpp ffmpeg DRMPrime playback on GBM Kodi?

H265 videos play with a shaking and slow motion.
When you press ‘o’ it shows it is using rkmpp ffmpeg DRMPrime codec.
You must enable DRMPrime Rendering first in Kodi Video Settings otherwise it will use software decoding by default.

Here is an image you can test.


Press Start on a gamepad to Select Kodi.

MPP used, mpp has been updated by Rockchip in the meantime


FFMpeg used

Patch that added hw decoding for RK3588 devices to Batocera Linux

I think it only affects GBM and not X11 since Rockchip couldn’t reproduce the problem with MPP on X11.
Do you know how to fix or or report it to the correct people?

1 Like

@mo123 it plays fine on my setup, my ffmpeg is totally different than yours but drm prime part should be the same. Do you have this for every file, can you send me a sample vid that you have this issue. And are you on 3588 or something else?

I’m on Rock5B.
H264, AV1, Mpeg2, VP9 doesn’t have problems, only H265 videos on GBM Kodi.
I’ll see if I can post a Kodi log later.

1 Like

why not pull back to ffmpeg master to enable ffmpeg support rk hw?

Because ffmpeg dropped rkmpp for licensing issues in the first place

Hello Everyone,

After months of work, i think this is the best this decoder can do with this kernel and panfork.
In above branch you can find the latest updated decoder where you can 8k@60fps HDR for hevc and h264, 8k@30fps for vp8/9 and 4k@60for AV1.

to test it with mpv run with

mpv --hwdec=rkmpp pathtofile
note: you might need to use latest mpv from git, otherwise you might get false positives like
Mapped surface with format 'nv12' has unexpected number of planes. (0 layers and 0 planes, but expected 2 planes), please use latest from git

to use it with kodi, run kodi with:
kodi.bin --windowing=gbm --audio-backend=alsa

make sure you select

settings->player->videos->render method
Allow using DRM PRIME Decoder=enable
Allow Hardware Acceleation with DRM PRIME=enable
Prime Render Method=EGL

and below is a demo showcase of 8k@60fps HDR file being played with mpv

https://streamable.com/e/kk2zm4

Known Issues:
Encoder is not working in this branch
When libyuv conversion is active there is 1 pixel of green line at top
Error handling is not the best, it might segfault when unexpected things happen.
NV20 is not yet supported but can easily be adopted.

Any test and feedback is wellcome.

Are you rendering the 8k on 1920x1080 video output?

Yes through egl

right, i have been following your progress. My setup is libmali X11 (dual head), in theory is ‘twice’ slower than wayland but is enough to compare the results and give you some feedback.Keep the good work! You and Nyan.

1 Like

Testing jellyfish-200-mbps-8k-uhd-hevc-10bit.mkv:

Input #0, matroska,webm, from '/apps/videos_rknn/jellyfish-200-mbps-8k-uhd-hevc-10bit.mkv':
  Metadata:
    MINOR_VERSION   : 1
    COMPATIBLE_BRANDS: iso4hvc1iso6
    MAJOR_BRAND     : iso4
    ENCODER         : Lavf60.3.100
  Duration: 00:00:30.03, start: 0.000000, bitrate: 200189 kb/s
  Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, progressive), 7680x4320 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 1k tbn (default)
    Metadata:
      HANDLER_NAME    : hevc@GPAC0.5.2-DEV-rev565-g71748d7-ab-suite
      ENCODER         : Lavc60.3.100 hevc_nvenc
      DURATION        : 00:00:30.030000000
[hevc_rkmpp_decoder @ 0x7f74007d00] Using partial libyuv soft conversion for yuv420p10le (7680x4320)
[hevc_rkmpp_decoder @ 0x7f74007d00] Pixfmt (yuv420p10le), Conversion (nv15[FBC]->p010le->yuv420p10le[LIBYUV])
rga_api version 1.8.1_[5] 0 aq=    0KB vq=15076KB sq=    0B f=0/0   
 125.95 M-V:  0.112 fd= 395 aq=    0KB vq=    0KB sq=    0B f=0/0   

Is this expected?

yes, to use p010 format you need this fix in the kernel, and this fix in rgamulti

i would suggest to use P010 instead of yuv420p10, p010 (FFMPEG_RKMPP_PIXFMT=p010 env variable) is much faster.

which librga sources do you use?

Ah yeah rgamulti also needs to be fixed with a patch. I edited the previous comment with the links for completeness.

Now it’s fine.

FFMPEG_RKMPP_PIXFMT=p010  DISPLAY=:0.0 ./ffplay /apps/videos_rknn/jellyfish-200-mbps-8k-uhd-hevc-10bit.mkv 
ffplay version 2bcff74 Copyright (c) 2003-2023 the FFmpeg developers
  built with gcc 11 (Ubuntu 11.4.0-1ubuntu1~22.04)
  configuration: --prefix=/usr --disable-libopenh264 --disable-vaapi --disable-vdpau --disable-decoder=h264_v4l2m2m --disable-decoder=vp8_v4l2m2m --disable-decoder=mpeg2_v4l2m2m --disable-decoder=mpeg4_v4l2m2m --disable-libxvid --disable-libx264 --disable-libx265 --enable-rkmpp --enable-nonfree --enable-gpl --enable-version3 --enable-libmp3lame --enable-libpulse --enable-libv4l2 --enable-libdrm --enable-libxml2 --enable-librtmp --enable-libfreetype --enable-openssl --enable-opengl --enable-libopus --enable-libvorbis --disable-shared --enable-decoder='aac,ac3,flac' --extra-cflags=-I/usr/src/linux-headers-5.10.110-rk3588-v4l2/include --disable-cuvid
  libavutil      58.  2.100 / 58.  2.100
  libavcodec     60.  3.100 / 60.  3.100
  libavformat    60.  3.100 / 60.  3.100
  libavdevice    60.  1.100 / 60.  1.100
  libavfilter     9.  3.100 /  9.  3.100
  libswscale      7.  1.100 /  7.  1.100
  libswresample   4. 10.100 /  4. 10.100
  libpostproc    57.  1.100 / 57.  1.100
arm_release_ver: g13p0-01eac0, rk_so_ver: 9
Input #0, matroska,webm, from '/apps/videos_rknn/jellyfish-200-mbps-8k-uhd-hevc-10bit.mkv':
  Metadata:
    MINOR_VERSION   : 1
    COMPATIBLE_BRANDS: iso4hvc1iso6
    MAJOR_BRAND     : iso4
    ENCODER         : Lavf60.3.100
  Duration: 00:00:30.03, start: 0.000000, bitrate: 200189 kb/s
  Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, progressive), 7680x4320 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 1k tbn (default)
    Metadata:
      HANDLER_NAME    : hevc@GPAC0.5.2-DEV-rev565-g71748d7-ab-suite
      ENCODER         : Lavc60.3.100 hevc_nvenc
      DURATION        : 00:00:30.030000000
[hevc_rkmpp_decoder @ 0x7f5c007d00] Pixfmt (p010le), Conversion (nv15[FBC]->p010le)
rga_api version 1.9.3_[2] 0 aq=    0KB vq=15891KB sq=    0B f=0/0   

Can you share your 8k@60fps HDR file so i can see how smooth this is on ffplay?

dont use ffplay if you want to test HDR files, because ffplay forces output to yuv420p and can not handle 10bit output. You can test sdr files though.

To test HDR, use something like mpv or kodi.

Some 8k files (hdr & sdr):
https://drive.google.com/drive/folders/1TSdV36G_npDtjRJze54GEYpdxpBt7nCK
Jellyfish 8k files (hdr):
https://drive.google.com/drive/folders/1rKpr5soXvwx65v3fEDCOsXwmiWERz6xH?usp=sharing

mpv also requires below fixes to play drm_prime properly. I mainlined NV16 part, but p010 should be missing in the mainline mpv.

From 504b2de386bffc0746c243b5f937fb0c5b7c4447 Mon Sep 17 00:00:00 2001
From: hbiyik <boogiepop@gmx.com>
Date: Thu, 28 Sep 2023 22:25:25 +0200
Subject: [PATCH 1/2] hwdec_drmprime: add nv16 support

NV16 is the half subsampled version of NV12 format. Decoders which
support High 4:2:2 of h264 provide the frame in NV16 format to establish
richer colorspace. Similar profiles are also available in HEVC and other
popular codecs. This commit allows NV16 frames to be displayed over
drmprime layers.

Signed-off-by: hbiyik <boogiepop@gmx.com>
---
 video/out/hwdec/dmabuf_interop_gl.c | 1 +
 video/out/hwdec/hwdec_drmprime.c    | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/video/out/hwdec/dmabuf_interop_gl.c b/video/out/hwdec/dmabuf_interop_gl.c
index bd33474289..e7fb1031a0 100644
--- a/video/out/hwdec/dmabuf_interop_gl.c
+++ b/video/out/hwdec/dmabuf_interop_gl.c
@@ -176,6 +176,7 @@ static bool vaapi_gl_map(struct ra_hwdec_mapper *mapper,
         if (p_mapper->desc.layers[i].nb_planes > 1) {
             switch (p_mapper->desc.layers[i].format) {
             case DRM_FORMAT_NV12:
+            case DRM_FORMAT_NV16:
                 format[0] = DRM_FORMAT_R8;
                 format[1] = DRM_FORMAT_GR88;
                 break;
diff --git a/video/out/hwdec/hwdec_drmprime.c b/video/out/hwdec/hwdec_drmprime.c
index 5051207413..290f11c535 100644
--- a/video/out/hwdec/hwdec_drmprime.c
+++ b/video/out/hwdec/hwdec_drmprime.c
@@ -29,6 +29,7 @@
 
 #include "libmpv/render_gl.h"
 #include "options/m_config.h"
+#include "video/fmt-conversion.h"
 #include "video/out/drm_common.h"
 #include "video/out/gpu/hwdec.h"
 #include "video/out/hwdec/dmabuf_interop.h"
@@ -117,6 +118,7 @@ static int init(struct ra_hwdec *hw)
     int num_formats = 0;
     MP_TARRAY_APPEND(p, p->formats, num_formats, IMGFMT_NV12);
     MP_TARRAY_APPEND(p, p->formats, num_formats, IMGFMT_420P);
+    MP_TARRAY_APPEND(p, p->formats, num_formats, pixfmt2imgfmt(AV_PIX_FMT_NV16));
     MP_TARRAY_APPEND(p, p->formats, num_formats, 0); // terminate it
 
     p->hwctx.hw_imgfmt = IMGFMT_DRMPRIME;
-- 
2.42.0


From 76a34a8f31fd69094adef09c4b2146da7a842a10 Mon Sep 17 00:00:00 2001
From: boogie <boogiepop@gmx.com>
Date: Wed, 1 Nov 2023 20:35:19 +0100
Subject: [PATCH 2/2] hwdec_drmprime: add p010 support

Removes the limitation that P010 DRMPrime Avframes were filtered out

Signed-off-by: hbiyik <boogiepop@gmx.com>
---
 video/out/hwdec/hwdec_drmprime.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/video/out/hwdec/hwdec_drmprime.c b/video/out/hwdec/hwdec_drmprime.c
index 290f11c535..9c63ab49ff 100644
--- a/video/out/hwdec/hwdec_drmprime.c
+++ b/video/out/hwdec/hwdec_drmprime.c
@@ -119,6 +119,7 @@ static int init(struct ra_hwdec *hw)
     MP_TARRAY_APPEND(p, p->formats, num_formats, IMGFMT_NV12);
     MP_TARRAY_APPEND(p, p->formats, num_formats, IMGFMT_420P);
     MP_TARRAY_APPEND(p, p->formats, num_formats, pixfmt2imgfmt(AV_PIX_FMT_NV16));
+    MP_TARRAY_APPEND(p, p->formats, num_formats, pixfmt2imgfmt(AV_PIX_FMT_P010));
     MP_TARRAY_APPEND(p, p->formats, num_formats, 0); // terminate it
 
     p->hwctx.hw_imgfmt = IMGFMT_DRMPRIME;
-- 
2.42.0

Isn’t this hdr? the colors will be wrong in ffplay?

yes, 10bit=hdr, colors will be downsampled to 8bit on cpu with ffplay. Unless you dont have an HDR display you wont see a difference but the problem is ffplay does this conversion purely on cpu, it kills the performance.

best you can get out of ffplay is

FFMPEG_RKMPP_PIXFMT=yuv420p ffplay pathtohdrfile.mp4

This will convert the HDR to SDR using RGA+libyuv so you wont waste performance on CPU.

FFplay simply can not HDR.

got it. 450% cpu usage.

in which case? ffplay’s internal conversion?