How to port ARM Mali-G610 graphic hardware support to Emby in Docker?

[chj915 10]

I have Emby Premiere purchased and I installed Emby server on my Windows 11 machine for hosting my own media library. I do rely on the graphic card H.264 hardware decoding a lot. On windows machine it is using Intel Graphic card so there is no issue. Recently, I have bought a Single Board Computer - Khadas Edge 2. It is a fast board and has factory shipped with Android, Ubuntu Desktop, and Ubuntu Server as OS options.

I am interested in getting my Emby server application ported over to this board and run as a docker container in Ubuntu OS.

The setup is easy but only thing that I cannot figure out: the graphic card hardware decoding support.

According to the product specifications, it has ARM Mali-G610 which is claimed to have H.265 encoding and decoding.

 

 

As of now, my Emby server runs via Docker container on this Single Board Computer, but there is no option to have the hardware decoding for H.265.

I know my question here is very specific to a graphic card device from ARM based Single Board Computer, it might not have lots of users out there. I just want to see if Emby community would have any answers.

 

Thanks

 

 

[Luke 42077]

Hi, can you please attach the emby server and hardware detection log files?

How to Report a Problem

Thanks !

[chj915 10]

hardware_detection-63819013492.txthardware_detection-63819013401.txtembyserver-63819013486.txtembyserver.txt

above are all the txt files under programdata\logs\ folder.

I started the emby docker container from scratch, so the log files are just for fresh new emby environment.

 

[Luke 42077]

OK, for comparison purposes, are you able to try our native Ubuntu package?

[chj915 10]

I have downloaded the ARM 64 version Emby package for linux and installed it.

It has the same result: no preferred hardware decoder option.

[Luke 42077]

Hmm ok. Can you try the 4.8 beta package?

[chj915 10]

tried the 4.8 beta native deb installation, it gives me the same result.

see logs in attachment.

emby_logs.zip

[chj915 10]

Just to give an update: I have tried Jellyfin (docker), the hardware decoding is supported smoothly.

In Emby, there is no option under the Preferred Hardware Decoder support for the Mali G610, thus the CPU usage was always at 90%.

In Jellyfin (docker), the hardware decoder option items are all provided. Not sure if the Jellyfin has detected any hardware available or it just lists out everything it supports. Anyway, when playing H.265 video with trans-coding, my Khadas Edge 2 (Rockchip 3588S) CPU usage is down to 20~30%.

 

[Luke 42077]

Hi, yes this is something we can look at. Thanks.

[softworkz 5066]

On 5/13/2023 at 10:38 PM, chj915 said:

Just to give an update: I have tried Jellyfin (docker), the hardware decoding is supported smoothly.

What makes you think though?

Can you provide an ffmpeg log from them, to see whether that's true?

 

On 5/13/2023 at 10:38 PM, chj915 said:

In Emby, there is no option under the Preferred Hardware Decoder support

In Jellyfin (docker), the hardware decoder option items are all provided. Not sure if the Jellyfin has detected any hardware available or it just lists out everything it supports.

JF is based on old Emby code - which was always showing all possible hw accels. 

Emby performs detailed detection, not only about available acceleration methods, it precisely detects decoders, encoders, with detail capabilities and available filtering operations. JF cannot do that, it shows you everything (I mean, you obviously don't have Nvidia or Apple hardware in that device...)

On 5/13/2023 at 10:38 PM, chj915 said:

Anyway, when playing H.265 video with trans-coding, my Khadas Edge 2 (Rockchip 3588S) CPU usage is down to 20~30%.

The reason for this could also be that they have some kind of throttling on by default, which you need to activate manually in case of Emby (iirc).

 

The general prerequisite for us to provide hw acceleration is that ffmpeg supports it. If you can find an ffmpeg version which supports your device, your OS and your GPU and you are able to get this working on your device - then we might be able to integrate that in Emby.

[beesyrup 10]

I'm very interested in this. I have a SOC with a Mali 450 that I'd like to use for my Emby server

[softworkz 5066]

13 hours ago, beesyrup said:

I'm very interested in this. I have a SOC with a Mali 450 that I'd like to use for my Emby server

Exact same answer like above:

On 6/2/2023 at 6:22 AM, softworkz said:

The general prerequisite for us to provide hw acceleration is that ffmpeg supports it. If you can find an ffmpeg version which supports your device, your OS and your GPU and you are able to get this working on your device - then we might be able to integrate that in Emby.

[beesyrup 10]

Roger that. I'll be on the hunt

[Luke 42077]

On 7/25/2023 at 8:36 AM, beesyrup said:

Roger that. I'll be on the hunt

Did you find anything?

[beesyrup 10]

Hey @Luke,

Apologies for the necro. I've been pretty busy for the past year and a half. I'm about to move onto a MFF Dell that supports Intel's QuickSync and allow me to use VAAPI out of the box, but I'm still trying to squeeze as much life I can out of my ODroid N2.

I've been following some developments from https://github.com/nyanmisaka/ffmpeg-rockchip where they've introduced hw acceleration for rkmpp. This is the biggest lead I've seen so far. I'm currently reviewing nyanmisaka's documentation on their wiki. I'll probably also be consulting the forum post (radxa) where they announced the release of this on their repo.

I'm no expert at this I'll need to set some time this weekend to try my hand at compiling this version of ffmpeg. These are my system specs reported via inxi -Fxxxrza:

# inxi -Fxxxrza
System:
  Kernel: 6.6.65-current-meson64 arch: aarch64 bits: 64 compiler: N/A
    parameters: root=<hidden> rootfstype=ext4 rootwait
    console=tty1 consoleblank=0 coherent_pool=2M usb-storage.quirks= net.ifnames=0
  Console: pty pts/1 Distro: Debian GNU/Linux 12 (bookworm)
Machine:
  Type: ARM System: Hardkernel ODROID-N2 details: N/A
CPU:
  Info: model: ARMv8 v8l variant-1: cortex-a53 variant-2: cortex-a73 bits: 64 type: MST AMCP
    arch: v8l family: 8 model-id: 0 stepping: 4
  Topology: cpus: 1x cores: 4 mt: 2 tpc: 2 st: 2 threads: 6 smt: <unsupported> cache: N/A
  Speed (MHz): avg: 1605 high: 1908 min/max: 1000/1992:1908 scaling: driver: cpufreq-dt
    governor: ondemand cores: 1: 1000 2: 1000 3: 1908 4: 1908 5: 1908 6: 1908 bogomips: N/A

...

Graphics:
  Device-1: meson-g12a-vpu driver: meson_drm v: N/A bus-ID: N/A chip-ID: amlogic:ff900000
    class-ID: vpu
  Device-2: meson-g12a-mali driver: panfrost v: kernel bus-ID: N/A chip-ID: amlogic:ffe40000
    class-ID: gpu
  Device-3: meson-g12a-dw-hdmi driver: meson_dw_hdmi v: N/A bus-ID: N/A
    chip-ID: amlogic:ff600000 class-ID: hdmi-tx
  Display: server: No display server data found. Headless machine? tty: 203x30
  Monitor-1: Unknown-1 size-res: N/A in console modes: 720x576
  API: N/A Message: No display API data available in console. Headless machine?

The output indicates the onboard GPU as being a meson-g12a-mali. According to Odroid's Specsheet on the Odroid N2 SBC, this is a Mali G52 MP6. I've been looking for a specsheet for this GPU, and it hasn't been easy to locate what its capabilities are, but I found on the Wikipedia entry for the Mali GPU indicates that the Mali G52 MP6 is capable of the decoding and encoding for the following:

- H.264 8-bit
- H.264 10-bit
- VP8
- HEVC Main
- HEVC Main 10
- VP9 8-bit
- VP9 10-bit

Since the server is headless, I don't have it plugged into anything but my drives, network, but I'll connect my TV up to it and see if I can test encoding/decoding (playback) of HEVC files. If you guys have any suggestion, I am happy to test it out on my side.

[beesyrup 10]

I was proceeding with the ffmpeg-rockchip build, and unfortunately it's out of the scope of my current abilities. I will need to reevaluate and see how I can proceed.

[beesyrup 10]

So there's some drama over LGPL license violations that occurred over the course of last year with rockchip blatantly copying ffmpeg code. Looks like Rockchip's devs are working on resolving it, and if it gets resolved, perhaps one day we'll hopefully see rockchip support in ffmpeg upstream down in the future.

Ref: https://github.com/rockchip-linux/mpp/issues/530