pbp-tools
pbp-tools copied to clipboard
kernel 5.10 mainline?
I tried this scripts and it works well, I built kernel 5.8.5. Is there a way to build a newer kernel (such as kernel 5.10) with this script?
5.10.17 has mainlined the kernel drivers so I don't think you need the kernel script anymore. I built
- libva
- libva-utils
- libva-request-api
- ffmpeg
- libva-v4l2-request
But decoding doesn't appear to work. The reason appears to be that there are no supported profiles or entry points. The output from vainfo shows this for /dev/video0 (which should be the rkvdec driver/decoder).
libva info: VA-API version 1.11.0
libva info: User environment variable requested driver 'v4l2_request'
libva info: Trying to open /usr/lib/dri/v4l2_request_drv_video.so
libva info: Found init function __vaDriverInit_1_11
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.11 (libva 2.11.0.pre1)
vainfo: Driver version: v4l2-request
vainfo: Supported profile and entrypoints
If you try to decode a video you get this (buried in the output):
$ ffmpeg -loglevel debug -hwaccel vaapi -vaapi_device /dev/video -i big_buck_bunny_480p_H264_AAC_25fps_1800K_short.MP4 -vf 'format=nv12,hwupload' -map 0:0 -map 0:1 -threads 8 -aspect 16:9 -y -f matroska -acodec copy -b:v 12500k -vcodec h264_vaapi -
...
[h264 @ 0xaaaaeccc7d20] Format vaapi_vld chosen by get_format(). [h264 @ 0xaaaaeccc7d20] Format vaapi_vld requires hwaccel initialisation. [h264 @ 0xaaaaeccc7d20] No support for codec h264 profile 578. [h264 @ 0xaaaaeccc7d20] Failed setup for format vaapi_vld: hwaccel initialisation returned error.
I've seen references to using /dev/dri/renderD128 instead of /dev/video0 but that gets the same results.
I'm wondering if the libva and ffmpeg versions need to be bumped now too. Does anyone know the state of these usespace libs and tools for rkvdec va-api? Or where I could ask abou them?
I've fixed some bugs in my test script that now show vainfo correctly. The updated script is vputests.sh, as in this example.
|----------------------------------------------------
++++ /dev/video0: |
---|
LIBVA_DRIVER_NAME=v4l2_request vainfo --display drm --device /dev/video0 libva info: VA-API version 1.11.0 libva info: User environment variable requested driver 'v4l2_request' libva info: Trying to open /usr/lib/dri/v4l2_request_drv_video.so libva info: Found init function __vaDriverInit_1_11 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.11 (libva 2.11.0.pre1) vainfo: Driver version: v4l2-request vainfo: Supported profile and entrypoints VAProfileH264Main : VAEntrypointVLD VAProfileH264High : VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264MultiviewHigh : VAEntrypointVLD VAProfileH264StereoHigh : VAEntrypointVLD VAProfileHEVCMain : VAEntrypointVLD
I also ported the kernel patch to 5.10.17. Before and after the patch I have only seen what appears to be HW accelleration with mpeg2video files. H264 doesn't not appear to be getting accelerated based on CPU uage. I'll attach the updated patch to this post.
linux-5.10.17-hwaccel_20210312.txt
I've also created my own sample files using OpenShot to save in H264, mpeg2video and mpeg4 formats (I'm not trying VP9 because its not one of our use cases) as 720p 25fps 1280x720 videos in MP4 and AVI containers. The videos are longer than most of the samples I've been using to give me a chance to watch CPU usage over time. That's how I'm testing if HW accel is apparently working. With mpeg2video I'm seeing about 7% CPU usage. With the others it varies from about 50% to 80% cpu usage.
I tried kwiboo's ffmpeg but there was no difference in the tests.
At this point I'm convinced that only mpeg2video are HW accelerated with the upstreamed hantro/rkvdec drivers plus the patches available here to both the kernel and user space utilities for VAAPI support.
there is a particular order to update patches, which you can see at LibreElec (patches by Kwiboo) beginning with the kernel, then ffmpeg. a year ago it was clear that the VAAPI implementation was abandoned. the code would need to be updated for the numerous kernel changes that have occurred, and the folks doing that work decided that there were better options to pursue such as gstreamer. only MPEG was working. you can see more information in the forum links on the main readme.
hardware acceleration IS working for the formats you mentioned, but you have to have a patched kernel and patched ffmpeg, and use specific tools: ffmpeg or GBM, which only kodi has (had) properly implemented. i have tested this extensively and the kodi experience is fantastic.
my setup was working well so I have not updated in a long time, but i do plan on updating these patches and scripts throughout the next few weeks.
Just a followup: I was able to ingest and decode 4 RTSP H.264 1080p streams @ 30fps with minimal CPU overhead. The trick was to use the drm interface and finding a reasonable ffmpeg command, which (for reference) is:
ffmpeg -y -hwaccel drm -hwaccel_device /dev/dri/renderD128 -rtsp_transport tcp -i rtsp://192.168.101.83/stream -rtsp_transport tcp -i rtsp://192.168.101.83/stream -rtsp_transport tcp -i rtsp://192.168.101.83/stream -rtsp_transport tcp -i rtsp://192.168.101.83/stream -threads 1 -f null -
This was done using 5.10.17 with the updated kernel patch plus the patches for ffmpeg.
Thanks for your work on this!