Radxa Orion O6

[theCl0ink]

Hi,

would anyone have an opinion how the Radxa Orion o6 would fare as a Jellyfin Server and if it's worth buying?
What kind of problems i might have with it e.g. with transcoding.

Thank you.

[gnattu]

You won't get any hardware acceleration support right now. I'm aware of this board but I don't think the software support will become useable in the near future.

[theCl0ink]

Thought that might be the case. Would it be wiser to get e.g. Radxa rock 5 or would you have some better recommendations?

[TheDreadPirate]

The RK3588 in the Rock 5 is supported by jellyfin.

https://jellyfin.org/docs/general/admini.../rockchip/

[gnattu]

Rock5 has its own limitation that its hardware decoder does not parse dovi rpu which breaks dolby vision tone mapping. (Its GPU is too slow for 4K HDR tone mapping anyway). If most of your library is in SDR it could be a good choice if you know how to set that up.

[nyanmisaka]

Hi,

would anyone have an opinion how the Radxa Orion o6 would fare as a Jellyfin Server and if it's worth buying?
What kind of problems i might have with it e.g. with transcoding.

Thank you.

The Radxa Orion O6 is not shipping yet, so it's too early to talk about the user experience. I might be able to get my hands on one soon.

According to information from Radxa employees, the CIX CD8180 SoC used in the Orion O6 uses a VPU IP from ARM, and they use the V4L2 stateful API, which is already supported in FFmpeg.

But there is currently no info about whether this VPU has fixed-function hardware to handle VideoPostProcessing (VPP). Anyway, the SoC already has an Arm Immortalis-G720 MC10 GPU that can provide support for the same.

[nyanmisaka]

Rock5 has its own limitation that its hardware decoder does not parse dovi rpu which breaks dolby vision tone mapping. (Its GPU is too slow for 4K HDR tone mapping anyway). If most of your library is in SDR it could be a good choice if you know how to set that up.

Last time I checked it could do 2160p@55fps with HDR10 tone-mapping enabled. So the RK3588 should be able to handle two 4k@24fps HDR->SDR transcodes.

Regarding DOVI, actually RKMPP parses out the metadata for each frame, but it does not meet the expectations of the DOVI helpers in FFmpeg. It may be related to different data structures or bitstream parsers built into MPP runtime.

[gnattu]

> Last time I checked it could do 2160p@55fps with HDR10 tone-mapping enabled.

This varies a lot depending on the input and in reality it barely does one 4k30 for most of the time (two will stall the stream from time to time). I might test some lite implementation that trade off flexibility for such slow GPUs to have more useable tone mapping performance.

---

> But there is currently no info about whether this VPU has fixed-function hardware to handle VideoPostProcessing (VPP). Anyway, the SoC already has an Arm Immortalis-G720 MC10 GPU that can provide support for the same.

I don't think we really need VPP hardware for this SoC as its GPU looks fast enough for most of the processing tasks to me, at least they are fast enough on paper.

[nyanmisaka]

> This varies a lot depending on the input and in reality it barely does one 4k30 for most of the time (two will stall the stream from time to time). I might test some lite implementation that trade off flexibility for such slow GPUs to have more useable tone mapping performance.

Probably because my test stream does not contain DOVI P8 metadata, reshape kernel is expensive on this ~0.5 TFLOPS GPU.

---

> I don't think we really need VPP hardware for this SoC as its GPU looks fast enough for most of the processing tasks to me, at least they are fast enough on paper.

Let's wait and see. This new GPU should be 3 or 4 times faster than the previous GPU used on the RK3588.

[nyanmisaka]

> Probably because my test stream does not contain DOVI P8 metadata, reshape kernel is expensive on this ~0.5 TFLOPS GPU.

Strange, the decoder does not output DOVI metadata, and the reshape kernel should not be used. Is your board overheating?