• Content Count

  • Joined

  • Last visited

About Kwiboo

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I have not synced any possible update from @jernej or the Raspberry Pi team yet, the latest ffmpeg that works with the cedrus/hantro patches we use in LibreELEC is located at That version is still not compatible with the rkvdec driver targeted for 5.7 due to incompatible use of flags, I will update the ffmpeg code to work with both hantro and rkvdec when I rebase my patches for 5.6. The main diff between upstream hantro and the patches we use in LibreELEC is support for field encoded (interlaced) H264. The ffmpeg v4l2 request api hwaccel is not yet upstreamed and the main reason is that it depends on private kernel headers not yet part of the uapi.
  2. Yes, I have had VPU working on 5.4 kernel since the new year started, my test images from 31 dec / 1 jan at should "work", at least for MPEG-2, H264 and VP8 codecs on RK3288, RK3328 and RK3399. The VPU patchset used in LibreELEC has not been touched/rebased for 5.5/5.6 yet, but I am hoping to get some time to work on that later this weekend and next week.
  3. @usual user thanks, I have updated the ffmpeg branch and updated my post to reflect the correct --enable-libudev should apply clean on latest FFmpeg master, there may be some v4l2 commits in v5.5 that may be required for the ffmpeg branch to compile on linux v5.4, I forgot about them. or should contain the patches needed for build on v5.4, the Allwinner patch is less intrusive, for Rockchip I picked every possible related v4l2 patch.
  4. @jerryg for hantro driver on RK3399 (or RK3328) I would recommend you to try the patches from, those add support for decoding of field encoded content and adds a hw variant for RK3399 on top of all hantro patches merged for 5.5. For ffmpeg I have two active branches that adds required bits for v4l2 stateless decoding: v4l2-request-hwaccel-4.0.4 (for use with ffmpeg in libreelec/kodi) and v4l2-request-hwaccel-master (for use with ffmpeg master), see for patches, build ffmpeg with --enable-v4l2-request --enable-libdrm --enable-libudev I plan on having these ffmpeg branches updated with latest stateless support until it can be upstreamed once the required private kernel headers have moved to uapi. mpv and kodi-gbm should be able to use the hw decoders as long as ffmpeg have been compiled with v4l2 request api enabled.
  5. Yep, the vpu1 is a Hantro G1 (or at least based on it). G1 is also used in IMX8 and details are in the IMX8M reference documentation. If you look for rk PX3 trm you also have some docs on the vpu1. Vpu2 is very similar to vpu1 but with regs in different positions. And imx8 g1 decoder code at is interesting.
  6. There are other people working on porting h264/vp8 to mainline driver, e.g., nothing I have tested yet.
  7. Great! The VPU in rk3288 (vpu1) should have VP8 support, same as the VPU in rk3328/rk3399 (vpu2) rk3288 has a second VPU block that can decode hevc rk3328/rk3399 has a second VPU block (rkvdec) that can decode h264/hevc/vp9 (they have two different vpu blocks that can decode h264) Just to let you know, I have moved to v5.1 now and latest RK VPU patchset v5 on top of linux v5.1 can be found at end of (along with a lot of probably unneccecery v4l2 patches)
  8. Yes, looks like the script used one of the branches, I do not have one branch with all patches, I tend to group patches into multiple branches to make it easier rebasing and review changes. If you keep the hdmi-sound base as you have and add as a patch you should have both branches. The 1080p H264, VP8 samples I have tested on my tinker board and even my rock64 running libreelec / kodi-gbm seems to play back fine using sw decoding. There are some libreelec test images at for testing, built out of
  9. Almost, that is the ffmpeg 4.0 branch I use myself, the ML patches was the ones at (same patches rebased on ffmpeg master), the FIXUP commit that I have added was just to do a rename as suggested by ML comments You can use if you want the 4.0 version or the link above for a ffmpeg master patch. I have tested very much, the only sample I have had issue with was a field encoded mpeg2 sample been trying to find other field encoded samples in order to test but they are hard to come by.
  10. I have not yet tested lima or panfrost drivers since libmali is working better for my use case, will switch to lima and panfrost in future. For midgard mali driver I am using (contains a restore 10.6 api commit that makes it work with rk r14p0 libmali) See for how I build the midgard driver. The midgard rk platform code is doing some unnecessary dev_info logging, but driver runs with mainline device trees on both rk3288 and rk3399. I am not sure the v4l2 testing tools by bootlin etc is working with rockchip vpu driver (nothing I have ever tested). The ffmpeg hwaccel from and mpv patched with should work for both cedrus and rockchip vpu driver. kodi-gbm should also work as long as ffmpeg used is patched and is built with --enable-v4l2-request --enable-libudev --enable-libdrm
  11. @Myy I pushed some updated kernel branches to my linux-rockchip repo today that may help you get the vpu driver running. Earlier this week I sent out my ffmpeg V4L2 request API hwaccel as RFC on ffmpeg-devel mailing list, see Important device tree and clk patches have already been merged or is queued for v5.1/v5.2. If you apply both of these two patches on top of v5.0.7 you should have a kernel with working vpu mpeg-2 driver for rk3288, rk3328 and rk3399: - contains all mmind/for-next patches merged/queued for v5.1/v5.2 + few patches from mailing list + my hdmi sound and cec patches - contains all v4l2 related media tree patches merged/queued for v5.1/v5.2 + Ezequiel rockchip vpu v2 patchset + my additions for rk3288 and rk3328 If you do not care for hdmi sound or cec improvements you can instead use the fromlist patch: - contains all mmind/for-next patches merged/queued for v5.1/v5.2 + few patches from mailing list For mali kernel driver I recommend, see below how I build it: make_target() { kernel_make -C $(kernel_path) M=$PKG_BUILD/driver/src/devicedrv/mali \ MALI_PLATFORM_FILES=platform/rk/rk.c GIT_REV="" \ EXTRA_CFLAGS="-DCONFIG_MALI400=1 -DCONFIG_MALI450=1 -DCONFIG_MALI470=1 -DMALI_FAKE_PLATFORM_DEVICE=1 -DCONFIG_MALI_DMA_BUF_MAP_ON_ATTACH -DCONFIG_MALI_DT" \ CONFIG_MALI400=m CONFIG_MALI450=y CONFIG_MALI470=y CONFIG_MALI_DMA_BUF_MAP_ON_ATTACH=y CONFIG_MALI_DT=y \ modules } makeinstall_target() { kernel_make -C $(kernel_path) M=$PKG_BUILD/driver/src/devicedrv/mali \ INSTALL_MOD_PATH=$INSTALL/$(get_kernel_overlay_dir) INSTALL_MOD_STRIP=1 DEPMOD=: \ modules_install }
  12. Sounds like it is linking to the static ffmpeg? I added the libudev dependancy to ffmpeg and only tested it on LibreELEC buildsystem where proper pkg-config file exists for libudev and -ludev is added correctly. Do you have full ffmpeg debug log? On my Tinker Board there is one media and three video devices and the v4l2_request probe code will try all media and related video devices until a video device supporting requested format is found. On Tinker Board the jpeg encoder is probed before the decoder and one output format not found is expected. Run mpv with --msg-level=ffmpeg=trace to get ffmpeg debug log. Output from v4l2-ctl --device /dev/video0 --all (and the other 2-3 video devices could be helpful to see if the MP2S format is supported).
  13. I never tested v4l2-request-test only peeked at the code to try and learn how to call the request api. The mpeg2/h264/hevc v4l2 ctrls currently lives in private kernel headers causing some troubles for user-space. My kernel vpu patcheset includes a revert to make the mpeg2 ctrl public and the hwaccel expects this, I plan to bundle the ctrl headers in next update to hwaccel.
  14. FFmpeg will need the following configure flags: --enable-v4l2-request --enable-libdrm --enable-libudev For mvp have some flags and commands that worked on LibreELEC buildsystem. kodi-gbm should also work without modifications as long as the mpeg2_v4l2request hwaccel is enabled, any recent version of kodi pre v18-v18.1. I have only tested this with libmali gbm files at and mali-utgard/mali-midgard kernel drivers. also have the with build commans I have used to build utgard/midgard drivers out-of-tree, but lima/panfrost should also "work" I have been told.
  15. @Myy The patches I have in my rockchip-5.x-vpu branch is on top of v5.0-rc6 + mmind/for-next and not a rockchip tree. All vpu related patches needed on top of v5.0-rc6: (patch) List of mmind/for-next patches rebased on v5.0-rc6: (patch) VPU related patches on top of mmind/for-next: (patch) I have started to send some of my patches to linux mailing list and more will follow.