Kwiboo

Members
  • Content Count

    42
  • Joined

  • Last visited


Reputation Activity

  1. Like
    Kwiboo got a reaction from gounthar in 4k HDMI output   
    I have some work-in-progress patches at https://github.com/Kwiboo/linux-rockchip/compare/next-20200501...next-20200501-drm-rockchip that should enable up to 4k30hz hdmi modes on rk3399.
     
    My focus switched to rkvdec so these patches have been on hold for some time, they need to be synced with some of my older rk3328 patches for 420-mode support before they can be sent upstream. With 10-bit decoding now working I am expecting readying 4k/10-bit hdmi patches to be more fun :-)
  2. Like
    Kwiboo got a reaction from aaditya in 4k HDMI output   
    I have some work-in-progress patches at https://github.com/Kwiboo/linux-rockchip/compare/next-20200501...next-20200501-drm-rockchip that should enable up to 4k30hz hdmi modes on rk3399.
     
    My focus switched to rkvdec so these patches have been on hold for some time, they need to be synced with some of my older rk3328 patches for 420-mode support before they can be sent upstream. With 10-bit decoding now working I am expecting readying 4k/10-bit hdmi patches to be more fun :-)
  3. Like
    Kwiboo got a reaction from Myy in Mainline VPU   
    No problems! :-)
     
     
    I can recommend you to look at https://github.com/Kwiboo/linux-rockchip/commits/linuxtv-rkvdec-work-in-progress that is the branch that will continue to see updates as I prepare ongoing work for upstream.
    With this updated branch (work rebased on top of media_tree master) and latest 4.2.2-rkvdec ffmpeg branch vp9, h264 (high 10 and high 422) and hevc (main 10) should be usable.
    There is still one bit not properly being configured for hevc so there are some videos that produce small artifacts while decoding.
     
    Hoping to have initial patchset with focus on rkvdec fixes and rkvdec/hantro support for h264 interlaced/field encoded on media mailing list before the weekend is over :-)
  4. Like
    Kwiboo got a reaction from jock in Mainline VPU   
    That branch was just something I played with for stateful decoding on RPi and Amlogic and not something that was finished nor do I expect it to be working.
     
    https://github.com/Kwiboo/FFmpeg/commits/v4l2-request-hwaccel-4.2.2 is the branch we use in LibreELEC. I was able to hw decode h264 with that branch and vanilla linux 5.6.6 on my RK3288 Tinker Board S a few hours ago.
    Also you should not need the --enable-libv4l2 configure flag, --enable-libdrm --enable-v4l2-request --enable-libudev should be enough to enable the request api hwaccels.
     
    What device are you testing on? I have not done any testing with rkvdec driver and there is no rk3328/rk3399 hantro driver for h264 in upstream media tree. Mpeg-2 and VP8 should work across rk3288/rk3328/rk3399.
    I do not expect h264 rkvdec to be working without changes to ffmpeg since there was some flags that got changed and now do not match between upstream rkvdec driver and my ffmpeg branch.
     
    I am hoping to get some time this weekend to update ffmpeg to work with rkvdec and hopefully submit the initial hantro h264 decoder for rk3328/rk3399 vpu2 to upstream.
  5. Like
    Kwiboo got a reaction from aaditya in Mainline VPU   
    That branch was just something I played with for stateful decoding on RPi and Amlogic and not something that was finished nor do I expect it to be working.
     
    https://github.com/Kwiboo/FFmpeg/commits/v4l2-request-hwaccel-4.2.2 is the branch we use in LibreELEC. I was able to hw decode h264 with that branch and vanilla linux 5.6.6 on my RK3288 Tinker Board S a few hours ago.
    Also you should not need the --enable-libv4l2 configure flag, --enable-libdrm --enable-v4l2-request --enable-libudev should be enough to enable the request api hwaccels.
     
    What device are you testing on? I have not done any testing with rkvdec driver and there is no rk3328/rk3399 hantro driver for h264 in upstream media tree. Mpeg-2 and VP8 should work across rk3288/rk3328/rk3399.
    I do not expect h264 rkvdec to be working without changes to ffmpeg since there was some flags that got changed and now do not match between upstream rkvdec driver and my ffmpeg branch.
     
    I am hoping to get some time this weekend to update ffmpeg to work with rkvdec and hopefully submit the initial hantro h264 decoder for rk3328/rk3399 vpu2 to upstream.
  6. Like
    Kwiboo got a reaction from aaditya in Armbian v20.05 (Kagu) Planning Thread   
    Yes, I have had VPU working on 5.4 kernel since the new year started, my test images from 31 dec / 1 jan at http://kwiboo.libreelec.tv/test/ 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.
  7. Like
    Kwiboo got a reaction from Myy in Armbian v20.05 (Kagu) Planning Thread   
    Yes, I have had VPU working on 5.4 kernel since the new year started, my test images from 31 dec / 1 jan at http://kwiboo.libreelec.tv/test/ 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.
  8. Like
    Kwiboo got a reaction from Myy in The VPU driver   
    @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 http://ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242316.html
    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:
    https://github.com/Kwiboo/linux-rockchip/compare/v5.0.7...rockchip-5.x-hdmi-sound.patch - contains all mmind/for-next patches merged/queued for v5.1/v5.2 + few patches from mailing list + my hdmi sound and cec patches
    https://github.com/Kwiboo/linux-rockchip/compare/v5.0.7...rockchip-5.x-vpu-v2.patch - 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:
    https://github.com/Kwiboo/linux-rockchip/compare/v5.0.7...rockchip-5.x-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 https://github.com/Kwiboo/mali-rockchip/commits/utgard-r9p0, 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 }  
  9. Like
    Kwiboo got a reaction from Myy in The VPU driver   
    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 https://github.com/Kwiboo/mali-rockchip/commits/midgard-r28p0 (contains a restore 10.6 api commit that makes it work with rk r14p0 libmali)
    See https://github.com/Kwiboo/LibreELEC.tv/blob/rockchip-5.x/projects/Rockchip/packages/mali-midgard-rockchip/package.mk 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 https://github.com/Kwiboo/FFmpeg/commits/v4l2-request-hwaccel and mpv patched with https://github.com/mpv-player/mpv/pull/6461 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
  10. Like
    Kwiboo got a reaction from TonyMac32 in The VPU driver   
    @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 http://ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242316.html
    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:
    https://github.com/Kwiboo/linux-rockchip/compare/v5.0.7...rockchip-5.x-hdmi-sound.patch - contains all mmind/for-next patches merged/queued for v5.1/v5.2 + few patches from mailing list + my hdmi sound and cec patches
    https://github.com/Kwiboo/linux-rockchip/compare/v5.0.7...rockchip-5.x-vpu-v2.patch - 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:
    https://github.com/Kwiboo/linux-rockchip/compare/v5.0.7...rockchip-5.x-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 https://github.com/Kwiboo/mali-rockchip/commits/utgard-r9p0, 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 }  
  11. Like
    Kwiboo got a reaction from Myy in The VPU driver   
    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).
  12. Like
    Kwiboo got a reaction from Myy in The VPU driver   
    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.
  13. Like
    Kwiboo got a reaction from petatester in The VPU driver   
    @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: https://github.com/Kwiboo/linux-rockchip/compare/v5.0-rc6...rockchip-5.x-vpu (patch)
    List of mmind/for-next patches rebased on v5.0-rc6: https://github.com/Kwiboo/linux-rockchip/compare/v5.0-rc6...rockchip-5.x (patch)
    VPU related patches on top of mmind/for-next: https://github.com/Kwiboo/linux-rockchip/compare/rockchip-5.x...rockchip-5.x-vpu (patch)
     
    I have started to send some of my patches to linux mailing list and more will follow.
  14. Like
    Kwiboo got a reaction from Myy in The VPU driver   
    @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: https://github.com/Kwiboo/linux-rockchip/compare/v5.0-rc6...rockchip-5.x-vpu (patch)
    List of mmind/for-next patches rebased on v5.0-rc6: https://github.com/Kwiboo/linux-rockchip/compare/v5.0-rc6...rockchip-5.x (patch)
    VPU related patches on top of mmind/for-next: https://github.com/Kwiboo/linux-rockchip/compare/rockchip-5.x...rockchip-5.x-vpu (patch)
     
    I have started to send some of my patches to linux mailing list and more will follow.
  15. Like
    Kwiboo got a reaction from chwe in The VPU driver   
    @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: https://github.com/Kwiboo/linux-rockchip/compare/v5.0-rc6...rockchip-5.x-vpu (patch)
    List of mmind/for-next patches rebased on v5.0-rc6: https://github.com/Kwiboo/linux-rockchip/compare/v5.0-rc6...rockchip-5.x (patch)
    VPU related patches on top of mmind/for-next: https://github.com/Kwiboo/linux-rockchip/compare/rockchip-5.x...rockchip-5.x-vpu (patch)
     
    I have started to send some of my patches to linux mailing list and more will follow.
  16. Like
    Kwiboo got a reaction from TonyMac32 in The VPU driver   
    @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: https://github.com/Kwiboo/linux-rockchip/compare/v5.0-rc6...rockchip-5.x-vpu (patch)
    List of mmind/for-next patches rebased on v5.0-rc6: https://github.com/Kwiboo/linux-rockchip/compare/v5.0-rc6...rockchip-5.x (patch)
    VPU related patches on top of mmind/for-next: https://github.com/Kwiboo/linux-rockchip/compare/rockchip-5.x...rockchip-5.x-vpu (patch)
     
    I have started to send some of my patches to linux mailing list and more will follow.
  17. Like
    Kwiboo got a reaction from Myy in The VPU driver   
    https://github.com/Kwiboo/rockchip-vpu-regtool 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.
  18. Like
    Kwiboo got a reaction from Myy in The VPU driver   
    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 https://github.com/mpv-player/mpv/pull/6461 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 http://kwiboo.libreelec.tv/test/ 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.
  19. Like
    Kwiboo got a reaction from balbes150 in The VPU driver   
    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 https://github.com/mpv-player/mpv/pull/6461 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 http://kwiboo.libreelec.tv/test/ 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.
  20. Like
    Kwiboo got a reaction from valant in ROCK64   
    Until Rockchip finished the SPL+DRAM init code for RK3328 we have to use the ddr+miniloader blobs to start u-boot, https://github.com/rockchip-linux/build/blob/debian/mk-uboot.sh#L48-L77 generates working idbloader.img, uboot.img and trust.img using tools and blobs from the rkbin repo.
    The BootROM will look for idbloader.img at 0x40 on SPI/eMMC/SD, and the miniloader will expect uboot.img+trust.img at 0x4000 and 0x6000 on the same device it loaded idbloader.img from, the miniloader before v2.43 had a bug that would always load uboot+trust from eMMC (or possibly SPI).
    http://opensource.rock-chips.com/wiki_Boot_option have some details on the boot process.
  21. Like
    Kwiboo got a reaction from Myy in The VPU driver   
    I build mpv for LibreELEC using https://github.com/Kwiboo/LibreELEC.tv/blob/rockchip/projects/Rockchip/packages/mpv-rockchip/package.mk#L63 along with the configure options defined earlier in the file.
     
    We are using a patch to update some of the EGL/GLES include files from RK's libmali repo using https://github.com/Kwiboo/LibreELEC.tv/blob/rockchip/projects/Rockchip/packages/mali-rockchip/patches/mali-rockchip-0001-update-include-files.patch
    There is also some GL include files included because mpv do not play nice with only GLES headers, see https://github.com/Kwiboo/LibreELEC.tv/tree/rockchip/projects/Rockchip/packages/mpv-rockchip/GL
  22. Like
    Kwiboo got a reaction from tkaiser in The VPU driver   
    Unfortunately it is not possible to link kodi krypton and mpv to the same ffmpeg version, mpv requires a rather new ffmpeg version and uses the newer send_packet/receive_frame api and automatic bit-streaming and kodi krypton uses the older video2_decode api.
    There was also some audio delays and missed packets if kodi krypton is linked to the newer ffmpeg version, kodi leia will require the new ffmpeg version and the patches will be rebased and updated at a later date.
     
    For optimal media playback there have been a few kernel changes required, see my rockchip-4.4 kernel tree at https://github.com/Kwiboo/linux-rockchip/commits/rockchip-4.4
    Changed to use of performance gpu governor as a default, the simple_ondemand governor is too slow and limits the gpu rate to ~30fps for gui animations Switched primary and overlay drm planes so we can have gui on top of video Raise the vpu clock to 600Mhz for hevc decoding on rk3288 Allow framebuffer and videomodes not to have same size for scaling of gui from 1080p to 4k (implemented in plexmediaplayer and on my todo list for kodi) Skip waiting on vblank for set plane drm calls, this was recently merged in Rockchip's release-4.4 tree and allows for rendering video and gui planes using legacy drm api without double vsync
  23. Like
    Kwiboo got a reaction from Myy in The VPU driver   
    Unfortunately it is not possible to link kodi krypton and mpv to the same ffmpeg version, mpv requires a rather new ffmpeg version and uses the newer send_packet/receive_frame api and automatic bit-streaming and kodi krypton uses the older video2_decode api.
    There was also some audio delays and missed packets if kodi krypton is linked to the newer ffmpeg version, kodi leia will require the new ffmpeg version and the patches will be rebased and updated at a later date.
     
    For optimal media playback there have been a few kernel changes required, see my rockchip-4.4 kernel tree at https://github.com/Kwiboo/linux-rockchip/commits/rockchip-4.4
    Changed to use of performance gpu governor as a default, the simple_ondemand governor is too slow and limits the gpu rate to ~30fps for gui animations Switched primary and overlay drm planes so we can have gui on top of video Raise the vpu clock to 600Mhz for hevc decoding on rk3288 Allow framebuffer and videomodes not to have same size for scaling of gui from 1080p to 4k (implemented in plexmediaplayer and on my todo list for kodi) Skip waiting on vblank for set plane drm calls, this was recently merged in Rockchip's release-4.4 tree and allows for rendering video and gui planes using legacy drm api without double vsync
  24. Like
    Kwiboo got a reaction from TonyMac32 in The VPU driver   
    Cool, I will check how this VPU driver works with a 4.13 kernel on LibreELEC later this weekend.
     
    I would suggest testing the VPU driver and mpp using Rockchip's gstreamer plugins or possibly LongChair's mpv/ffmpeg.
    I don't know much about gstreamer but it seems to be what the Rockchip's developers use to test video decoding.
    Both mpv/plexmediaplayer and kodi use DRM/KMS, gbm version of libmali and a few kernel hacks on LibreELEC for smooth 1080p/4k video playback, they most likely need modifications to run on x11/wayland.
     
    For a version of ffmpeg that use mpp for decoding, see https://github.com/LongChair/FFmpeg/commits/rockchip or the rockchip-new branch.
    LongChair also have a mpv version for both those branches of ffmpeg at https://github.com/LongChair/mpv/commits/rockchip or the rockchip-new branch.
    I have a ffmpeg 3.1 backport at https://github.com/Kwiboo/FFmpeg/commits/rockchip-krypton and Kodi Krypton patches at https://github.com/Kwiboo/plex-home-theater/commits/rockchip-krypton.
    The Kodi Leia patches in the rockchip-leia branch will be updated once we have achieved more stable playback on rk3328 devices using mpv and Kodi Krypton.
  25. Like
    Kwiboo got a reaction from Myy in The VPU driver   
    Cool, I will check how this VPU driver works with a 4.13 kernel on LibreELEC later this weekend.
     
    I would suggest testing the VPU driver and mpp using Rockchip's gstreamer plugins or possibly LongChair's mpv/ffmpeg.
    I don't know much about gstreamer but it seems to be what the Rockchip's developers use to test video decoding.
    Both mpv/plexmediaplayer and kodi use DRM/KMS, gbm version of libmali and a few kernel hacks on LibreELEC for smooth 1080p/4k video playback, they most likely need modifications to run on x11/wayland.
     
    For a version of ffmpeg that use mpp for decoding, see https://github.com/LongChair/FFmpeg/commits/rockchip or the rockchip-new branch.
    LongChair also have a mpv version for both those branches of ffmpeg at https://github.com/LongChair/mpv/commits/rockchip or the rockchip-new branch.
    I have a ffmpeg 3.1 backport at https://github.com/Kwiboo/FFmpeg/commits/rockchip-krypton and Kodi Krypton patches at https://github.com/Kwiboo/plex-home-theater/commits/rockchip-krypton.
    The Kodi Leia patches in the rockchip-leia branch will be updated once we have achieved more stable playback on rk3328 devices using mpv and Kodi Krypton.