Updated FFMpeg with mpp

#3

weird, i have a feeling this is caused from external issues rather than ffmpeg.

what is the version of the librga you use? what is the version of libyuv u use? what is version mpp you use?

could you parse the output of

ls -la /dev/dma_heap/
groups
and finally dmesg.

and finally last resort: could you compile with --disable-stripping configure option, and after the segfault happens, execute coredumpctl gdb and when the app opens type bt full. This requires gdb to be installed and will pinpoint exactly where it is crashing. A little bit tricky and if we cant solve it, this can help as a final resort.

#4

as I just edited, I had mpp built from git, but it was installed to /usr/local/lib so ffmpeg tried to use the radxa-supplied one. Overriding that with LD_LIBRARY_PATH=/usr/local/lib fixed the issue, and i am doing a first test transcode. So far, at least ffmpeg seems to adhere to the requested bitrate, unlike the one from jjm2473 - fps is 70 for 1080p mp4 input and hevc output

1 Like
#5

please make sure that you update ffmpeg repo as well, a lot of small things has been fixed recently.

#6

Hello and thanks for trying to give us the right to use ffmpeg (gstreamer sucks).
Do you have any idea if rkmpp decoder will ever be able to report frame types (I, P, B)? Currently and with anything (ffmpeg) I’ve tested so far, all are (un)known as PICT_TYPE=?
And also encoder to encode B-frames, what could already be expected of a modern hw encoder like 10 years ago?
Or I missed something maybe?

#7

Hello, I am with BreadOS, former RebornOS, and Arch…
Your current ffmpeg-mpp 2:6.06 with Aur does not build, due to missing dependencies.
Any chance to get an updated version sometime?
Thanks for your good work.
Regards
Uli
Hello,
Since some time ffmpeg-mpp, ffmpeg4.4-mpp expired from AUR.
iI this due to a new ffmpeg version ?
Can I get ffmpeg-mpp in AUR back ?
I feeel that kodi is not anylonger running that smooth.
Kind regards
Uli

#9

@zoelechat
Normally mpp has the frame classificiation, but it does not expose this information to external libraries, thats why none of mpp implementation have the frame types classified including mine. My understanding to tell if a frame B, I or P is purely for diagnostic purposes, why are you interested in this info from a decoder, my be we can request from Mpp maintainers to expose the api.
image

@Uli_Beling it compiles on my arch, my be you can post your error log in the archlinux thread so i can give it a look, i assume it is some funny missing package in BredOS. But please, none of the new features in this repo is available in ARCH package, i am currently testing those new stuff, when i am satisfied with it i will also release this to arch packages as well…

#10

Hello, problem resolved.
After deinstallation of mpv.chromaprint, strawberry ffmpeg-mpp builds.
Installing mpv,strawberry,chromaprint again makes it work.
regards
uli

#11

Mostly to be able to use the -skip_frame (nokey, nointra…) input switch of ffmpeg. For example to make a timelapse and keep only the “best quality” (=I) frames.
In my case from an outdoor cam where I can adjust I-frame interval (therefore timelapse speed, dynamically, without need to restart ffmpeg), ending in a much more timer-accurate result than relying on how ffmpeg deals with VBR input :slight_smile:

#12

woah, it is always amusing me how everyone is using ffmpeg differently, i will try to ask mpp people if they could expose this information. I could actually do it myself but it would be quite ugly and not future maintainable.

1 Like
#13

@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
#14

@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?

#15

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
#16

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

#17

Because ffmpeg dropped rkmpp for licensing issues in the first place

#18

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.

#19

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

#20

Yes through egl
…

#21

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
#22

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

jellyfish-8k
jellyfish-8k.jpeg1920×1080 985 KB 

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?

#23

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.