• Posts

  • Joined

  • Last visited

Recent Profile Visitors

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

Kwiboo's Achievements

  1. Thanks for testing!, kodi has just moved to ffmpeg 4.3 so LibreELEC will follow as soon as all ffmpeg patches has been rebased. Do you have a sample to share? Also note that only Profile 0 is supported and videos using frame resize is expected to have issues. I do not expect these formats to work, the kodi drmprime video codec and renderer sw decoding parts have mainly been tested with 8-bit video. The crash should probably be fixed, unfortunately 10/12-bit sw decoding is not high on priority list, in future when ffmpeg filters are supported in kodi drmprime video codec converting to a 8-bit pixel format may be possible.
  2. Kwiboo

    Mainline VPU

    Thanks for testing, normally I try to keep ffmpeg_v4l2-request-hwaccel-master and ffmpeg_v4l2-request-hwaccel-4.2.2 in sync but I have not yet updated or tested the -master branch, I will try to update it in next few days. Background on my different ffmpeg branches: v4l2-request-hwaccel-x.y.z: Main branch that most of the time matches the patches used in LibreELEC master, x.y.z (4.2.2) matches the ffmpeg version used in Kodi master. This branch is usually tested on Rockchip/hantro/rkvdec by me and on Allwinner/cedrus by @jernej, fixup commits usually gets squashed right before we pick out a new patchset for use in LibreELEC. v4l2-request-hwaccel-master: This branch should contain the patches in v4l2-request-hwaccel-x.y.z on top of ffmpeg master, may see some delays at times. v4l2-request-hwaccel-4.2.2-rkvdec: work-in-progress branch for parts that currently only is expected to work on rockchip/rkvdec, e.g. 10-bit hevc decoding on cedrus stops working in this branch due to patches to handle rkvdec 10-bit decoding, patches should eventually flow to -x.y.z/-master branches once ready.
  3. I have some work-in-progress patches at 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 :-)
  4. Kwiboo

    Mainline VPU

    Correct, the device-tree changes is not part of my media_tree branch, it is already merged for 5.8 and not something I care for in my patchset (I do not use this kernel branch as-is, only the diff from media tree master + linux-next and/or a mix of merged/work-in-progress patches). No this is not the "small artifacts while decoding" issue, this is due to the sw pixel format conversion being done, the sw pixel format may incorrectly be signaled as nv12 but is instead "nv15" for 10-bit content also there is no nv15/nv20 converter. Correct, I recommend you use kodi-gbm or mpv if you want to render video as they both have support for zero-copy rendering to a dedicated drm plane, with ffmpeg command the cpu will be busy doing pixel format conversion (sw pixel conversion is also activated with null output).
  5. Kwiboo

    Mainline VPU

    No problems! :-) I can recommend you to look at 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 :-)
  6. Kwiboo

    Mainline VPU

    I have some patches for activating h264 decoding using the hantro vpu on rk3328/rk3399 at, they only ever reached mailing list as a RFC. Hoping to find some time soon to rework the field encoded content (interlaced) support and also to make it possible to use the hantro vpu for h264 decoding on rk3328/rk3399. Hantro h264 does seem to be limited to 1080p on those SoCs so will probably not bring any benefit over rkvdec.
  7. Kwiboo

    Mainline VPU

    Thanks! I have now updated the (and the -master) branch, commits have been squashed, updated and split apart to hopefully make it easier to use with mainline linux without the work-in-progress cedurs/hantro patches that has not yet been upstreamed. I would recommend you to test the commits up to and including "HACK: hwcontext_drm: do not require drm device", that should be safe to use on v5.5 or newer kernel without out-of-tree patches for cedrus/hantro/rkvdec. Also added the initial vp9 hwaccel, picked from, but have not yet had time to test it more then a simple compile test. I am expecting that I will make some minor updates to the vp9 hwaccel once I have run some tests.
  8. Kwiboo

    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. 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.
  9. 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.
  10. 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.
  11. @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.
  12. @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.
  13. 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.
  14. There are other people working on porting h264/vp8 to mainline driver, e.g., nothing I have tested yet.
  15. 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)