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.
Hello, I am with BreadOS, former RebornOS, and Arch…
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.
@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…
Hello, problem resolved.
After deinstallation of mpv.chromaprint, strawberry ffmpeg-mpp builds.
Installing mpv,strawberry,chromaprint again makes it work.
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
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.
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
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?
@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.
why not pull back to ffmpeg master to enable ffmpeg support rk hw？
Because ffmpeg dropped rkmpp for licensing issues in the first place
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
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.
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_ 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?
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_ 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):
Jellyfish 8k files (hdr):