gounthar

Yep. In my tests, I've been able to transcode one HEVC 1080p and one 480p at the same time, or five simultaneous 480p (though it will depend on the bitrate of the source material). It may have trouble if you feed some HEVC 4k  material to it, particularly if it is 10-bit or high bitrate.

I'd need something that could handle two 1080p h264 or HEVC in parallel at least. I hate bottlenecks

Hi there,
 
I bought a few months ago a H616 based TV Box, and made the same kind of mistakes this week. I bought an OrangePi Zero2, also sporting a H616.
I bought the TVBox because at that time: "wow, an undocumented AllWinnner SoC!", how stupid is that?
I bought the Zero2 because CNX software gave a few hints about the SoC features, like the fact the G31 GPU is a Bitfrost GPU, meaning it supports Vulkan, and down the line, it could potentially be supported by Panfrost open-source graphics driver.
I'm still dreaming of an Armbian based video encoding SBC, and this SoC (like so many others on the paper) looks promising:
Video Decoding 10-bit H265/HEVC up tp 4Kp60 or 6Kp30 VP9 up to 4Kp60 H264/AVC up to 4Kp30 AVS2 up to 4Kp60 Encoding H.264 up to 4Kp25 or 1080p60 JPEG up to 1080p60 What do you folks think?

@Medapayne
create a /etc/asound.conf to get the analog audio card as default.
whats the output of
aplay -l
 
Mine:
 
___ ____ _ _____ / _ \| _ \(_) |__ /___ _ __ ___ | | | | |_) | | / // _ \ '__/ _ \ | |_| | __/| | / /| __/ | | (_) | \___/|_| |_| /____\___|_| \___/ Welcome to Armbian 20.08.9 Buster with Linux 5.9.1-sunxi root@opi-zero(192.168.6.99):~# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: Codec [H3 Audio Codec], device 0: CDC PCM Codec-0 [CDC PCM Codec-0] Subdevices: 1/1 Subdevice #0: subdevice #0 root@opi-zero(192.168.6.99):~# more /etc/asound.conf pcm.!default { type hw card 0 device 0 } ctl.!default { type hw card 0 } and enable [*] analog-codec in armbian-config -> system -> hardware  

Did you try to do multiple transcodings in parallel?

TL;DR: Odroid XU4/HC1/MC1

Sorry, I didn't see this post before. I have a jellyfin server on a Odroid HC1, working like a charm since long ago. HW transcoding can do 1080p with no problem. I have special ffmpeg packages for Armbian buster, in case you want them.



Enviado desde mi moto g(6) plus mediante Tapatalk

At the moment I run a local Jellyfin server on an older amd64 system which @NicoD would call a giant space heater
Anyway it would be nice if a proper SBC could replace this thing, last but not least to save a decent amount of space
 
The question is which board is capable and has the proper software support? Anyone here does have experience with video acceleration on SBCs using media servers like plex, emby, jellyfin or whatever they all may called and if so which board, which kernel and how well do things work?
 
Since the data backend is network storage the board does not need either lots of USB3 connectors (one decent is enough for caching) nor other fance stuff like PCIe or SATA.
 
Lots of SoCs are advertised to support lots of en- an decoding but in reality not often proper software support is there...
 

Done, thanks.

Done, thanks.

I think I marked that point as outdated as it has not been revisited for a long time but also have no experience with docker whatsoever to change it.
So of anyone wants to change that please go ahead:https://github.com/armbian/documentation/edit/master/docs/User-Guide_Advanced-Features.md

I personally like the PineH64 more. The same SoC, but with 3GB(4GB on-board, 1GB unusable), lower temperatures. But it gets a little less love from developers than the OPi's. For most things it is the same, but I can't garantee all hardware features will work well.
Panfrost on H6 doesn't perform well. For that the RK3399's are a lot more powerful. So OPi4. 

It was a nice board... when it was new Hope that's not your daily driver.
As long as you state it as an opinion I'm ok with it. Don't try to convince anyone it's a fact. Already enough fake news around.
For some tasks an RPi4 can be good. I love it for gaming. But I wouldn't want to use it for desktop use. I much rather use 2 good SBCs with each a display than to use a RPi4 for that.
I can also share keyboard and mouse with Barrier to make it look and feel like I'm dual screening. But I'm also no typical user.
I do believe coming from ancient M1, the RPi4 must feel like a monster. Compared to RK3399 it's still a baby.

Hi all.
I've just finished a long video special where I talk about all my SBCs. In the order how I got them.
I show the specs of all of them. Say what I like, what's bad about them. What I use them for. What SBC is best for your goal.
Here's my video, I hope you enjoy it.

Greetings, NicoD.
 
 
P.S. : Pictures of anyone else their collection? Mine are not all on this pic, no room for them all. 

Does anybody have a set of compiled FFMPEG libraries that can be used with the latest Armbian Focal release? I have difficulty compiling the branches in Kwiboo's repository and getting them to work afterwards. A set of patches that works against the release from Focal so that I could recompile the deb with those would work too.
I'm using an ASUS Tinkerboard.

We are developing AI vision app on Orange Pi 4 and Intel Movidius Neural Stick 2. Everything is working great up to FullHD with software decoders. But now we need to decode 4K video stream from RTSP to feed it to OpenCV/OpenVINO.
We could successfully use Kwiboo's ffmpeg with current Armbian 5.8.6 kernel without patches. Decoder is definitely working and we can see 120 fps with `ffmpeg -hwaccel drm -hwaccel_output_format drm_prime -i big1.avi -benchmark -f null -` (big1.avi is 3840 x 2160 h264 video).
However I can't find a way to scale it using RGA. As far as I understand it should be some kind of mem2mem filter but I'm not sure how to do it. The best I could come so far is the command: `ffmpeg -y -hwaccel drm -hwaccel_output_format drm_prime -i big1.avi -an -vf 'hwdownload,format=nv12,scale=1280:-2' -pix_fmt rgb24 -f rawvideo /dev/null` that gives about 15fps and 20% CPU usage.
So my question is how can I scale and convert to RGB888 without 4K decoded frame downloaded to the CPU?

Hello martinayotte!
 
Minutes after I posted my question, I found your first reply in another thread that lead me to the right path. I just don't replied here yesterday due to the limit of one post per day.
 
Beyond this, one of the pins was wrong. With Orange Pi PC and that sensor, the correct is use 3.3V, and not 5V. So, for the red wire, PIN 1, and not 2.
 
Now my temperature monitor system is alive and kicking!
 
Thank you very much!

I've been following @xmixahlx work on pbp-tools.  I have an rk3399 board we're developing in house (kind of) and I'm tasked with seeing what it takes to get the VPU working.  Our build system won't work with the pbp scripts but I extraced the useful bits (urls, patches, etc.) from them to get a build working with the following components.  I also wrote a BASH test script for doing validation (see link below) up to and including attempting to decode and encode to the NULL device with ffmpeg.  I'm not getting the output I'm expecting and was wondering if I've missed a step.
 
This is what I have now.  This is the order I build them as well.
        1. Linux 5.8.5 w/local config plus pbp patch
            a. url: https://github.com/xmixahlx/pbp-tools/tree/master/resources/linux/5.8
            b. linux-5.8-rc4-hwaccel_20200709.diff
        2. v4l2-utils 1.20.0 (no patches)
        3. libva (git master) with patches
            a. url: https://patch-diff.githubusercontent.com/raw/intel/libva/pull/
            b. 332.patch
            c. 340.patch
            d. patches edited based on https://github.com/xmixahlx/pbp-tools/blob/master/pbp-install-libva
        4. libva-v4l2-request (git master) with patches
            a. url: https://patch-diff.githubusercontent.com/raw/bootlin/libva-v4l2-request/pull/
            b. 30.patch
            c. 32.patch
            d. Why not 28, 29 too? (31 doesn't exist: https://github.com/bootlin/libva-v4l2-request/pulls) - I think I found these may not be needed after all, but can't remember now why I left them out.
        5. libva-utils (git master, no patches)
        6. ffmpeg n4.3.1 with patches
            a. url: https://raw.githubusercontent.com/xmixahlx/pbp-tools/master/resources/ffmpeg/4.3/
            b. ffmpeg-4.3-v4l2request-rkvdec_20200709.diff
        7. v4l2-request-test (git master, no patches)
 
The test script, which I linked at the bottom of this post, is mostly just printing out what my setup looks like and responses to various v4l2, va and ffmpeg commands suggested here, the pbp forum and for ffmpeg.  I run it like this:
 
 
I can also run it without the -t option to enable decode/encode tests but those don't work and I think that's because of what the rest of the tests are telling me.  Most important is that vainfo is not showing any profile or entrypoints. 
One important fact for my build:  drm is not enabled yet.  We have it working on a 4.4.179 kernel and are working on a port to 5.4, but I have to wait for that before I port again to 5.8.5.  Not sure if that's going to be a show stopper for testing the VPU or not.  I thought with the va interface I wouldn't need that.
 
Any tips on what to try next would be appreciated.
 
Here is the output from the test.
VPU TESTS ==== CHECK FOR DRIVERS Drivers: hantro-vpu rkvdec ==== LIST DEVICES Video Devices: /dev/video1 /dev/video2 /dev/video0 Media Devices: /dev/media1 /dev/media0 ==== DUMP FORMATS AND CONTROLS ++++ /dev/video1: |---------------------------------------------------- JPEG Compression Controls compression_quality 0x009d0903 (int) : min=5 max=100 step=1 default=50 value=50 ioctl: VIDIOC_ENUM_FMT Type: Video Capture Multiplanar [0]: 'JPEG' (JFIF JPEG, compressed) |---------------------------------------------------- ++++ /dev/video2: |---------------------------------------------------- mpeg_2_slice_parameters 0x009909fa (unknown): type=103 flags=has-payload mpeg_2_quantization_matrices 0x009909fb (unknown): type=104 flags=has-payload vp8_frame_header 0x009910d0 (unknown): type=301 flags=has-payload ioctl: VIDIOC_ENUM_FMT Type: Video Capture Multiplanar [0]: 'NV12' (Y/CbCr 4:2:0) |---------------------------------------------------- ++++ /dev/video0: |---------------------------------------------------- Codec Controls h264_level 0x00990a67 (menu) : min=0 max=15 default=0 value=0 h264_profile 0x00990a6b (menu) : min=0 max=6 default=2 value=2 vp9_profile 0x00990b00 (menu) : min=0 max=0 default=0 value=0 hevc_profile 0x00990b67 (menu) : min=0 max=2 default=0 value=0 hevc_level 0x00990b68 (menu) : min=0 max=8 default=0 value=0 h264_sequence_parameter_set 0x00990ce8 (unknown): type=110 flags=has-payload h264_picture_parameter_set 0x00990ce9 (unknown): type=111 flags=has-payload h264_scaling_matrix 0x00990cea (unknown): type=112 flags=has-payload h264_slice_parameters 0x00990ceb (unknown): type=113 flags=has-payload h264_decode_parameters 0x00990cec (unknown): type=114 flags=has-payload h264_decode_mode 0x00990ced (menu) : min=1 max=1 default=1 value=1 h264_start_code 0x00990cee (menu) : min=1 max=1 default=1 value=1 hevc_sequence_parameter_set 0x00990cf0 (unknown): type=120 flags=has-payload hevc_picture_parameter_set 0x00990cf1 (unknown): type=121 flags=has-payload hevc_slice_parameters 0x00990cf2 (unknown): type=122 [16] flags=has-payload hevc_scaling_matrix 0x00990cf3 (unknown): type=123 flags=has-payload hevc_decode_mode 0x00990cf7 (menu) : min=1 max=1 default=1 value=1 hevc_start_code 0x00990cf8 (menu) : min=1 max=1 default=1 value=1 vp9_frame_context_0 0x009918a0 (unknown): type=400 flags=has-payload vp9_frame_context_1 0x009918a1 (unknown): type=400 flags=has-payload vp9_frame_context_2 0x009918a2 (unknown): type=400 flags=has-payload vp9_frame_context_3 0x009918a3 (unknown): type=400 flags=has-payload vp9_frame_decode_parameters 0x009918a4 (unknown): type=404 flags=has-payload ioctl: VIDIOC_ENUM_FMT Type: Video Capture Multiplanar [0]: 'NV12' (Y/CbCr 4:2:0) [1]: 'NV15' (10-bit Y/CbCr 4:2:0 (Packed)) [2]: 'NV16' (Y/CbCr 4:2:2) [3]: 'NV20' (10-bit Y/CbCr 4:2:2 (Packed)) |---------------------------------------------------- ==== SHOW HW ACCELS ffmpeg version n4.3.1-Kodi Copyright (c) 2000-2020 the FFmpeg developers built with gcc 7.5.0 (GCC) configuration: --prefix=/usr --arch=arm64 --target-os=linux --cross-prefix=aarch64-linux-gnu- --enable-cross-compile --sysr oot=/home2/qsys3/src/os/../aarch64-linux-gnu/install --pkg-config=aarch64-linux-gnu-pkg-config --enable-shared --disable-doc --enable-v4l2-request --enable-libdrm --enable-libudev --enable-pic --enable-avfilter --enable-postproc --enable-pthreads --e nable-gpl --enable-nonfree --enable-version3 --toolchain=hardened --enable-avfilter --enable-libfontconfig --enable-libfreety pe --enable-libxml2 --enable-openssl --enable-protocol=file --enable-protocol=pipe --enable-hwaccel=h264_vaapi --enable-hwacc el=hevc_vaapi --enable-hwaccel=mjpeg_vaapi --enable-hwaccel=mpeg2_vaapi --enable-hwaccel=mpeg4_vaapi --enable-hwaccel=vp9_vaa pi --enable-muxer=h264 --enable-muxer=mjpeg --enable-muxer=mpeg2video --enable-muxer=mp2 --enable-muxer=mp4 --enable-muxer=mo v --enable-muxer=null --enable-demuxer=mpegvideo --enable-demuxer=h264 --enable-demuxer=hevc --enable-demuxer=mov --enable-en coder=mjpeg_vaapi --enable-encoder=vp9_vaapi --enable-encoder=vp8_v4l2m2m --enable-encoder=vp8_vp8_vaapi --enable-encoder=hev c_vaapi --enable-encoder=hevc_v4l2m2m --enable-encoder=mpeg2_vaapi --enable-encoder=h264_vaapi --enable-encoder=h264_v4l2m2m --enable-encoder=wrapped_avframe --enable-encoder=pcm_s16le --enable-decoder=mjpeg --enable-decoder=vp9 --enable-decoder=vp8 --enable-decoder=vp8_v4l2m2m --enable-decoder=vp9_v4l2m2m --enable-decoder=hevc --enable-decoder=hevc_v4l2m2m --enable-decode r=h264 --enable-decoder=webp --enable-decoder=mpeg2video --enable-decoder=mpeg2_v4l2m2m --enable-decoder=mpeg4 --enable-decod er=mpeg4_v4l2m2m --enable-rpath --extra-ldflags=-ludev --libdir=/usr/lib --shlibdir=/usr/lib libavutil 56. 51.100 / 56. 51.100 libavcodec 58. 91.100 / 58. 91.100 libavformat 58. 45.100 / 58. 45.100 libavdevice 58. 10.100 / 58. 10.100 libavfilter 7. 85.100 / 7. 85.100 libswscale 5. 7.100 / 5. 7.100 libswresample 3. 7.100 / 3. 7.100 libpostproc 55. 7.100 / 55. 7.100 Hardware acceleration methods: vaapi drm |---------------------------------------------------- ==== SHOW VAINFO ++++ /dev/video1: |---------------------------------------------------- libva info: VA-API version 1.9.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_9 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.9 (libva 2.9.0.pre1) vainfo: Driver version: v4l2-request vainfo: Supported profile and entrypoints |---------------------------------------------------- ++++ /dev/video2: |---------------------------------------------------- libva info: VA-API version 1.9.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_9 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.9 (libva 2.9.0.pre1) vainfo: Driver version: v4l2-request vainfo: Supported profile and entrypoints |---------------------------------------------------- ++++ /dev/video0: |---------------------------------------------------- libva info: VA-API version 1.9.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_9 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.9 (libva 2.9.0.pre1) vainfo: Driver version: v4l2-request vainfo: Supported profile and entrypoints |---------------------------------------------------- Tests completed.  
Here is the test script.
 
 

While adding w1-gpio in /boot/armbianEnv.txt, you don't need to add it in /etc/modules-load.d/modules.conf ...
But you need to add "param_w1_pin=PD10" in /boot/armbianEnv.txt as well, otherwise it is defaulted to PD14.

My post was edited while I was modifying it (thanks Werner for the readability), but then I couldn't save  :-(
So some adds-on here.
 
I change the set points to adapt to my fan:
... # declare -a CpuTemps=(75000 65000 55000 40000 25000 0) declare -a CpuTemps=(75000 68000 60000 50000 40000 0) # Duty cycle for each CPU temp range # declare -a DutyCycles=(40000 6000 3000 2000 1500 0) declare -a DutyCycles=(40000 30000 20000 12000 8000 0) ... After modifying the script, don't forget to restart  the service:
# systemctl restart pwm-fan.service

When starting, the fan will run for 10 s, which shows the service is working. Then it will stop and restart only if the temperature is above the lower temperature threshold and the corresponding duty cycle high enough to allow the fan to start. This may need some trials to find the correct values, as each fan reacts differently.

I exchanged the radiator provided with the sataHat by a bigger one, as the original was getting very hot  (cannot keep a finger on it), even when the system was idle. Now temperatures of both the radiators of nanoPi and sataHat are similar (finger feeling again ;-)
 
It would be nice also to include temperature of the sataHat in the script, but I cannot find it. Is it measured and if yes, where is it available ?
 

None of these images work on H5. 
Unfortunetely, encoder doesn't work on H5

Fix sound HDMI for Renegade Elite
 
 
 
 
 

I installed this u-boot ontop of my already running armbian eMMC install and boot time improved dramatically... and it will boot from sdcard if one is inserted

i just downloaded files and followed instructions
 
https://github.com/pcm720/u-boot-build-scripts/releases/tag/v2020.07-1

Process of rebuilding all images for all boards takes at least 3-4 days to finish. If all went well. Sometimes this process breaks and its usually best to start with a new version ... another 3-4days.  It also creates a lot of traffic, heat, noise (currently fastest build server is stationed in office environment) and other related non-ecological impacts to the planet  

We only rebuild ALL images:
- when there is no other way / urgent
- major releases (few times per year)

Refer to this C library: https://github.com/luoyi/h3-gpio which seems quite fast, and read this comment.
 
It appears 10Mhz should be doable, but only if you do not read the value of the GPIO. So cache the latest value of the GPIOs locally in your code as a local variable if say, you need to do bit manipulation.
 

If you are successfully running Armbian on your device - whatever it may be - and the targeted conference app has armhf or arm64 Debian binary packages available I do not see a reason why this should not work.
 
tl;dr: Just DO it!
 
 
Btw. if you are unsure about your English you can also try to write in your native language and use Google translator which has pretty decent AI to get the context of stuff correctly.