gounthar

I decompiled sun8i_thermal.ko, not sure what I was expecting...
This is the entirety of their "fix" compared to stock armbian: https://gist.github.com/dbeinder/6c4dac8df91fb4b1b1537bafa8136065/revisions
Yep, that's just a +30C offset shoved straight into the function, couldn't even be bothered with putting it into the struct for H2/H3, never mind chip detection...
> "BREAKING: Our engineer has solved the incorrect temperature Report about Zero LTS boards"
Good job, Xunlong, nice one

i have been updating the kernel, ffmpeg, and kodi in sequence when major new patches from @Kwiboo are updated with consistent success, minus the known issues.

Well, kernel modification is needed for better decoding (less glitches). Probably new *-ctrl.h files contain new fields (not 100% sure) which also need to be filled.
 
There is no any post processing implemented here like scaling. It would be possible to do that via SoC specific peripherals but that wouldn't be universal and thus it's out of scope of this library.
 
Anyway, I'm glad you succeeded.

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:
 

Yes, it is.
On nanopi neo air with armbian 20.08.0 (5.7.8) it works.
 
FFmpeg with 960x720 input from our camera* encode mp4 by h264_omx with 15-20 fps.  If i use cedrus264 as codec, ffmpeg can easy provide 30 fps. With default cam500b  i get 60 fps 640x480 (that is maximum of the camera).  Fps numbers i get from ffmpeg log and i think  this results is accurate enough. 
* our camera  isn't ov5640 default camera and 30 fps likely it's maximum fps. We haven't camera's datasheet. 

Anyone tried hadware encoding whit ffmpeg ?
 

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

I have reverted the following commits:
 
341772b82a3b media: cedrus: Specify H264 startcode and decoding mode 8cae93e09011 media: uapi: h264: Add the concept of start code 5604be66a568 media: uapi: h264: Add the concept of decoding mode Now I can run decoding of H264:
$ export LIBVA_DRIVER_NAME=v4l2_request $ time ffmpeg -hwaccel vaapi -hwaccel_device /dev/video0 -hwaccel_output_format vaapi -i big_buck_bunny_720p_H264_AAC_25fps_3400K.MP4 -f null /dev/null ... real 0m15.255s user 0m5.651s sys 0m1.693s Average speed is ~5.3x, fps ~130
There are some errors at the end though:
 
[AVHWFramesContext @ 0xae54cfe0] Failed to destroy surface 0x400000b: 6 (invalid VASurfaceID). Here is the test of decoding without hardware:
$ time ffmpeg -i big_buck_bunny_720p_H264_AAC_25fps_3400K.MP4 -f null /dev/null real 0m37.776s user 0m57.906s sys 0m1.983s Average speed is ~2.0x, fps ~50
I also tried to decode in software and encode in hardware. This causes crash of ffmpeg (I was not able to get a stack with gdb yet):
ffmpeg -vaapi_device /dev/video0 -i big_buck_bunny_720p_H264_AAC_25fps_3400K.MP4 -vf 'format=nv12,hwupload' -c:v h264_vaapi -an stream.mp4 ... Segmentation fault  

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.

Yes, I did. If was long time ago and I found kerberosio more attractive. There was also a performace issue with ZM on bananapi that time.
I've tested ZM recently again (on bananapi m3) and it seems using less CPU than kerberosio while movement detection. So, I would switch to ZM if it will be able to handle >1 cameras.
But I decided to first play with HW decoding on bananapi prior to migrating to ZM.
 
-----
Here are the results of my attempt to use cedrus.
- I've built libva-v4l2-request. There were few issues with it. It requires libva-dev and libdrm-dev, I've installed it with apt.
Version release-2019.03 of libva-v4l2-request failed on build due to libva-dev version mismatch (this package seems declared incorrect verion for pkg-config).
I've switched to a tip of the master branch was built successfully (but with small change in the /usr/include/linux/videodev2.h - I've added v4l2_timeval_to_ns which
is missing. BTW, I've also installed linux headers with apt, these headers contain v4l2_timeval_to_ns but libva-v4l2-request does not use these)
This lib is installed by default to /usr/lib/dri/, but libVA will search it under /usr/lib/arm-linux-gnueabihf/dri/ and I've just create a symbolic link. Maybe --prefic should be specified to autoconf instead.

- I've tried to use this lib with ffmpeg (default, installed with apt):
export LIBVA_DRIVER_NAME=v4l2_request ffmpeg -v verbose -hwaccel vaapi -hwaccel_device /dev/video0 -hwaccel_output_format vaapi -i big_buck_bunny_720p_H264_AAC_25fps_3400K.MP4 -r 5 -an stream.mp4
It produces the following error:
 
[AVHWDeviceContext @ 0x1d7a820] libva: VA-API version 1.1.0 [AVHWDeviceContext @ 0x1d7a820] libva: va_getDriverName() returns -1 [AVHWDeviceContext @ 0x1d7a820] libva: User requested driver 'v4l2_request' [AVHWDeviceContext @ 0x1d7a820] libva: Trying to open /usr/lib/arm-linux-gnueabihf/dri/v4l2_request_drv_video.so [AVHWDeviceContext @ 0x1d7a820] libva: Found init function __vaDriverInit_1_1 [AVHWDeviceContext @ 0x1d7a820] libva: va_openDriver() returns 0 [AVHWDeviceContext @ 0x1d7a820] Initialised VAAPI connection: version 1.1 [AVHWDeviceContext @ 0x1d7a820] Unknown driver "v4l2-request", assuming standard behaviour. Stream mapping: Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264)) Press [q] to stop, [?] for help [h264 @ 0x1d77fc0] Reinit context to 1280x720, pix_fmt: vaapi_vld v4l2-request: Unable to set control: Bad address v4l2-request: Unable to queue media request: No such file or directory [h264 @ 0x1d77fc0] Failed to end picture decode issue: 1 (operation failed). [h264 @ 0x1d77fc0] hardware accelerator failed to decode picture Kernel log also contains errors:
 
[94838.781065] cedrus 1c0e000.video-codec: Missing required codec control [94838.785428] cedrus 1c0e000.video-codec: Missing required codec control [94838.791230] cedrus 1c0e000.video-codec: Missing required codec control [94838.794613] cedrus 1c0e000.video-codec: Missing required codec control - I've built v4l2-request-test and play with it. Initially it complains "Unable to start display engine" so, I've commented this functionality (so it can decode, but does not try to display frames).
This suite contains several test packages (frames). MPEG2 tests works perfectly (decoding only, as I said).
H265 tests fail with error Processing frame 1/50 Loaded 145064 bytes of video slice data Unable to set control: Bad address There was no kernel errors.
H264 tests are disabled because of absence of V4L2_PIX_FMT_H264_SLICE in the system headers (linux headers contain it but autoconf does not see those).
 
Any suggestions how to enable H264? Should I also rebuild the kernel? What's wrong with H265?

Encoding using cedrus264 was for legacy kernel.
I think Uboborov has done some work with mainline kernel for encoding with cedrus. Search the forum for "encoding" or uboborov

most scripts are not pbp specific, but that has been the focus so i am not sure for other devices. i would say test and give feedback after reading the scripts. i will be making these more generic as i expect to get a few HardRock64 devices when they are available.
 
the most specific is the linux build script because of the pbp patch and kernel config, but you can override this with KERNELCONFIG and use your own config to build for almost any rockchip device. I will make the pbp patch overrideable.
 
back on topic:
 
kwiboo's linux-rockchip WIP branch is working great - and we have a LOT of activity for v4l2 and rkvdec on linux-media. excited for 5.9.
 
kwiboo's ffmpeg 4.3 branch patch applies to 4.3.1 and master as well as release/4.3 -- all working well!
 
i shared the vp9 file that gives me problems above. the same file decodes fine with intel vaapi.
 
the ffmpeg frontend still does not share v4l2request support, so software that uses libavcodec like mpv are still broken due to lack of decoder detection and selection capability.
 
wildly thankful for the work of kwiboo and jernej and others. thanks!
 
 
 
 

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:

 

Hi @Kwiboo,
 
I did some testing using your version 2 of the patch:
1) Few seconds after starting the video, the screen gets blank for few seconds.
2) If the decoder gets stuck is hard to make it work again. I tried the soft reset patch does not help much.
A sample video is here (has few missing packets): https://minisatip.org/tmp/tmp2.ts
 
Thanks

What i know orange pi has two microphone option.
 
1- on board microphone
2 - from audio in out
 
When i check with arecord -l
 
i see only one card which is realtek5651
 
ı have tried voice record with arecord. ı couldnt get any voice.
 
with usb sound card i can record.
 
i can listen with on board auido out.
 
Why i can not get any voice from on board microphone or audio in.?
 
you can see my alsa values
http://alsa-project.org/db/?f=351ef8f0285ef89eaa267f2b7ff9866f06ef3413
 
you can see all informations
http://ix.io/2rH8

I guess they rebranded an armbian image which includes alternative drivers for xradio and added the temperature fix....

I installed Orange Pi's version of Ubuntu Bionic server with kernel 5.34.27 mentioned in the tweet refered to by @gounthar above on a Orange Pi Zero LTS V1.5 board, and it has indeed fixed the temperature reporting problem.  The onboard wifi is working flawlessly, too.

I have some work-in-progress patches at https://github.com/Kwiboo/linux-rockchip/compare/next-20200501...next-20200501-drm-rockchip 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 :-)

Hello Everyone!
I cannot get Gstreamer to use video acceleration on my ROC-RK3328-CC (Libre Renegade)
rockchip-gstreamer from Rockchip's github page just wont let me compile the vpudec plugin
I have tried both stretch and buster with 4.4 legacy kernel (currently on buster), but I seem to be missing one peice.
 
Here's what I do:
-Install a current Armbian Renegade Legacy image, and install all the tools necessary to compile everything.
-Git Clone and compile: Gstreamer, plugins-base, plugins-good, plugins-bad, plugins-ugly, plugins-libav
-Git Clone and compile: libmali, mpp, rockchip-gstreamer, rockchip-gstreamer-extra
during mpp compilation, I get the following warning:
 
[ 71%] Building CXX object mpp/legacy/CMakeFiles/rockchip_vpu_static.dir/vpu_api_legacy.cpp.o /home/onev/video/mpp/mpp/legacy/vpu.c: In function ‘VPUClientInit’: /home/onev/video/mpp/mpp/legacy/vpu.c:104:14: warning: this statement may fall through [-Wimplicit-fallthrough=] type = VPU_DEC; ~~~~~^~~~~~~~~ /home/onev/video/mpp/mpp/legacy/vpu.c:105:5: note: here case VPU_DEC: ^~~~ [ 71%] Building C object mpp/legacy/CMakeFiles/rockchip_vpu_static.dir/vpu_mem_legacy.c.o When I run './autogen.sh' for rockchip-gstreamer it says that vpudec will not be compiled due to unmet dependencies.
configure: *** Plug-ins with dependencies that will be built: rockchipmpp configure: *** Plug-ins with dependencies that will NOT be built: rkximage vpudec So I look at the configure.ac file, and I see it only has one dependency, and that is rockchip_vpu version 0.3.0 - [rockchip_vpu < 0.3.0]
So I check my /dev folder and both vpu_service and rkvdec devices are present.
lsmod shows neither modules are loaded, so I first do rkvdec:
sudo modprobe rkvdec
and that works, as lsmod now shows the rk_vcodec module is loaded.
next I do the vpu_service module:
sudo modprobe rockchip_vpu
and that returns to prompt with no error message, but the module is still not listed by lsmod (nothing for vpu)
So just for the heck of it, I edit the configure.ac to allow vpudec to compile without checking the dependency, and of coarse there's a bunch of errors.
This suggests that I'm missing something, possibly a library I'm overlooking?
Or perhaps its that the Rockchip Ayufun branch (which is the branch armbian installs) of the official rockchip branch of the kernel, doesn't have the latest updates from the rockchip branch?
 
Does anyone have any ideas about what I'm missing here?
 
Any hints would be sincerely appreciated

It turns out that it's been renamed to 'hantro-vpu' starting with 5.3. 
I got the kernel module compiled but now I realize there's a bunch of patches that update everything for this name changed that were not applied while using the armbian build tool.  I'll open up a new thread regarding that since it's a different issue.
 

So after looking through the device tree, I see that it's called 'video-codec'
however modprobe cant find the module...
I only see it in these locations:
 
/sys/devices/platform/ff350000.video-codec
/sys/bus/platform/devices/ff350000.video-codec
/sys/firmware/devicetree/base/video-codec@ff350000
 
it doesn't appear that I have the kernel module.
Any ideas where I can find the source code for the 'video-codec' kernel module?
 
 
 

Hello Everyone!
What is the kernel config option that I need to set to enable the VPU driver?
Background:
I'm using the most current RK3328 RENEGADE armbian image (debian non-desktop) on my ROC-RK3328-CC (Libre Renegade).
I've compiled a brand new kernel with the armbian build tool.
first, I cloned and compiled gstreamer and it's plugins from Github.
Everything works fine but no video acceleration...
So then I clone, compile, and install libmali, mpp, gstreamer-rockchip and gstreamer-rockchip-extra, and although the new pluggins are now available to gstreamer (specifically mppvideodec), whenever I try to use mppvideodec, I recieve the following error:
mpi: mpp version: 14cae9c4 author: Johnson Ding [mpp_platform]: fix wrong device getting problem mpp_rt: NOT found ion allocator mpp_rt: found drm allocator hal_h264d_api: Assertion vcodec_type & ((1 << VPU_CLIENT_RKVDEC) | (1 << VPU_CLIENT_VDPU1) | (1 << VPU_CLIENT_VDPU2)) failed at hal_h264d_init:104 hal_h264d_api: hal_h264d_init hard mode error, value=0 hal_h264d_api: Assertion 0 failed at hal_h264d_init:154 mpp_device: mpp_device_init failed to find device for coding 7 type 0 Caught SIGSEGV After searching for a while, I came across this bug report in Chinese which suggests that I don't have the RK3328 VPU driver installed:
https://translate.googleusercontent.com/translate_c?depth=1&hl=en&pto=nl&rurl=translate.google.com&sl=zh-CN&sp=nmt4&tl=en&u=https://github.com/rockchip-linux/mpp/issues/52&usg=ALkJrhiZFAGMkTKx7lz28OCXBQAmjeA8mw
I checked the kernel config (I'm using the armbian build tool to compile the newest kernel), and I do see "V4L platform devices" however this doesn't seem to be anything rockchip specific.
Since the default Armbian desktop versions seem to have video accel already enabled, I am hoping someone might be able to give me a hint as to what process I should follow in order to properly build the correct vpu-codec kernel driver for the RK3328
I see that in the RK3328 Media Script (Rock64, Renegade) post by JMMC, he has a precompiled DEB package for librockchip-vpu0...  Is this what I'm missing here?  If so, can anyone point me to the source so I could build my own?
So 2 questions:  
1.  Is there a kenrel option I should be setting in order to compile the VPU driver?  
1.  if not, which VPU driver code should I be compiling for mpp to work?
Thanks so much for your time in reading this.

Huh..it seams that it is not so simple for everyone to reach this poing to have a HW acceleration on H3.
My goal is to reach transcoding from h264 full HD as input stream (satillite stream from enigma2 receivers) and lower down the resolution to SD in h264 with FFmpeg.
I compiled myself the ffmpeg with h264 and libfdk-aac.
All this working even without HW but from SD to SD.
Is there some detail tutorial how can I reach this point?
Thx!

I am absolutely unqualified to give an answer here but out of curiosity I searched the error and found you may not have to specify an option to use neon?
 
https://stackoverflow.com/questions/29851128/gcc-arm64-aarch64-unrecognized-command-line-option-mfpu-neon

An USB video sink is a standard USB host port consuming the video via UVC function. I.e. you plug in a USB webcam in your USB port and you get a /dev/videoX device.
This will not work quite well due to the bandwidth requirement for the raw video. Using native Ethernet would already be a challenge.
The proper way is to use hardware encoders at the host and forward the processed stream. With zero copy (dma_buf) video pipeline this puts little strain on the CPU.