Jump to content

Sash0k

Members
  • Posts

    5
  • Joined

  • Last visited

Reputation Activity

  1. Like
    Sash0k reacted to a.rodionov in Nanopi neo air ffmpeg with Cedrus H264   
    Thanks to all for help.  We have setuped uboborov sunxi-cedar-mainline in 5.7 armbian kernel.  I think, early we did some errors in dts.  Our current dts we published in https://github.com/Rexarrior/sunxi-cedar-mainline.  Big thanks to uboborov! 
  2. Like
    Sash0k got a reaction from buptsb in Hardware Graphic/Video Acceleration in H3 Mainline   
    Trying to add VA-API into actual Armbian Focal (Linux orangepipc 5.4.45-sunxi #20.05.4)
     
    Install instruction
     
    Next, export driver:
    $ export LIBVA_DRIVER_NAME=v4l2_request and check it with vainfo tool. Have an error:
    $ vainfo libva info: VA-API version 1.7.0 libva info: User environment variable requested driver 'v4l2_request' libva info: Trying to open /usr/lib/arm-linux-gnueabihf/dri/v4l2_request_drv_video.so libva info: va_openDriver() returns -1 vaInitialize failed with error code -1 (unknown libva error),exit  
    To fix, add symbolic link to installed driver:
    $ sudo ln -s /usr/lib/dri/v4l2_request_drv_video.so /usr/lib/arm-linux-gnueabihf/dri/  
    And seems everything is ok
    $ vainfo libva info: VA-API version 1.7.0 libva info: User environment variable requested driver 'v4l2_request' libva info: Trying to open /usr/lib/arm-linux-gnueabihf/dri/v4l2_request_drv_video.so libva info: Found init function __vaDriverInit_1_7 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.7 (libva 2.6.0) vainfo: Driver version: v4l2-request vainfo: Supported profile and entrypoints VAProfileMPEG2Simple : VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointVLD VAProfileH264High : VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264MultiviewHigh : VAEntrypointVLD VAProfileH264StereoHigh : VAEntrypointVLD VAProfileHEVCMain : VAEntrypointVLD  
  3. Like
    Sash0k got a reaction from gounthar in Hardware Graphic/Video Acceleration in H3 Mainline   
    Hello again.
    I've compiled libva-v4l2-request for actual orangepipc 5.7.15-sunxi #20.08
    Works better than 5.4.45, no artifacts in 720p
    Patched sources: https://github.com/Sash0k/libva-v4l2-request
  4. Like
    Sash0k got a reaction from gounthar in Hardware Graphic/Video Acceleration in H3 Mainline   
    Finally got it! No kernel modifications needed, only v4l2-request.

    Key notes:
    Use bootlin code, latest master (not release-2019.03 tag) I merged just one small patch from https://github.com/bootlin/libva-v4l2-request/pull/30/files (seems, it's unecessary) Download kernel sources with corresponding version. For my armbian is: https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.4.45.tar.xz Extract 2 files from kernel/include/media mpeg2-ctrls.h and h264-ctrls.h and replace ones in v4l2-request Replace V4L2_PIX_FMT_H264_SLICE_RAW to V4L2_PIX_FMT_H264_SLICE in v4l2-request source code Compile and install (instruction is as 2 posts above) Don't forget to set VLC as in https://linux-sunxi.org/Sunxi-Cedrus  
    Tested with VLC, usable with issues:
    Artifacts in some videos h264 720p and higher, for example: https://imgur.com/nYFArT4 (360/480 works fine) Scaling (fullscreen, resizing) not works, slowdown with message [a310cb88] main filter error: Failed to create video converter Minor issues in console output on playback (see bold)  
    Thanks to: @jernej for this post:
     
  5. Like
    Sash0k got a reaction from gounthar in Cedrus on Armbian   
    Hello. Thanks to you post, i've started VPU acceleration in H3 (OrangePI PC). For your SBC seems it will be the same.
     
     
    Seems, it will be better to upgrade backend headers, than downgrade kernel
     
     
    Try this patch: https://github.com/bootlin/libva-v4l2-request/pull/30/files
     
    Details:
    https://forum.armbian.com/topic/11184-hardware-graphicvideo-acceleration-in-h3-mainline/?do=findComment&comment=105564
  6. Like
    Sash0k reacted to jernej in Mainline VPU   
    You have to make sure that libva-v4l2-request uses  same *-ctrl.h files that are in kernel sources under include/media/. For starters, just copy them over from kernel to lib source folder. Then you might need to adjust lib sources to new field names. Unless these files are completely the same, you won't have any success.
  7. Like
    Sash0k got a reaction from gounthar in Hardware Graphic/Video Acceleration in H3 Mainline   
    Unfortunately, no success.
     
    First, mainline bootlin backend is outdated, h264 broken. It has some pull requests, that not merged.
    Tryng to recompile Philipp Zabel's version, and merge his work for h264
     
     
    This version works with artifacts in VLC:

     
  8. Like
    Sash0k reacted to Kwiboo 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.
  9. Like
    Sash0k reacted to divis1969 in Cedrus on Armbian   
    I've found that the issue with h264 codec is caused by the size of the struct v4l2_ctrl_h264_slice_params defined in include/media/h264-ctrls.h (kernel) and include/h264-ctrls.h (libva-v4l2-request).
    Kernel's version adds one more field start_byte_offset with commit
    commit 5604be66a56867a784e162299a48c214921ffa1b Author: Boris Brezillon <boris.brezillon@collabora.com> Date: Fri Aug 16 13:01:24 2019 -0300 media: uapi: h264: Add the concept of decoding mode I did not find any changes in libva-v4l2-request that match this change in kernel.
    I'm going to revert the above commit to test whether this can fix the issue.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines