Myy

Members
  • Content Count

    283
  • Joined

  • Last visited


Reputation Activity

  1. Like
    Myy reacted to jernej in The VPU driver   
    There is also VP9 decoding IP core , which is present in Allwinner H6, NXP i.MX8 and I think Rockchip has it too. It may be connected to Hantro and Google, but I'm unsure who is the original author.
  2. Like
    Myy reacted to JMCC in The VPU driver   
    Correct me if I'm wrong, but I understand that the new V4L2 driver only supports HW decoding, not encoding, right?
     
    In that case, IMO the usefulness of an standalone FFmpeg is very limited.  What I mean is that you won't get a noticeable benefit in transcoding with FFmpeg if you only accelerate the decoding. Not to mention possible colorspace conversion limitations etc (I think I bumped into some of those with the "old" RKMPP FFmpeg implementation).
     
    On the other hand, I see the real usefulness of that when FFmpeg is used as part of media players such as MPV or Kodi. And, in those cases, I always found it easier and more efficient to compile its own version of FFmpeg with the app, than link it against the system libs.
     
    So my opinion is that it is better to leave alone the system FFmpeg debs,  and compile the new version on a separate directory; that way it will not break other FFmpeg-dependent apps, such as video editors etc.. And let the media players use their own FFmpeg (after all that is what they normally recommend in their compilation instructions), and apply the patch there when necessary.
  3. Like
    Myy got a reaction from JMCC in The VPU driver   
    VPU patches re-ordered, remade and tested against 5.1 release kernel, with the usual patches combined.
     
    I retested the H264 driver with a slight fix and it's better, but there's still a few blocks not placed correctly here and there.
    This might be resolved this month, though.
     
    Anyway, it's MPEG-2 decoding only for the moment.
     
    Note to @TonyMac32, if you want to import these patches, the actual kernel patch list I'm using is there : https://github.com/Miouyouyou/RockMyy/blob/master/GetPatchAndCompileKernel.sh#L57
     
     
    Now, what remains is FFmpeg.
    I don't remember if Ubuntu is still using libav, or went back to FFmpeg. I remember that the projects forked for some weird reasons and Debian went with libav...
    So, basically, do I create a package, or just a tarball with the libraries. With just the tarball, you'll have to extract them somewhere and run LD_LIBRARY_PATH=/path/to/ffmpeg/libs to use them with mpv and such.
    With the Debian package, you get the advantages (automatic dependencies handling) along with all the troubles (packages conflicts).
     
    I still have to test bootlin libva too, since it seems to go well with VLC.
  4. Like
    Myy got a reaction from JMCC in The VPU driver   
    Here's a first draft of the patches I pulled from bbrezillon tree : https://github.com/Miouyouyou/RockMyy/tree/SplittingPatchesForVPU/patches/kernel/v5.1/VPU
    These are applied against mainline v5.1-rc5 kernels, and have been tested with Kwiboo's FFMPEG and a standard MPV.
     
    I'll try to test them, and adapt them, against v5.1 releases tomorrow. Then I'll re-arrange them and do a release of RockMyy.
     
    I'll then generate a FFmpeg package with Kwiboo's patch, using Kwiboo's tree, since bbrezillon's one doesn't integrate udev /dev/video node detection.
     
    And *then* I'll give the whole thing to test to @TonyMac32, who loves testing random VPU patches for Tinkerboards.
  5. Like
    Myy got a reaction from TonyMac32 in The VPU driver   
    Here's a first draft of the patches I pulled from bbrezillon tree : https://github.com/Miouyouyou/RockMyy/tree/SplittingPatchesForVPU/patches/kernel/v5.1/VPU
    These are applied against mainline v5.1-rc5 kernels, and have been tested with Kwiboo's FFMPEG and a standard MPV.
     
    I'll try to test them, and adapt them, against v5.1 releases tomorrow. Then I'll re-arrange them and do a release of RockMyy.
     
    I'll then generate a FFmpeg package with Kwiboo's patch, using Kwiboo's tree, since bbrezillon's one doesn't integrate udev /dev/video node detection.
     
    And *then* I'll give the whole thing to test to @TonyMac32, who loves testing random VPU patches for Tinkerboards.
  6. Like
    Myy reacted to Igor in Forum upgrade planned for May 2nd   
    Upgrade is complete ... now bug fixing.
  7. Like
    Myy reacted to Kwiboo 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 }  
  8. Like
    Myy reacted to Kwiboo 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
  9. Like
    Myy got a reaction from gounthar in RK3399 Orange Pi   
    Glad you got back from MASKROM mode.
     
    The image I used at the time was from RKTool_Linux.tar.gz -> Linux_Pack_Firmware/Linux-rockdev_2015-06-17_for_RK3399.zip -> rockdev/
     
    This comes from OrangePi MEGA folder : https://mega.nz/#F!K1BQFQjL!W9rYedaoGpV4y8vHfrGEfQ!ekYA0AwR
     
    Why did they hide the image into a sub-sub-archive on a random MEGA folder ? I don't know.
  10. Like
    Myy got a reaction from TonyMac32 in The VPU driver   
    Okay, I'm trying (again) this week-end. So the Randy-Li patch not including VPU Decoder v1 for RK3288 chips, I've giving up on it at the moment.
    I'm retrying the Ezequiel patch, with Kwiboo additions, now trying to understand how the V4L2 request thing work, and why when using the v4l2-request-test tester, the driver sends back a "Invalid request" response...
  11. Like
    Myy got a reaction from JMCC in RK3288 Media Script (TinkerBoard)   
    I need to understand what V4L2 changes are made between the branch used in the "Rockchip-linux" talk (it seems to be mmind one, but I'm not entirely sure). Then, I could try Ayaka and Kwiboo patches again.
  12. Like
    Myy reacted to Igor in Switching Rockchip64-DEV to 5.0.y ...   
    IDK and haven't tried that yet.
     
    Perhaps @ayufan  @TonyMac32  @Myy know more about ?
  13. Like
    Myy reacted to NicoD in Armbian in 3D   
    Hi all. 
    Since I wanted a 3D intro for my Youtube Channel I started working with Blender again. Now the intro is finished I've got time to try to make a 3D Armbian Logo.
     

    I'll show some of the progress here for those who are interested. And if anybody else wants to do the same, go  ahead. We can then compare the results.
    I've only just begun. But I needed a break so I started writing this.
    Here's how it begins... create a side view ... 


    Then put those pictures in Blender, add a cube, position it right on both pictures, and start modeling....

    All done with the NanoPi M4 on Armbian Bionic.

    I'll slowly keep working on it. I can't promise it will look great, but nothing is lost if it doesn't... Someone once asked me to do this, I can't remember who it was. I think Chwe or jmcc or tido. Could also have been a ghost in my sleep.
    Cheers, NicoD

    ps: @Igor It would be nice if we could easily resize images in our posts. Maybe with a dropdown box and % would be easiest to do. I know this isn't a priority, just a suggestion. 
     
  14. Like
    Myy reacted to Kwiboo 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).
  15. Like
    Myy reacted to Kwiboo 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.
  16. Like
    Myy reacted to TonyMac32 in The VPU driver   
    Haha. I still need to do that thermal comparison between factory, my Frankenstein above, and the nice case they sent me. It is far superior to the factory cooler, although it would still throttle in your situation.

    Sent from my Pixel using Tapatalk


  17. Like
    Myy got a reaction from petatester in The VPU driver   
    Alright, the module not loading was due to one my patch modifying the DTSI in order to adapt to Ayaka driver, which used names like "VEPU" and "VDPU". So I basically copied back the nodes as they're defined in the rk3288.dtsi of your kernel tree.

    So the module loads, media-test is able to list all the rockchip-vpu outputs (sink, ...). However this one, https://github.com/bootlin/v4l2-request-test , throws Invalid argument when trying to execute a VIDIOC_TRY_FMT . Given how IOCTL work, trying to recompile FFMPEG appears to be a "quicker" solution than debugging the tester from bootlin.

    Is there a "quick" tester that just tries to decode ONE frame of a specific format, that is up to date and works with the currently implemented V4L2 Request extension ?
  18. Like
    Myy got a reaction from TonyMac32 in The VPU driver   
    Yeah... well.. went without it, with just a passive cooler while powered through a USB charger. #SoRebel #MuchRockchip
  19. Like
    Myy reacted to TonyMac32 in The VPU driver   
    That's the only reasonable way to do something stressful with an RK3288.  I'd add GPIO powering on top of that to be sure, since it not thermal throttling presents challenges for everything else in the system that might not have anticipated pulling 15 Watts for over an hour.
  20. Like
    Myy reacted to Kwiboo 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.
  21. Like
    Myy reacted to Kwiboo 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.
  22. Like
    Myy reacted to Kwiboo 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.
  23. Like
    Myy got a reaction from petatester in The VPU driver   
    Well, while this is called a "Video Processing Unit", the thing is : there's a LOT of video file formats out there. Which mean, a lot of different parameters and decoding/decompressing methods, based on the format used. (I mean, there are different formats and there are "different" for a reason...)
    All the VPU I know are specialized in decoding a few formats, at most : H264, H265, VP8, VP9, ...
     
    For each format, the VPU must be configured to access external data like : The current frame, the configuration of the current stream (Width, Height, Bytes per pixel, Color format, ...), the different decoding tables if any (e.g. CABAC tables for H26x), ... .
    The amount of external data and configuration vary from format to format, knowing that some formats can also have "sub-formats" (H264 is a good example of this madness) which require more or less parameters.
     
    So, yeah, VPU are dedicated to a few formats, and for each format, the setup can be completely different. That can be due to configuration registers being mapped at different addresses depending on the decoded format, or the same registers having completely different meaning depending on the format decoded.
     
    Note that, in this case, the VPU decode one frame per one frame.
    You cannot just "Send the MKV to the VPU, get a video stream on the other end". It *clearly* doesn't have enough memory for that.
    Very roughly, the procedure goes as is :
    First, the user application must :
    Get the first frame of the video stream Send it to the VPU driver Then VPU driver must :
    Setup the VPU to decode the frame Launch the VPU decoding process Wait for the decoded result Send back the result to the user application. Then user application :
    Retrieves and shows the result, Rinces and repeat for every frame of the video. So, yeah, VPU are not CODEC agnostics. They are CODEC specialized. So the driver is setup slowly, but surely, to decode each format correctly.
  24. Like
    Myy got a reaction from manuti in The VPU driver   
    Well, while this is called a "Video Processing Unit", the thing is : there's a LOT of video file formats out there. Which mean, a lot of different parameters and decoding/decompressing methods, based on the format used. (I mean, there are different formats and there are "different" for a reason...)
    All the VPU I know are specialized in decoding a few formats, at most : H264, H265, VP8, VP9, ...
     
    For each format, the VPU must be configured to access external data like : The current frame, the configuration of the current stream (Width, Height, Bytes per pixel, Color format, ...), the different decoding tables if any (e.g. CABAC tables for H26x), ... .
    The amount of external data and configuration vary from format to format, knowing that some formats can also have "sub-formats" (H264 is a good example of this madness) which require more or less parameters.
     
    So, yeah, VPU are dedicated to a few formats, and for each format, the setup can be completely different. That can be due to configuration registers being mapped at different addresses depending on the decoded format, or the same registers having completely different meaning depending on the format decoded.
     
    Note that, in this case, the VPU decode one frame per one frame.
    You cannot just "Send the MKV to the VPU, get a video stream on the other end". It *clearly* doesn't have enough memory for that.
    Very roughly, the procedure goes as is :
    First, the user application must :
    Get the first frame of the video stream Send it to the VPU driver Then VPU driver must :
    Setup the VPU to decode the frame Launch the VPU decoding process Wait for the decoded result Send back the result to the user application. Then user application :
    Retrieves and shows the result, Rinces and repeat for every frame of the video. So, yeah, VPU are not CODEC agnostics. They are CODEC specialized. So the driver is setup slowly, but surely, to decode each format correctly.
  25. Like
    Myy got a reaction from TonyMac32 in The VPU driver   
    You should like my Wayland example, then :3
     
    Anyway, I see that Ezecquiel Garcia is currently pushing patches to adapt the V4L2 patches from Ayaka, into something that works with V4L2 (and a few modifications) without the MPP layer in-between.
    He pushed support for MPEG-2 decoding support... I'll see if he pushes support for H264 this week.
    If not, I'll try to adapt Ayaka's patches.