JMCC

Rev 1.3

Okay, kernel panic also happens with 20.08.14. But board boots perfectly with 20.08.1

I am getting kernel panic on my Rockpi-4b legacy, both with the images I build and also when I switch to nightly from a 20.8 image. Am I the only one?

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.

The solution is that it works with Kernel 4.9, it doesn't with 5.9. If you want that feature, then you can download the "legacy" version with the proper kernel: https://redirect.armbian.com/odroidn2/Buster_legacy.torrent

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.

Nice! BTW, someone might have noticed my new "aggresive" signature. In case someone wants to use the same image, or modify it (change the color, etc.), it is available here: https://users.armbian.com/jmcc/images/

Yes, I use tvheadend with Jellyfin. So when I am watching a SD channel, which uses MPEG2-ts, it does transcoding. Enviado desde mi moto g(6) plus mediante Tapatalk

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.

@jeanrhum AFAIK, there is only decoding support for Rockchip's mpp in FFmpeg. There is active development for Rockchip VPU in mainline, not using mpp but instead the standard v4l2-m2m API. However, again they are focusing only on decoding, so far. @gounthar Are you sure you saw some FFmpeg fork with rkmpp encoding? That would be great, but I never heard about it.

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.

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

Well, it depends on what Amlogic device you are using. If it is some TV box, then there is a specific sub-forum for them. If it is an Odroid or FriendlyElec board, then you should post in the Amlogic sub-forum. Enviado desde mi moto g(6) plus mediante Tapatalk

BTW@NicoD can you send me some link about that small screen you show on the video? Enviado desde mi moto g(6) plus mediante Tapatalk

Cool one! You really hate the Tinkerboard, haha. It was my first SBC, and my unit works quite well (stable at 2 GHz). So I kind of like it. Enviado desde mi moto g(6) plus mediante Tapatalk

You can use the Armbian build script to build your customized kernel. After you select the board and the flavor (it must be Legacy), you can also choose to have a Kernel config menu. Look for the appropriate Kernel feature (I don't know the exact name, probably use the search function and enter 'CEC'). If you get it to work, please post your results here, and maybe you can make a Pull Request and contribute to the Armbian project. Sorry, i don't own a RockPro64. You can post this question on a new thread, within this same Rockchip 3399 sub-forum.

Yes, there are plans. No timeline for it, though

Exactly, just disable your desktop by running "sudo systemctl disable lightdm.desktop", and then place kodi-gbm-wrapper in /etc/rc.local This script was intended only for testing, so you need to re-run it after every update that may affect some of its components. Besides that, of course you can and should update your system. We are preparing a fully integrated solution into the Armbian package repos, so you won't need to use the script any more. I'll post about it soon, hopefully. I'll say a few words about Kodi there.

Hello @Unicorn, The posts you link through Archive.org are also available on the regular Armbian forum, they have not been deleted. Here it is the main one: Your post is correct and according to the forum rules, I can see no reason for it to be deleted. If it disappeared temporarily, maybe it was because of a mistake made during some cleanup, or something alike. We are a small community of devs and mods dealing with plenty of stuff, so these things can happen. You are welcome to contribute and help things work better. Regards.

@martinayotte Any insights on this?

That sounds like a good way to implement these package groups. Maybe, for the sake of simplicity and easy maintenance, we could classify by board families instead of boards?

Wow, that's very interesting. It somehow responds to what I meant for the future, about Wayland etc. Though, it does not overlap with the proposal related to AR-150, since in this case it is not about desktop environments or configurations, but about a set of packages of two kinds: Libs and configs to set up HW acceleration, regardless of the DE you are going to use on top of it. Multimedia applications, that can be run under any DE, or some of them with no DE at all. On the other hand, the AR-200 solution seems to be more focused on Mainline, not Legacy. But both things are certainly related. I will try to reach @Myy to coordinate about it. @IgorBut could we at least get the packages uploaded to apt.armbian.com for this time? I have some time to do that now, but I don't know if I will be able to do it in three months from now.

Hello. Sorry for the no-show at the IRC meeting, got the COVID and that precise day I was moving back to my home after being discharged. I'm better now, thanks be to God. I have been investigating, and got to make a set of multimedia packages that will work with Buster or Focal. I think it is a good opportunity to close AR-151, and give to users some stable and well-proven multimedia solution, while exploring newer options as Mainline or Wayland for next releases. The solution would be simply a set of packages, with some base meta-package to install them all, and do the necessary configs. We could then choose to install it at build time, or make it an option in Armbian-config, or just leave it for the user to do an "apt install armbian-multimedia-xxxx". I think I can have the binary packages ready by the freeze date (this weekend), at least for some boards (RK3288, RK3399 and probably also RK3328 and XU4). @lanefu Do you think we can include it in this release?