HW acceleration (decode + encode) with RK3568?

[softworkz 5283]

I'm afraid to say that, but this is farther away than the impression that has been created.

Once we have a new ffmpeg version, this will not immediately include RK hwa support. Initially, we will need to test and stabilize all regular functionality with the new ffmpeg. This takes time. And when we integrate the RK hw features in a new and specific ffmpeg build for those devices, this still doesn't mean that it's working automatically. There is development in Emby Server required, so that it will make use of those hwa capabilities. So it's really not something that is like just-around-the-corner.

Even though this is not the kind of message you were all hoping and waiting for - I think it's not only fair but also a matter of respect towards users, not to let them get trapped in a long loop of hope and disappointment. It's definitely on the agenda, but not possible to get done by a finger-snip.

Thanks

[Dans34 0]

Got a CM3588 myself , following with interest 

[Liam2000 4]

@softworkzis there a roadmap at all? I'm having to use both Jellyfin and emby at the moment but would love to just migrate to just Emby.

[danergo 43]

Hi Folks! How is the status with this currently? I came across with this problem again, and it would be extremely useful if I can use rk's hw acceleration with emby.

[Luke 42722]

On 3/7/2026 at 12:04 PM, danergo said:

Hi Folks! How is the status with this currently? I came across with this problem again, and it would be extremely useful if I can use rk's hw acceleration with emby.

Hi, we are working on an updated ffmpeg that should be in the server beta channel in the near future. Thanks.

[zyrorl 4]

@Lukeany status on when it'll be available in Beta, this has been waiting for quite a long time!!!

[niksol 0]

On 4/13/2026 at 10:44 AM, zyrorl said:

@Lukeany status on when it'll be available in Beta, this has been waiting for quite a long time!!!

+1... 

[softworkz 5283]

Just to let you guys know - this is not on the never-gonna-happen list.

We're working towards it, and progress is made...

[niksol 0]

5 minutes ago, softworkz said:

Just to let you guys know - this is not on the never-gonna-happen list.

We're working towards it, and progress is made...

Wow, this is awesome! Can we somehow understand the status of progress? Is there much more work left to be done?

[softworkz 5283]

I got few minutes, so let me explain our - let's say - "limited excitement" for RockChip devices.

Few years ago, users convinced us to look into those types of devices (earlier gen of course) for transcoding and it looked very promising  - at least on paper - so we bought a Pine64 with an RK3399 and looked into it. Step-by-step it became clear that the specs were blatant lies and none of the promises kept true, like ffmpeg support, which had been mentioned and confirmed at various places, and then it turned out that there had been an earlier attempt, abandoned 1.5 years ago, completely unusable, requiring some kernel of firmware that wasn't even available - a total failure.

Playback at FullHD - stuttering like crazy - far away from all the specs they published - and it was clear that this device will never be able to transcode anything (when it cannot even de-code, how should it at the same time? 

Several OS images were provided and the only question was: which bug will the next one have what the others don't have?

OS had to be copied on an eMMC card - ancient technology, super-slow, took endlessly long and the result worked only in one of 3 cases - at best.
The device became super-hot, even for little effort, cooling was insufficient, and it became even slower when hot and it was hot most of the time.
Also, it was hardly possible to keep it closed. Each time I reassembled, it took only minutes until another reason came up for disassembling again, yet it needed its case for cooling, so it was an endless chain of open close open close open close - you couldn't put it into a corner and be good.
It might be a nice gadget for doing simple things, but the way how it was advertised - by RockChip, not by Pine - is not acceptable, just a collection of lies.

It's been an incredible waste of time, disappointing all along the line with a manufacturer who is lying about capabilities - from this background it should be understandable that since then, our excitement for anything about RockChip has been - as said - rather limited.

The conclusion was that we won't do any pioneering work and won't make any move in this area until there's proven evidence that this can work in a reasonable way and other will have done the required work on ffmpeg integration and suitable OS images, drivers and convincing device models are available.

The condition of the last sentence seems to be fulfilled, that why we're going for another attempt, but not as a top priority.

Edited 11 minutes ago by softworkz

[softworkz 5283]

51 minutes ago, niksol said:

Wow, this is awesome! Can we somehow understand the status of progress? Is there much more work left to be done?

Well, on the FFmpeg side, everything is prepared, but not at the side of Emby Server. 

We do not even have a device other than the underperforming hand-warmer (which I won't ever touch again  ).

[niksol 0]

2 minutes ago, softworkz said:

Well, on the FFmpeg side, everything is prepared, but not at the side of Emby Server. 

We do not even have a device other than the underperforming hand-warmer (which I won't ever touch again  ).

Okay, I understand. Thanks for your work and attempts!

Maybe we can help you to test raw software in beta test? For example I have Orange Pi 5+ with RK3588S, it can transcode any format with ffmpeg included in Jellyfin without any bugs and much heating/cpu load. So I think it won't be difficult to test and feedback for such users as me.

[softworkz 5283]

Thanks for the offer, through, the FFmpeg command building we do is pretty complex and working on this requires probably more iterations than we will have beta versions over the next few years...

Acquisition of a device not a problem in itself, it's rather about which one.  The requirements are:

1. The device must use: RK3588 or RK3588S
2. The device must have an internal M.2 M-key NVMe slot.
3. Multi-Boot
   The device must be able to
   • either boot multiple OS installations from NVMe  (probably doesn't work)
   • or boot with a boot loader  with a menu  on regular/flash storage while the core OS is installed on NVMe 
   • or boot from a non-fixed drive while the core OS is installed on NVMe and switch OS by changing the drive's medium
     In this case, the "drive'" must be externally accessible without opening the case
4. The device must be useable in all possible ways without needing to disassemble and re-assemble it more than once - ever

More generally: Everything that requires more time than it should/could, is a showstopper