I have a new re-written ffmpeg at https://github.com/hbiyik/FFmpeg and i would appreciate any kind of testing.
Wiki is at:
Supported Hardware Encoders with Output Scaling:
H264, HEVC/H265, VP8
Supported Hardware Decoders:
H263, H264, HEVC/H265, AV1, vp8, vp9, mpeg1, mpeg2, mpeg4
Would appreciate any form of test report at https://github.com/hbiyik/FFmpeg/issues/14
PS: This should also theoretically work on other rockchip socs, but i dont have any of them so i can not test
alright, I checked out your git, I did modify the configure line a little from your wiki however:
./configure --enable-rkmpp --enable-version3 --enable-lib
drm --enable-nonfree --enable-gpl --enable-version3 --enable-libx264 --enable-librtmp --enable-shared --enable-static --enable-libx265 --enable-libmp3lame --enable-libpulse --enable-openssl --enable-libopus --enable-libvorbis --enable-libaom --enable-libass --enable-libdav1d --enable-libx265 --enable-libvpx
I used that configure line because i also used it for jjm2473’s fork of rkmpp enabled ffmpeg, so i have a comparison. the build went on clean, no errors from the first try on, however a warning during linking.
After build it complained about missing libavdevice.so.60 on first try(ffmpeg --encoder) - I found it in the libavdevice subfolder of your git pull. After that it comlained about all the rest of the common libs being missing one by one. simple guess would be that I didnt install ffmpeg. after adjusting my LD_LIBRARY_PATH for testing ffmpeg loads.
so far so good. ffmpeg -encoders | grep rk lists the h264, hevc and vp8 encoders
ffmpet -decoders | grep rk lists h263, h264, hevc, mpeg1/2/4, vp8 and vp9 hardware decoders. I’m starting to like this.
Now lets give it a try - the goal is to trancsode.
./ffmpeg -i in.mkv -c:v hevc -c:a copy /extern/nn.hevc.mp4
and i get a segfault. same goes when trying to encode to h264
EDIT: I tried a clean build with the configure line from the git repos wiki, but i also keep getting segfault when trying to transcode a video, doesnt matter whether i transcode to h264 or hevc. Input in all cases has been h264 full hd
As for the linker warning, this is what i get:
LD ffprobe_g /usr/bin/ld: /lib/aarch64-linux-gnu/libtirpc.so.3: warning: common of rpc_createerr@@GLIBC_2.17’ overridden by definition from /lib/aarch64-linux-gnu/libc.so.6
/usr/bin/ld: /lib/aarch64-linux-gnu/libtirpc.so.3: warning: common of rpc_createerr@@GLIBC_2.17' overridden by definition from /lib/aarch64-linux-gnu/libc.so.6 /usr/bin/ld: /lib/aarch64-linux-gnu/libtirpc.so.3: warning: common of rpc_createerr@@GLIBC_2.17’ overridden by definition from /lib/aarch64-linux-gnu/libc.so.6
STRIP ffplay
`
Tiny attachment: I had installed a current mpp, however that got installed into /usr/local/lib and the system mpp was used instead. turns out your ffmpeg isnt compatible with the mpp that comes from radxas repo. a simple override using LD_LIBRARY_PATH fixed that issue, and the segfault is gone. Might be worth adding that to the wiki.
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.
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
please make sure that you update ffmpeg repo as well, a lot of small things has been fixed recently.
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?
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
@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.
@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.
regards
uli
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.
@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?
@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
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.