Myy

  • Content Count

    364
  • Joined

  • Last visited

Reputation Activity

  1. Like
    Myy reacted to Igor in Forum upgrade planned for May 2nd   
    Upgrade is complete ... now bug fixing.
  2. 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 }  
  3. 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
  4. 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.
  5. 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...
  6. 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.
  7. 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 ?
  8. 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. 
     
  9. 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).
  10. 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.
  11. 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


  12. 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 ?
  13. 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
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. 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.
  20. 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.
  21. Like
    Myy got a reaction from jock 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.
  22. Like
    Myy got a reaction from petatester in The VPU driver   
    MPP/RKMPP is the RocKchip Media Process Platform.
    A set of libraries, made by Rockchip, to communicate with their VPU driver. The thing is done in such a way that the "driver" basically only handle a few things like memory management.
    The actual registers of the hardware are known by MPP and are setup by this library, then sent to the driver which almost blindly write the registers values into the hardware, or read them back and send them back to MPP.
    Which mean that, even if you have the sources of the Rockchip VPU driver, you need the sources of MPP to understand how the hardware is actually programmed, based on the format you want to decode/encode.
    This is the kind of setup which make you wonder, who's the real "driver" ?
    http://opensource.rock-chips.com/wiki_Mpp
     
    FFMPEG is one the most famous multimedia processing library and tool. This thing can combine audio/video from different sources and combine/convert them into a LOT of formats.
    It comes as a library AND as a binary, which is one of the swiss-army knife for Audio-Video processing.
    https://ffmpeg.org/
     
    MPV is a Media Player, fork of Mplayer2, which use FFMPEG as a backend. It currently have a RKMPP backend to decode video frames using the RKMPP libraries.
    https://mpv.io/
     
    H264 is a video format.
    https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC
     
    The I-frames in H264 are reference (key) frames, from which other kind of frames (B/P frames) will be generated. The I-frame is basically the full frame, while the B/P frames are basically "patches" applied to I-frames to get the new picture.
    The "patches" being generally smaller than the I frame, you get one way to "compress" the video (upon various others used simultaneously).
    https://en.wikipedia.org/wiki/Inter_frame
  23. Like
    Myy got a reaction from manuti in The VPU driver   
    MPP/RKMPP is the RocKchip Media Process Platform.
    A set of libraries, made by Rockchip, to communicate with their VPU driver. The thing is done in such a way that the "driver" basically only handle a few things like memory management.
    The actual registers of the hardware are known by MPP and are setup by this library, then sent to the driver which almost blindly write the registers values into the hardware, or read them back and send them back to MPP.
    Which mean that, even if you have the sources of the Rockchip VPU driver, you need the sources of MPP to understand how the hardware is actually programmed, based on the format you want to decode/encode.
    This is the kind of setup which make you wonder, who's the real "driver" ?
    http://opensource.rock-chips.com/wiki_Mpp
     
    FFMPEG is one the most famous multimedia processing library and tool. This thing can combine audio/video from different sources and combine/convert them into a LOT of formats.
    It comes as a library AND as a binary, which is one of the swiss-army knife for Audio-Video processing.
    https://ffmpeg.org/
     
    MPV is a Media Player, fork of Mplayer2, which use FFMPEG as a backend. It currently have a RKMPP backend to decode video frames using the RKMPP libraries.
    https://mpv.io/
     
    H264 is a video format.
    https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC
     
    The I-frames in H264 are reference (key) frames, from which other kind of frames (B/P frames) will be generated. The I-frame is basically the full frame, while the B/P frames are basically "patches" applied to I-frames to get the new picture.
    The "patches" being generally smaller than the I frame, you get one way to "compress" the video (upon various others used simultaneously).
    https://en.wikipedia.org/wiki/Inter_frame
  24. Like
    Myy got a reaction from TonyMac32 in The VPU driver   
    After fighting to get FFMPEG compiled, MPV compiled (with Debian putting ffmpeg includes inside /usr/include/arm-what-ever-arch-hf/ and /usr/include/arm-what-ever-arch-hf/ having priority over /usr/include !) and then patching MPV to get the OpenGL display working correctly (stop using eglGetDisplay when you can use eglGetPlatformDisplayEXT !), I got the same error as you had...
     
    And then I realized that the error states that the buffer allocation failed...
     
    So I tried as root and it led to RKMPP failing to get the right frames in time. And then it crashed... badly.
     
    I'll retry with Gstreamer, since Rockchip seems to love gstreamer. And if that doesn't work, then the VPU is still in a shit state... But at least, they can communicate with it so I guess it's something...
  25. Like
    Myy reacted to TonyMac32 in The VPU driver   
    @Myy I missed your comment on the initial commit, I need to quite waiting until midnight to do the more interesting stuff. 
     
    I'm being presented with 5 options under the rockchip_mpp kconfig:  I've got MPP_VDEC_DEVICE, vpu decovder V1 and V2, vpu encoder V1 and V2. Are they all needed?