gounthar

But a page for the H616 proccesor was created.

The only HW acceleration that is going to work among Armbian-supported boards is XU4. Besides that, it's Intel or RPi. Or, of course, SW transcoding.

the distro natively packaged versions are new enough for my use these days.. I just do code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } apt install docker.io

Wait, you mentioned h264. You are aware that h264 normally doesn't need transcoding, right? The server just feeds the stream to the client, so the limit is set by your network connection and/or your storage device. You can stream many h264 streams of any resolution at once, even 4k.
 
Transcoding is only needed when the file is in a format that the client cannot handle natively. So, for example, if you are using Chrome browser as client, it cannot handle HEVC, and therefore it needs transcoding. But, if your client is Kodi with Jellyfin plugin, then you won't need transcode either for HEVC, since Kodi can handle it.
 
Since almost all clients support h264, it will normally not be transcoded. And, if you want, you can convert all your videos to h264, and then you can use any SBC as server, even with a weak CPU.

Done, thanks.

I think this could be an interesting soc, but in how many months (or years)?
This soc is not referenced in sunxi status matrix and nothing is planned in kernel 5.11, so I fear that support is not even started from their side. Maybe it's close enough to h6, but I didn't see any information about somebody able to start linux with it and it has a different gpu.
 

Isn't there a port of ffmpeg that permits hardware encoding for RK3399? I think I saw it there.

The only Armbian-supported VPUs that can handle that are Rockchips. But there is no FFmpeg support for encoding, only Gstreamer. So no Jellyfin either.

You can try SW transcoding in a Odroid N2+, and see if it can cope with it. Otherwise, you must go for some Intel SBC, or probably RPi4.

Enviado desde mi moto g(6) plus mediante Tapatalk

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.