JMCC

ANNOUNCEMENT: The media script is now deprecated, in favor of the official Legacy Multimedia Framework. Please refer to this topic:
 

IT'S FINALLY HERE...

THE OFFICIAL ROCKCHIP-LEGACY MULTIMEDIA INTEGRATION
 
After two years of using a separate script to enable the multimedia features in RK3288/3328 Legacy Kernel, the whole framework has been incorporated to the official Armbian packaging system. The choice distro for this integration is Debian Buster (see FAQ at the end of this post about the reasons).
 
I. Installation
Download a Armbian Buster Legacy Desktop image for your board, and install it with the standard Armbian method. Install the complete multimedia solution with sudo apt update && sudo apt upgrade sudo apt install media-buster-legacy-tinkerboard --install-recommends ## Or ## sudo apt install media-buster-legacy-rk3328 --install-recommends The switch "--install-recommends" will add the whole Kodi binary addons collection (retro-gaming cores, music visualizations, screensavers, additional media decoders/encoders, vfs, etc.), plus the GLES-to-OpenGL wrapper "gl4es".  
II. Features
Accelerated GLES/EGL X desktop: No action needed. Accelerated Chromium, with WebGL and video display acceleration: No action needed Desktop video player capable of smooth 4K HEVC-HDR: Use the "Rockchip Gst Player" from the Multimedia menu, or choose it with right-click on the media file. Command-line 4K playing is also possible with "gst-play-1.0 --videosink=kmssink". RKMPP-accelerated MPV: Use normally for standard operation (windowed with mouse-operated GUI). For fullscreen, keyboard-operated mode, use the command line switch "--gpu-context=drm" (this will allow you to play smooth 4K).
        - See instructions below, in the next post, for playing Youtube videos up to 4k with this MPV. ISP Camera with real-time h.264/1080p HW encoding (RK3288 only): Using the Gstreamer Plugin. Check this wiki for instructions on how to use it. Most of it applies to Armbian, except for the selection of ov5647/imx219 camera, which must be done using DT overlays. OpenCL 1.2 support (RK3288 only): It will be fully functional, no further action needed. You can download some tests and examples from this link. Kodi 18.9 Leia with full RKMPP+GBM acceleration, 4K-HDR capable: You can start it from Light DM menu as your user account: 
 
Alternatively, you can also run it as a system service with these command lines: sudo systemctl disable lightdm sudo systemctl enable kodi-gbm sudo reboot  
Full collection of Kodi binary add-ons: Includes retrogaming cores, media encoders and decoders, PVR, screensavers, vfs and audio visualizations. They are all installed with the package "kodi-addons-full", but are disabled by default. They need to be enabled individually within the Kodi GUI. OpenGL 2.1 support through the gl4es wrapper: It is installed with the package "gl4es", with no further action needed.  
III. Sources
This is the list of the sources used for the packages:
 
IV. FAQ
¿Why did you use Debian Buster as a base for this implementation?
It was the most appropriate for several reasons. Upstream Rockchip-Linux developers use Debian buster, so the software could be ported with less modifications than if we chose a different distro. Besides, it is a completely stable distro, unlike Bullseye, which is a moving target as of today. It also has Chromium as a package, unlike Focal that uses snap instead. For last, it has a good backports repo, with several libs that would otherwise need to be compiled and maintained if we chose, for example, Focal.
  ¿Why Legacy instead of Mainline?
This is an implementation based on the vendor's BSP kernel. It has been tested and is reliable, which many people will prefer rather than having a bleeding-edge, less stable implementation. In addition to that, Mainline upstream multimedia support is still a WIP, and lacks many features that are only present on Legacy kernels.
  ¿Will you add new features to this implementation?
No, this implementation will only receive bug fixes if necessary. From now on, all multimedia work will be focused on Mainline and recent distros (like Focal or Bullseye). All new features will go there.

I just posted the announcement for the official Armbian Rockchip Legacy Multimedia Framework. As you can see on the announcement, I say that from now on all multimedia work will be done in Mainline.
 
That means integrating GPU and VPU acceleration into the official Armbian repos. The timeline is for next Armbian release, in February, if possible.
 
As of today, I am planning to include Kodi and MPV. So if anybody wants to help, it will be much appreciated. 

I just posted the announcement for the official Armbian Rockchip Legacy Multimedia Framework. As you can see on the announcement, I say that from now on all multimedia work will be done in Mainline.
 
That means integrating GPU and VPU acceleration into the official Armbian repos. The timeline is for next Armbian release, in February, if possible.
 
As of today, I am planning to include Kodi and MPV. So if anybody wants to help, it will be much appreciated. 

IT'S FINALLY HERE...

THE OFFICIAL ROCKCHIP-LEGACY MULTIMEDIA INTEGRATION
 
After two years of using a separate script to enable the multimedia features in RK3399 Legacy Kernel, the whole framework has been incorporated to the official Armbian packaging system. The choice distro for this integration is Debian Buster (see FAQ at the end of this post about the reasons).
 
I. Installation
Download a Armbian Buster Legacy Desktop image for your board, and install it with the standard Armbian method. Install the complete multimedia solution with sudo apt update && sudo apt upgrade sudo apt install media-buster-legacy-rk3399 --install-recommends The switch "--install-recommends" will add the whole Kodi binary addons collection (retro-gaming cores, music visualizations, screensavers, additional media decoders/encoders, vfs, etc.), plus the GLES-to-OpenGL wrapper "gl4es".
 
II. Features
Accelerated GLES/EGL X desktop: No action needed. Accelerated Chromium, with WebGL and video display acceleration: No action needed Desktop video player capable of smooth 4K HEVC-HDR: Use the "Rockchip Gst Player" from the Multimedia menu, or choose it with right-click on the media file. Command-line 4K playing is also possible with "gst-play-1.0 --videosink=kmssink". RKMPP-accelerated MPV: Use normally for standard operation (windowed with mouse-operated GUI). For fullscreen, keyboard-operated mode, use the command line switch "--gpu-context=drm" (this will allow you to play smooth 4K).
        - See instructions below, in the next post, for playing YouTube videos up to 4K with this MPV.
ISP Camera with real-time h.264/1080p HW encoding: Using the Gstreamer Plugin. Check this wiki for instructions on how to use it. Most of it applies to Armbian, except for the selection of ov5647/imx219 camera, which must be done using DT overlays. OpenCL 1.2 support: It will be fully functional, no further action needed. You can download some tests and examples from this link. Kodi 18.9 Leia with full RKMPP+GBM acceleration, 4K-HDR capable: You can start it from LightDM menu as your user account: 


Alternatively, you can also run it as a system service with these command lines: sudo systemctl disable lightdm sudo systemctl enable kodi-gbm sudo reboot Full collection of Kodi binary add-ons: Includes retrogaming cores, media encoders and decoders, PVR, screensavers, vfs and audio visualizations. They are all installed with the package "kodi-addons-full", but are disabled by default. They need to be enabled individually within the Kodi GUI. OpenGL 2.1 support through the gl4es wrapper: It is installed with the package "gl4es", with no further action needed.  
III. Sources
This is the list of the sources used for the packages:
 
IV. FAQ
¿Why did you use Debian Buster as a base for this implementation?
It was the most appropriate for several reasons. Upstream Rockchip-Linux developers use Debian buster, so the software could be ported with less modifications than if we chose a different distro. Besides, it is a completely stable distro, unlike Bullseye, which is a moving target as of today. It also has Chromium as a package, unlike Focal that uses snap instead. For last, it has a good backports repo, with several libs that would otherwise need to be compiled and maintained if we chose, for example, Focal.
  ¿Why Legacy instead of Mainline?
This is an implementation based on the vendor's BSP kernel. It has been tested and is reliable, which many people will prefer rather than having a bleeding-edge, less stable implementation. In addition to that, Mainline upstream multimedia support is still a WIP, and lacks many features that are only present on Legacy kernels.
  ¿Will you add new features to this implementation?
No, this implementation will only receive bug fixes if necessary. From now on, all multimedia work will be focused on Mainline and recent distros (like Focal or Bullseye). All new features will go there.

IT'S FINALLY HERE...

THE OFFICIAL ROCKCHIP-LEGACY MULTIMEDIA INTEGRATION
 
After two years of using a separate script to enable the multimedia features in RK3399 Legacy Kernel, the whole framework has been incorporated to the official Armbian packaging system. The choice distro for this integration is Debian Buster (see FAQ at the end of this post about the reasons).
 
I. Installation
Download a Armbian Buster Legacy Desktop image for your board, and install it with the standard Armbian method. Install the complete multimedia solution with sudo apt update && sudo apt upgrade sudo apt install media-buster-legacy-rk3399 --install-recommends The switch "--install-recommends" will add the whole Kodi binary addons collection (retro-gaming cores, music visualizations, screensavers, additional media decoders/encoders, vfs, etc.), plus the GLES-to-OpenGL wrapper "gl4es".
 
II. Features
Accelerated GLES/EGL X desktop: No action needed. Accelerated Chromium, with WebGL and video display acceleration: No action needed Desktop video player capable of smooth 4K HEVC-HDR: Use the "Rockchip Gst Player" from the Multimedia menu, or choose it with right-click on the media file. Command-line 4K playing is also possible with "gst-play-1.0 --videosink=kmssink". RKMPP-accelerated MPV: Use normally for standard operation (windowed with mouse-operated GUI). For fullscreen, keyboard-operated mode, use the command line switch "--gpu-context=drm" (this will allow you to play smooth 4K).
        - See instructions below, in the next post, for playing YouTube videos up to 4K with this MPV.
ISP Camera with real-time h.264/1080p HW encoding: Using the Gstreamer Plugin. Check this wiki for instructions on how to use it. Most of it applies to Armbian, except for the selection of ov5647/imx219 camera, which must be done using DT overlays. OpenCL 1.2 support: It will be fully functional, no further action needed. You can download some tests and examples from this link. Kodi 18.9 Leia with full RKMPP+GBM acceleration, 4K-HDR capable: You can start it from LightDM menu as your user account: 


Alternatively, you can also run it as a system service with these command lines: sudo systemctl disable lightdm sudo systemctl enable kodi-gbm sudo reboot Full collection of Kodi binary add-ons: Includes retrogaming cores, media encoders and decoders, PVR, screensavers, vfs and audio visualizations. They are all installed with the package "kodi-addons-full", but are disabled by default. They need to be enabled individually within the Kodi GUI. OpenGL 2.1 support through the gl4es wrapper: It is installed with the package "gl4es", with no further action needed.  
III. Sources
This is the list of the sources used for the packages:
 
IV. FAQ
¿Why did you use Debian Buster as a base for this implementation?
It was the most appropriate for several reasons. Upstream Rockchip-Linux developers use Debian buster, so the software could be ported with less modifications than if we chose a different distro. Besides, it is a completely stable distro, unlike Bullseye, which is a moving target as of today. It also has Chromium as a package, unlike Focal that uses snap instead. For last, it has a good backports repo, with several libs that would otherwise need to be compiled and maintained if we chose, for example, Focal.
  ¿Why Legacy instead of Mainline?
This is an implementation based on the vendor's BSP kernel. It has been tested and is reliable, which many people will prefer rather than having a bleeding-edge, less stable implementation. In addition to that, Mainline upstream multimedia support is still a WIP, and lacks many features that are only present on Legacy kernels.
  ¿Will you add new features to this implementation?
No, this implementation will only receive bug fixes if necessary. From now on, all multimedia work will be focused on Mainline and recent distros (like Focal or Bullseye). All new features will go there.

IT'S FINALLY HERE...

THE OFFICIAL ROCKCHIP-LEGACY MULTIMEDIA INTEGRATION
 
After two years of using a separate script to enable the multimedia features in RK3399 Legacy Kernel, the whole framework has been incorporated to the official Armbian packaging system. The choice distro for this integration is Debian Buster (see FAQ at the end of this post about the reasons).
 
I. Installation
Download a Armbian Buster Legacy Desktop image for your board, and install it with the standard Armbian method. Install the complete multimedia solution with sudo apt update && sudo apt upgrade sudo apt install media-buster-legacy-rk3399 --install-recommends The switch "--install-recommends" will add the whole Kodi binary addons collection (retro-gaming cores, music visualizations, screensavers, additional media decoders/encoders, vfs, etc.), plus the GLES-to-OpenGL wrapper "gl4es".
 
II. Features
Accelerated GLES/EGL X desktop: No action needed. Accelerated Chromium, with WebGL and video display acceleration: No action needed Desktop video player capable of smooth 4K HEVC-HDR: Use the "Rockchip Gst Player" from the Multimedia menu, or choose it with right-click on the media file. Command-line 4K playing is also possible with "gst-play-1.0 --videosink=kmssink". RKMPP-accelerated MPV: Use normally for standard operation (windowed with mouse-operated GUI). For fullscreen, keyboard-operated mode, use the command line switch "--gpu-context=drm" (this will allow you to play smooth 4K).
        - See instructions below, in the next post, for playing YouTube videos up to 4K with this MPV.
ISP Camera with real-time h.264/1080p HW encoding: Using the Gstreamer Plugin. Check this wiki for instructions on how to use it. Most of it applies to Armbian, except for the selection of ov5647/imx219 camera, which must be done using DT overlays. OpenCL 1.2 support: It will be fully functional, no further action needed. You can download some tests and examples from this link. Kodi 18.9 Leia with full RKMPP+GBM acceleration, 4K-HDR capable: You can start it from LightDM menu as your user account: 


Alternatively, you can also run it as a system service with these command lines: sudo systemctl disable lightdm sudo systemctl enable kodi-gbm sudo reboot Full collection of Kodi binary add-ons: Includes retrogaming cores, media encoders and decoders, PVR, screensavers, vfs and audio visualizations. They are all installed with the package "kodi-addons-full", but are disabled by default. They need to be enabled individually within the Kodi GUI. OpenGL 2.1 support through the gl4es wrapper: It is installed with the package "gl4es", with no further action needed.  
III. Sources
This is the list of the sources used for the packages:
 
IV. FAQ
¿Why did you use Debian Buster as a base for this implementation?
It was the most appropriate for several reasons. Upstream Rockchip-Linux developers use Debian buster, so the software could be ported with less modifications than if we chose a different distro. Besides, it is a completely stable distro, unlike Bullseye, which is a moving target as of today. It also has Chromium as a package, unlike Focal that uses snap instead. For last, it has a good backports repo, with several libs that would otherwise need to be compiled and maintained if we chose, for example, Focal.
  ¿Why Legacy instead of Mainline?
This is an implementation based on the vendor's BSP kernel. It has been tested and is reliable, which many people will prefer rather than having a bleeding-edge, less stable implementation. In addition to that, Mainline upstream multimedia support is still a WIP, and lacks many features that are only present on Legacy kernels.
  ¿Will you add new features to this implementation?
No, this implementation will only receive bug fixes if necessary. From now on, all multimedia work will be focused on Mainline and recent distros (like Focal or Bullseye). All new features will go there.

IT'S FINALLY HERE...

THE OFFICIAL ROCKCHIP-LEGACY MULTIMEDIA INTEGRATION
 
After two years of using a separate script to enable the multimedia features in RK3399 Legacy Kernel, the whole framework has been incorporated to the official Armbian packaging system. The choice distro for this integration is Debian Buster (see FAQ at the end of this post about the reasons).
 
I. Installation
Download a Armbian Buster Legacy Desktop image for your board, and install it with the standard Armbian method. Install the complete multimedia solution with sudo apt update && sudo apt upgrade sudo apt install media-buster-legacy-rk3399 --install-recommends The switch "--install-recommends" will add the whole Kodi binary addons collection (retro-gaming cores, music visualizations, screensavers, additional media decoders/encoders, vfs, etc.), plus the GLES-to-OpenGL wrapper "gl4es".
 
II. Features
Accelerated GLES/EGL X desktop: No action needed. Accelerated Chromium, with WebGL and video display acceleration: No action needed Desktop video player capable of smooth 4K HEVC-HDR: Use the "Rockchip Gst Player" from the Multimedia menu, or choose it with right-click on the media file. Command-line 4K playing is also possible with "gst-play-1.0 --videosink=kmssink". RKMPP-accelerated MPV: Use normally for standard operation (windowed with mouse-operated GUI). For fullscreen, keyboard-operated mode, use the command line switch "--gpu-context=drm" (this will allow you to play smooth 4K).
        - See instructions below, in the next post, for playing YouTube videos up to 4K with this MPV.
ISP Camera with real-time h.264/1080p HW encoding: Using the Gstreamer Plugin. Check this wiki for instructions on how to use it. Most of it applies to Armbian, except for the selection of ov5647/imx219 camera, which must be done using DT overlays. OpenCL 1.2 support: It will be fully functional, no further action needed. You can download some tests and examples from this link. Kodi 18.9 Leia with full RKMPP+GBM acceleration, 4K-HDR capable: You can start it from LightDM menu as your user account: 


Alternatively, you can also run it as a system service with these command lines: sudo systemctl disable lightdm sudo systemctl enable kodi-gbm sudo reboot Full collection of Kodi binary add-ons: Includes retrogaming cores, media encoders and decoders, PVR, screensavers, vfs and audio visualizations. They are all installed with the package "kodi-addons-full", but are disabled by default. They need to be enabled individually within the Kodi GUI. OpenGL 2.1 support through the gl4es wrapper: It is installed with the package "gl4es", with no further action needed.  
III. Sources
This is the list of the sources used for the packages:
 
IV. FAQ
¿Why did you use Debian Buster as a base for this implementation?
It was the most appropriate for several reasons. Upstream Rockchip-Linux developers use Debian buster, so the software could be ported with less modifications than if we chose a different distro. Besides, it is a completely stable distro, unlike Bullseye, which is a moving target as of today. It also has Chromium as a package, unlike Focal that uses snap instead. For last, it has a good backports repo, with several libs that would otherwise need to be compiled and maintained if we chose, for example, Focal.
  ¿Why Legacy instead of Mainline?
This is an implementation based on the vendor's BSP kernel. It has been tested and is reliable, which many people will prefer rather than having a bleeding-edge, less stable implementation. In addition to that, Mainline upstream multimedia support is still a WIP, and lacks many features that are only present on Legacy kernels.
  ¿Will you add new features to this implementation?
No, this implementation will only receive bug fixes if necessary. From now on, all multimedia work will be focused on Mainline and recent distros (like Focal or Bullseye). All new features will go there.

IT'S FINALLY HERE...

THE OFFICIAL ROCKCHIP-LEGACY MULTIMEDIA INTEGRATION
 
After two years of using a separate script to enable the multimedia features in RK3399 Legacy Kernel, the whole framework has been incorporated to the official Armbian packaging system. The choice distro for this integration is Debian Buster (see FAQ at the end of this post about the reasons).
 
I. Installation
Download a Armbian Buster Legacy Desktop image for your board, and install it with the standard Armbian method. Install the complete multimedia solution with sudo apt update && sudo apt upgrade sudo apt install media-buster-legacy-rk3399 --install-recommends The switch "--install-recommends" will add the whole Kodi binary addons collection (retro-gaming cores, music visualizations, screensavers, additional media decoders/encoders, vfs, etc.), plus the GLES-to-OpenGL wrapper "gl4es".
 
II. Features
Accelerated GLES/EGL X desktop: No action needed. Accelerated Chromium, with WebGL and video display acceleration: No action needed Desktop video player capable of smooth 4K HEVC-HDR: Use the "Rockchip Gst Player" from the Multimedia menu, or choose it with right-click on the media file. Command-line 4K playing is also possible with "gst-play-1.0 --videosink=kmssink". RKMPP-accelerated MPV: Use normally for standard operation (windowed with mouse-operated GUI). For fullscreen, keyboard-operated mode, use the command line switch "--gpu-context=drm" (this will allow you to play smooth 4K).
        - See instructions below, in the next post, for playing YouTube videos up to 4K with this MPV.
ISP Camera with real-time h.264/1080p HW encoding: Using the Gstreamer Plugin. Check this wiki for instructions on how to use it. Most of it applies to Armbian, except for the selection of ov5647/imx219 camera, which must be done using DT overlays. OpenCL 1.2 support: It will be fully functional, no further action needed. You can download some tests and examples from this link. Kodi 18.9 Leia with full RKMPP+GBM acceleration, 4K-HDR capable: You can start it from LightDM menu as your user account: 


Alternatively, you can also run it as a system service with these command lines: sudo systemctl disable lightdm sudo systemctl enable kodi-gbm sudo reboot Full collection of Kodi binary add-ons: Includes retrogaming cores, media encoders and decoders, PVR, screensavers, vfs and audio visualizations. They are all installed with the package "kodi-addons-full", but are disabled by default. They need to be enabled individually within the Kodi GUI. OpenGL 2.1 support through the gl4es wrapper: It is installed with the package "gl4es", with no further action needed.  
III. Sources
This is the list of the sources used for the packages:
 
IV. FAQ
¿Why did you use Debian Buster as a base for this implementation?
It was the most appropriate for several reasons. Upstream Rockchip-Linux developers use Debian buster, so the software could be ported with less modifications than if we chose a different distro. Besides, it is a completely stable distro, unlike Bullseye, which is a moving target as of today. It also has Chromium as a package, unlike Focal that uses snap instead. For last, it has a good backports repo, with several libs that would otherwise need to be compiled and maintained if we chose, for example, Focal.
  ¿Why Legacy instead of Mainline?
This is an implementation based on the vendor's BSP kernel. It has been tested and is reliable, which many people will prefer rather than having a bleeding-edge, less stable implementation. In addition to that, Mainline upstream multimedia support is still a WIP, and lacks many features that are only present on Legacy kernels.
  ¿Will you add new features to this implementation?
No, this implementation will only receive bug fixes if necessary. From now on, all multimedia work will be focused on Mainline and recent distros (like Focal or Bullseye). All new features will go there.

As I said, there is one kernel config per board family, regardless of which packages are installed on userspace the kernel remains the same.  May people will want to download or build a console-only image and then install desktop on it (I do it quite often), so it makes sense to keep it this way.
 
Also, even people running headless may want to use the OpenCL features offered by panfrost, which is an additional reason for keeping it enabled.
 
Besides, having the graphics driver enabled in the kernel should not cause any kind of problem when you are not using the module (that is, no gpu accelerated apps running).  Mali drivers have always been enabled on legacy kernels, without being used in most cases, and it has never been an issue. If some problem ever arose from panfrost on servers, then it would be time to think about the best solution for it. But, as of today, it is not a problem at all, unless the contrary is proven.

I have tested Focal Xfce desktop on a Rockpi-4b, with Firefox, glmark2, video playing, etc., for over half an hour, and didn't have any problem. I have not been able to reproduce the bug.
 
If someone can give me clear steps to reproduce it, I will try to look into it. Otherwise, I consider it solved.

Armbian 20.11.3 bugfix release is out! Detailed report - what has been fixed and what's new:
 
https://www.armbian.com/newsflash/armbian-20-11-3-bugfix-update/

All images for a certain board share the same kernel.  After all, a desktop image is just a server image in which you install Xfce and the rest of the desktop apps.
 
However, panfrost should not give any trouble if you are not using any graphical application. But if you want to disable it anyway, just add a line like this:
blacklist panfrost to a newly created file
/etc/modprobe.d/blacklist-panfrost.conf  

Forums, apt and downloads will be off-line for approximately 30 minutes for system maintenance.   Thanks your understanding.

I have plans to incorporate the media packages compilation into the build script. Let's see if I get the chance to do it

It depends on which level we are talking. I assume AWS Graviton servers have a big team of paid staff to take care of both the hardware and the software, for example.
 
Now, if we are talking about $40 ARM SBC's, I think "hobbyists" and people in "playground mode" is a good way to describe the main public of those devices. If we also add "students", I think we have a complete description of the kind of use you can reasonably expect for that kind of boards, which the manufacturers make them for.  And, particularly, we describe the kind of people who willingly contribute to a project aimed to make an OS for these boards.
 
On the other hand, I consider absolutely unrealistic to expect the same level of support for such a project as you expect for one that is backed by a big company with a big staff. As unrealistic as expecting a group of volunteers, who spend their free time on the project out of good will and because they like it, to focus on a reduced number of boards they are not interested in, and only for the NAS use case, "just because I say so".
 
And it is not only unrealistic, but IMO also unnecessary. I find it hard to imagine a system administrator pulling an OPi Zero out of his pocket in front of the corporate board and saying "Hey, this is going to be our new support for the crucial data. Don't worry, it is going to run Armbian out of a Sandisk Extreme Pro, which has been proven to be the most reliable SD card in many forum posts".
 
----------
 
Now, focusing on our topic, I tried btrfs a couple years ago, attracted mainly because of the snapshots feature. But when I was trying to compile some software I needed, and discovered it was not even mature enough to allow creation of swapfiles on it, I just decided to go back to good ol' ext4. I haven't tried again since, maybe I should 

I see your point. You are used to deal with some profile of TV-box user, with high expectations and little technical knowledge. I personally would not call "dangerous" the standard approach of erasing eMMC in order to replace it for Armbian, it is what we do in many other boards. I have personally done it, the method is documented in official Khadas documentation, as well as the method for flashing the original Android again. But, again, I see your point, that it can be somehow "dangerous" for someone who has no clue of what he is doing.
 
So I think a sane approach is to keep the kvim2.csc the same way as we have been doing all along with kvim1.csc, which has not produced many complaints so far. The option in the build script is there, but we don't publish images among the supported boards, nor specify the method to install them. That way, only users with enough knowledge to use the build script will have those images. At least, for the time being, this may change in the future of course.
 
Besides that, I have developed a new function for the bash script, that grabs the meson-gxm boot blobs from the amlogic-boot-fip repo, as well as some patch to fix CPU scheduling in AML S912. These things can be useful if/when we start to support the Tartiflette.
I'm making a PR with all these changes.

Release info:
https://www.armbian.com/newsflash/armbian-20-11-tamandua/
 
Downloads:
https://www.armbian.com/download/
 

Hi @JMCC, I happened upon this thread as I was experimenting with HW encoding for one of my two HC1s, so I was very happy to read your posts and test out your custom ffmpeg build. I'm seeing a modestsubstantial speed boost (1.8x vs 0.9x) compared to the Armbian build.
 
My encode params are `-vcodec h264_v4l2m2m -num_capture_buffers 32  -pix_fmt nv21`. Any additional suggestions? Thanks
 

Okay, another use case. This one will bring some surprises.
 
Let us imagine we want to compile natively armhf/arm64 binaries. Like, for example, making the new Armbian multimedia packages that we will announce very soon
 
In this case, the Threadripper will be in clear disadvantage, since it needs to virtualize the ARM CPU through Qemu. But, will it be able to make up with core count and sheer processing power? Here are the numbers. We will compare the Threadripper with the Ampere ARM server, and with my highly optimized Odroid XU4 (good cooling and slight overclock).
 
First, a single thread 7-zip bench (Decompressing MIPS, higher is better):
$ 7z b -mmt1 Threadripper (native amd64): 4793 Threadripper (emulating armhf): 1529 Ampere ARM server (native armhf): 2889 Odroid XU4 (native armhf): 2160 As you can see, the single-core performance of the Threadripper is reduced to 1/3 of its natiive performance when emulating through Qemu, leaving it well below the Odroid XU4 and the Ampere.
 
Now, a real-world use case: let us compile our customized version of Kodi for armhf (compilation time, lower is better):
$ time cmake --build . -- -j$(nproc --all) Threadripper (emulating armhf): 18m9.696s Ampere (native armhf): 5m50.033s Odroid XU4 (native armhf): 45m50.711s The 32-core ARM server beats here the 64C/128T AMD server for more than three times shorter compile time. And Odroid XU4 gets just slightly above double the compile time of the AMD. If we factor in power consumption, it becomes very clear that compiling in an emulated environment is very suboptimal.
 
Now, we must remember that for building Armbian images we don't emulate, but instead cross-compile. In that case, the AMD is working natively, and that is another story. In that case, the AMD has absolutely no match with the ARM server, or anything else I ever tested. We will probably post numbers about this in some other opportunity.

Okay, another use case. This one will bring some surprises.
 
Let us imagine we want to compile natively armhf/arm64 binaries. Like, for example, making the new Armbian multimedia packages that we will announce very soon
 
In this case, the Threadripper will be in clear disadvantage, since it needs to virtualize the ARM CPU through Qemu. But, will it be able to make up with core count and sheer processing power? Here are the numbers. We will compare the Threadripper with the Ampere ARM server, and with my highly optimized Odroid XU4 (good cooling and slight overclock).
 
First, a single thread 7-zip bench (Decompressing MIPS, higher is better):
$ 7z b -mmt1 Threadripper (native amd64): 4793 Threadripper (emulating armhf): 1529 Ampere ARM server (native armhf): 2889 Odroid XU4 (native armhf): 2160 As you can see, the single-core performance of the Threadripper is reduced to 1/3 of its natiive performance when emulating through Qemu, leaving it well below the Odroid XU4 and the Ampere.
 
Now, a real-world use case: let us compile our customized version of Kodi for armhf (compilation time, lower is better):
$ time cmake --build . -- -j$(nproc --all) Threadripper (emulating armhf): 18m9.696s Ampere (native armhf): 5m50.033s Odroid XU4 (native armhf): 45m50.711s The 32-core ARM server beats here the 64C/128T AMD server for more than three times shorter compile time. And Odroid XU4 gets just slightly above double the compile time of the AMD. If we factor in power consumption, it becomes very clear that compiling in an emulated environment is very suboptimal.
 
Now, we must remember that for building Armbian images we don't emulate, but instead cross-compile. In that case, the AMD is working natively, and that is another story. In that case, the AMD has absolutely no match with the ARM server, or anything else I ever tested. We will probably post numbers about this in some other opportunity.

Okay, another use case. This one will bring some surprises.
 
Let us imagine we want to compile natively armhf/arm64 binaries. Like, for example, making the new Armbian multimedia packages that we will announce very soon
 
In this case, the Threadripper will be in clear disadvantage, since it needs to virtualize the ARM CPU through Qemu. But, will it be able to make up with core count and sheer processing power? Here are the numbers. We will compare the Threadripper with the Ampere ARM server, and with my highly optimized Odroid XU4 (good cooling and slight overclock).
 
First, a single thread 7-zip bench (Decompressing MIPS, higher is better):
$ 7z b -mmt1 Threadripper (native amd64): 4793 Threadripper (emulating armhf): 1529 Ampere ARM server (native armhf): 2889 Odroid XU4 (native armhf): 2160 As you can see, the single-core performance of the Threadripper is reduced to 1/3 of its natiive performance when emulating through Qemu, leaving it well below the Odroid XU4 and the Ampere.
 
Now, a real-world use case: let us compile our customized version of Kodi for armhf (compilation time, lower is better):
$ time cmake --build . -- -j$(nproc --all) Threadripper (emulating armhf): 18m9.696s Ampere (native armhf): 5m50.033s Odroid XU4 (native armhf): 45m50.711s The 32-core ARM server beats here the 64C/128T AMD server for more than three times shorter compile time. And Odroid XU4 gets just slightly above double the compile time of the AMD. If we factor in power consumption, it becomes very clear that compiling in an emulated environment is very suboptimal.
 
Now, we must remember that for building Armbian images we don't emulate, but instead cross-compile. In that case, the AMD is working natively, and that is another story. In that case, the AMD has absolutely no match with the ARM server, or anything else I ever tested. We will probably post numbers about this in some other opportunity.

The new version of ffmpeg, compiled for xu4 with HW acceleration, will come soon (hopefully) to the Armbian repos. In the meantime, you can download it from this link. It is completely static, so you can install it on any distro. After that, just install Jellyfin and enter in the "FFmpeg path" field "/opt/ffmpeg-xu4/bin/ffmeg" (or also the symlink, "/usr/local/bin/ffmpeg-xu4")

The new version of ffmpeg, compiled for xu4 with HW acceleration, will come soon (hopefully) to the Armbian repos. In the meantime, you can download it from this link. It is completely static, so you can install it on any distro. After that, just install Jellyfin and enter in the "FFmpeg path" field "/opt/ffmpeg-xu4/bin/ffmeg" (or also the symlink, "/usr/local/bin/ffmpeg-xu4")

As a result of all the work that Armbian developers put into the upgrade to kernel 4.14 for the XU4 board family, now we can enjoy many new features. One of them is the access to the SoC video encoding capabilities.
 
Emby Media Server can take advantage of the Exynos 5422 MFC video engine for transcoding. That means lower CPU usage, lower temperatures, and the possibility of encoding in real time higher resolutions or more simultaneous streams. In my tests, I've been able to transcode one HEVC 1080p and one 480p at the same time, or five 480p (though it will depend on the bitrate of the source material).
 
However, the ffmpeg version shipped with official Emby is quite unstable when using this feature. For that reason, I compiled a better and more stable version from @memeka's repo. I've been using it for over a month without a single crash.
 
So this is a step-by step guide on how to make everything work:
 
0. [PREREQUISITE]: You must be running an Armbian Strech XU4 "Next" image, like the one you can download here.
 
>> DOWNLOAD the emby and ffmpeg packages from this link << Install them (Note: this will install Emby Server version 3.5.3, which is the last at the writing of this tutorial. It has been tested to work with this version, and may or may not work with any other): $ tar xvf emby-server-stretch-xu4_1.0.tar.xz $ sudo dpkg -i ffmpeg/*.deb $ sudo dpkg -i emby-server/*.deb $ sudo apt -f install  
Hold the ffmpeg packages, so they don't get upgraded:  
$ sudo apt-mark hold ffmpeg-doc ffmpeg libavcodec-dev libavcodec-extra libavdevice-dev libavfilter-dev libavfilter-extra libavformat-dev libavresample-dev libavutil-dev libmysofa-dev libmysofa-utils libmysofa0 libpostproc-dev libswresample-dev libswscale-dev  
Add the user "emby" to the video group, so it can have access to the transcoding engine: $ sudo usermod -aG video emby  
Modify the emby executable, to use our custom ffmpeg (Note: you will need to repeat this step every time you update the emby deb package): $ sudo nano /opt/emby-server/bin/emby-server # Change the following line: ffmpeg $APP_DIR/bin/ffmpeg \ # to: ffmpeg /usr/bin/ffmpeg \  
Restart the service:
$ sudo service emby-server restart  
Now, you can open the web browser, point to your Emby server (e.g. http://odroidxu4.local:8096), and configure it as described in the official tutorial (https://github.com/MediaBrowser/Wiki/wiki/Installation).
For last, you need to enable Hardware video transcoding in the web interface. The option is under the "Transcoding" submenu. Don't forget to click on "Save" when you are done:
 
 

 
And that's it!
 
As an additional tip, I recommend disabling UPnP in Emby, because it causes the program to crash frequently when enabled (this is just a general recommendation, it has nothing to do with hardware encoding).
 
Enjoy! And please, share your experiences and comments here.