gounthar

Link to donate for the server 
May we know more about the ARM64 server? What cores? How many? What frequency? What cooling? Just any info  

At least people that work on development can mitigate this frustration when catching the bug or fixing the problem.
 
 
We just got ARM64 server on our hand as a donation from:
 


https://www.worksonarm.com/
https://github.com/WorksOnArm/cluster
 
but it will only be available for limited time and before we can use it in production, we need to port our build system to support native building, test and then start using it in production. 
 
 
Fastest build server we will need to purchase - we still need a major CPU upgrade on cross compilation server. Something in range of Threadripper 3970x / 3990x + board + pci4 ssd in raid0 + 128GB memory which will costs us ∼6000 EUR.
 
Our current aging 5 years old Dual Xeon E5-2683 build/CI server was also purchased with help from community and I hope we will also receive help!

Call to Action: Armbian donation round.
 
Dear members of the community, 
 
Do you love the armbian OS? 
Are you frustrated by bugs or problems within armbian? 
Do you wish that armbian was even better with more releases? 
 
If the answer is yes keep reading because there may be a solution. 
 
As you know the dedicated team of developers here code this project in their spare time to develop an incredible Linux OS for our ARM devices. They do this for the love of this hobby and we all benefit from it because it is an open source project.
 
One of the hurdles is the fast compiling of the armbian OS. To solve this issue the developers are looking to purchase or rent an 80 core ARM build server. This will improve compilation times and therefore the workflow of the developers. It will mean that they can develop at a much faster pace and more importantly diagnose problems, optimize code and iron out bugs a lot more effectively and efficiently.
 
The developers are currently considering the Ampere Altra. 
 
https://www.anandtech.com/show/15949/ampere-altra-1p-server-pictured-gigabytes-2u-with-80-arm-n1-cores-pcie-40-and-ccix
 
To make this a reality I, on behalf of the development team, am asking for everybody to chip in. If everybody donates just a little bit the developers will be able to get this server and develop the armbian software that we all love so much.
 
What are you waiting for? 
 
Hit subscribe in the menu of the forum. Every major payment method is accepted.

I've got my RK3399's with the M4 and M4V2. Plenty enough. It will not perform any differnt.
Why don't you write a review about it on the forum? And if you want, you can film a few things and I can put it in a video for you.
Shipping in Europe is also pretty expensive. But thanks for the offer.

P.S.: Amazing gaming Armbian image almost available for RK3399 made by @Salvador Liébana. I'm now making a preview video about it.
Box86 installed. So x86 linux games, and Windows games/programs are possible on RK3399.

@NicoD I can forward mine to you for review once I put together three posts as it was asked for by Firefly.

Yes I am. From Belgium.
I sent them a mail but didn't get an answer.
I couldn't put a message on the forum.

All kernel and header packages for the sunxi family are built from https://github.com/megous/linux/tree/orange-pi-5.9

https://wiki.friendlyarm.com/wiki/index.php/NanoPi_R4S
 
I am really excited about this board.
 
 
 
https://www.cnx-software.com/2020/11/12/nanopi-r4s-headless-rk3399-sbc-features-up-to-4gb-ram-dual-gigabit-ethernet-usb-3-0-ports/
The first comments below this blogpost are also not so bad besides the fact that USB-C is power-in only.
 

Excellent! Good luck with it.
 
However, I want to make some clarifications for people following the thread. As I said above, when I talk about transcoding, I am always thinking about HEVC sources, since h.264 sources don't need transcoding. XU4, therefore, will use SW to decode the HEVC, and HW to encode into h.264. That is how acceleration works.
 
As a matter of fact, if you force ffmpeg in command line to do both HW decoding and encoding (e.g., from h.264 to h.264 in XU4), it will have a negative impact on performance, versus using SW decoding and HW encoding. Again, we are always talking about the XU4 v4l2-m2m encoder, AFAIK the only ARM encoder currently supported by ffmpeg besides RPi.

Good news! I got to compile a highly optimized ffmpeg binary from a current git, with XU4 tweaks, that is able to encode two simultaneous 1080p@25, as long as the source bitrate is not excessive.
 
You can download and give it a try from here. It is completely static, so you can install it on any distro. It will install the binary in "/opt/ffmpeg-xu4/bin/ffmpeg", and a symlink "/usr/local/bin/ffmpeg-xu4". Therefore, it can be installed along the system ffmpeg without conflicts.

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...