gounthar

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.

I know this thread is over a year old, but I was finally able to get decent camera output out of the GC2035 thanks to the cedar H264 gstreamer plugin linked here!
 
I'm no gstreamer expert, but what i've been able to figure out is that after the cedar_h264enc stage of the pipeline, you need to add a h264parse stage, which you can then follow with something like matroskamux if you want to write a .mkv file, or rtph264pay if you want to send the data over the network via RTP. eg:
 
gst-launch-1.0 -ve v4l2src device=/dev/video0 \ ! video/x-raw,format=NV12,width=800,height=600,framerate=15/1 \ ! cedar_h264enc ! h264parse ! queue \ ! matroskamux ! filesink location=test.mkv  

If anyone is interested: I designed a new cover instead of the acrylic plate. I broke it because I tried to drill a hole into it to get access to the power pins:
 
I made a new one in Fusion 360 to be 3D-printed or laser cut: https://www.thingiverse.com/thing:4501621
With it you get access to all pins (power, PCIe, GPIO, serial and SPI) and the reset button. The picture is of version 1. The newer version on thingiverse has larger cutouts and holes.
 
 
 
 

Serial and power mux board is ready for ordering. However before I do so, I need to wait till SD card mux board redesign is complete at least overall idea is “approved”.
 
As previously written the major change is to switch from simple SDI interface towards SDIO one allowing full speed communication with card. This requires 8 pins thus not only mux board but also card adapter tuning. 
Recently idea under consideration is to move SD mux board away from stacking and make it more alike USB Mass Storage device. 

Awesome thanks. Let me know what $$ you need. This looks right up my alley hihi I've been a bench tech all my (professional) life.

By asking and if there will be some left ...  V1.0 has some troubles and we are working on a redesign https://github.com/armbian/mpads When we will get a new batch (ETA= unknown) I will send you one.

Hit the easy button and install OpenWRT
 
Done and done - solves your problem.
 
Move on to other interesting things with your homelab.

Been a while since I been on these forums but if I remember correctly when I did get it to 1.6ghz the temps were quite high on load even with copper shims decent thermal paste. 
 
I use mine for mining still going strong all 10 of them in a cluster.

I've been trying rosetta on kernel 5.6 and 5.7 and it just seems like it overheats and drops dead pretty quick with rosetta.  showing those temps also   have you had much luck there?

I'm cranking CPU max back now to try again.

Collabora released Wayland running on RK3399: https://www.collabora.com/news-and-blog/blog/2020/06/05/bifrost-meets-gnome-onward-upward-zero-graphics-blobs/

We will post some info this week (on our blog and by newsletter) on production progress and shipping estimate.
 
 
 
Well we have some track record of donations to Armbian, and actually we are part of the Armbian team as mvebu family maintainer until now, and you can expect us to be very active on the rockchip64/rk3399 family. So even though it's never enough, I think we are doing our share of contribution back ;-)
 
 

i may hope the temperature reading is wrong. 83 degrees Celsius wil melt your case i think.

Simple, LibreELEC heavily patches kernel and ffmpeg for better experience. Patches are slowly getting in kernel but ffmpeg patches will need far more time to be accepted (kernel must first declare this API stable which won't happen anytime soon). You also need Kodi master (e.g. Kodi 19 pre-alpha), because it has a lot of important improvements. Last but not least, only Kodi GBM (e.g no desktop environment) version really works well (zero copy playback) and soon wayland. X11 has no chances to work well.
 
TL;DR: LibreELEC uses features which are in development and not present in any stable version yet.
 
BTW, also 4K HEVC videos work well.

I had a lot of stability issues with the original Orange Pi image, and it's running like a charm with Armbian.
Thanks, folks!

I just noticed you don't even have to go to dev branch. In current it is enabled already. If your 5.4.x-current kernel is halfway up-to-date you should be able to modprobe cedrus.

Decoding H264 and X11 rendering using vdpau_sunxi, libcedrus, kernel 4.20.17, mpv, vncserver and Armbian Bionic on Orange PI Zero
libvdpau: https://github.com/uboborov/libvdpau-sunxi-H3.git
libcedrus: https://github.com/uboborov/libcedrus-H3.git
cedar_dev: https://github.com/uboborov/sunxi-cedar-mainline.git
 
mpv, ffmpeg, x11 installed using apt
 
It works extremely slow but it's just a beginning  )
video: https://www.youtube.com/watch?v=9O7L_kaEDdk
UPD:
video on Orange PI One 1280x720 HDMI (works pretty fine)
https://www.youtube.com/watch?v=8qPyOG-yJIw
 

Added in the latest version 20200423 installation of the system in eMMC for Renegade Elite (rk3399) and now perezalivayu images on the site. I checked with myself, everything works. Now I have Armbian installed on EMMC in Renegade and a new feature has appeared-direct launch of other systems immediately from USB media (the connectors on the front line work).

gounthar ,
If you intend to use rpi-monitor to control the temperatures of the sensors I recommend you to leave it alone, I use domoticz works well and it's simple, if you need more info open a new post.

@gounthar
 
how i did it with my OPZero:
 
Enable w1-gpio
 
add param_w1_pin=PA10 to armbianEnv.txt and connect your DS18B20 like these.. +------------------------------------------------+ | OPi Zero GPIO Pin | 18B20 | Widerstand | |------------------------|---------|-------------| |Pin 17 3.3V | braun | VCC |-|4,7kOhm|-¬ | |Pin 26 1-wire | blau | Data |------------ | |Pin 9 GND | schwarz | GND | | +------------------------------------------------+ Its working fine :-)