• 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. 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.
  2. There are other people working on porting h264/vp8 to mainline driver, e.g., nothing I have tested yet.
  3. 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)
  4. 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
  5. 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.
  6. 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
  7. @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 }
  8. 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).
  9. 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.
  10. 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.
  11. @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.
  12. I was familiar with the vpu2 hw regs that needed to be set from creating an experimental mpeg-2 hwaccel for the rk vcodec kernel driver some time ago. After collaboration with @jernej to create a v4l2 request api hwaccel and getting it working with the Allwinner cedrus driver I learned enough v4l2 to get the rockchip vpu MPEG-2 decoder to work on my Rock64. Ezecquiel Garcia was then very helpful and got my initial work (decoder boilerplate was copied from encoder and chromium os) ready for upstream and submitted the MPEG-2 decoder for rk3399 on top of his decoder boilerplate work. RK3288 and RK3328 was left out as they requires clk and drm changes to work properly, patches are being prepared to be submitted. The rockchip-vpu-regtool was created to help set correct hw regs for both vpu1 and vpu2, mpeg2.txt was created based on mpp hal code, some imx-vpu-hantro code along with some docs was also useful to get more insights into the rockchip vpu.
  13. may also be interesting, it generated the template vpu code used for the rk mpeg-2 decoder. I will push an update including txt-files with hw regs that needs to be set for other codecs later, buffer and reference frame handling code will need to be created by hand.
  14. For mpeg-2 on rk3288/rk3328 there are some other patches needed, see my rockchip-5.x-vpu branch for working rk3288/rk3328 mpeg-2 decoding on v5.0-rc6. clk, drm and dts patches will be sent upstream any day now. Also check out and the linked ffmpeg hwaccel if you want to use mpv or kodi-gbm for testing, I recently pushed dynamic selection of media/video device to hwaccel so should work without forcing decoder to /dev/video0. I pushed two libreelec test images to for tinker board and rock64 if you want to test mpeg-2 decoder, it includes patches from my rockchip-5.x-rebase and rockchip-5.x-vpu linux branch.
  15. For LibreELEC we use latest RK BSP kernel on TinkerBoard, MiQi, RK3328 and RK3399 and it has been pretty "stable" last few months. I do not have a single branch with all changes and instead generate patches based on RK BSP release-4.4 branch. Each branch mainly contain patches picked from mainline to improve multimedia. Linux tree: Patches: We are currently using a release-4.4 tag as base that includes the removed rk1808/rk3399pro commits from BSP tree. I usually just merge latest LSK 4.4 android to include the latest 4.4 patches, but anything newer then current RK BSP seems to cause issues for BT/WiFi on my TinkerBoard.