[RockChip] Asus Tinker Board

[UltimateCoder 0]

Hey guys,

 

yesterday I managed to setup emby server at version 3.2.60.0 on my Asus Tinker Board.

 

I have to say ... this is a pretty dope software actually. This in mind, I tested some things, and it really worked well.

 

 

The part I am a little bit upset about, is that although the tinker board has a gigabit NIC, and therefore should easy be able to handle traffic, there is a problem with transcoding. I tested my setup with serval devices. Some of them do not needed any transcoding at all, some needed it though. 

 

The problem now is, that the Tinker Board actually can perform better than it acutually does now. I have some pretty hard stuttering on some devices that need transcoding. The CPU usage goes up to pretty much 100%. I am a professional software developer myself, and would love to help you guys out, to tweak the shit out of this single board computer, since it is a cheap alternative for acting as a media server.

 

Could you point me to some settings, that I could try first, to make transcoding more effective on the Tinker Board? Maybe I just have the wrong settings in place.

 

If changing settings wont help, we maybe can discuss how to archive better performance out of these small boards. I mean since they also have hw acceleration, there might be some percent to gain with some tweaks.

[Luke 37219]

Hi, thanks for the feedback !

 

I guess the only setting i can think of changing would be hardware acceleration under the Transcoding menu, that is if any hardware acceleration is supported. Thanks.

[dcrdev 251]

There's a va-api driver and library availible for rockchip, but it's not bundled with emby.

 

You could build those from source and have a stab at building ffmpeg against that.

[Waldonnis 148]

Poking through the ffmpeg sources a tad, it looks like some RockChip MPP support was added to ffmpeg at some point.  I don't know how inclusive it is or what it requires dependency-wise, though.  Decoding via rkmpp is listed as supported on the hwaccel documentation page, but not rkmpp encoding acceleration (only rkmppdec.c is present in libavcodec, so that seems accurate).  You'd need to build ffmpeg with --enable-rkmpp to try that out, but without encoding support, any performance gains will be limited.  From what I can tell, there was some discussion about it a few months back on one of the ffmpeg lists as well as some Kodi-related talk that indicated that the hardware implementation and API were a bit strange, but I have no idea what resulted from that (worth searching for, imo, just to have some context).

 

I agree with dcrdev and think trying the vaapi driver may be the best place to start since Emby already knows about vaapi...and you probably won't have to recompile a custom ffmpeg, which is a time sink no matter what platform you're on.

[UltimateCoder 0]

I found that thread with the discussion about adding support for RockChip too. The problem is, as you already said, no encoding support.

 

I even found something about vaapi (http://rockchip.wikidot.com/rockchip-va-driver). I don't know if this is something I can use since it is declared as deprecated and has been replaced by MPP (Don't find that post any more). Maybe you can have a look at it @@Waldonnis ?

 

It seems that there is a dude that actively develops the RockChip implementation still (https://github.com/LongChair/FFmpeg/tree/rockchip). I could not find an implementation for an encoder. So even for @@dcrdev s method not a good idea :/

 

You guys have any other options to make it less painless to use a Tinker Board ?

Edited January 5, 2018 by UltimateCoder

[dcrdev 251]

The va-api implementation did infact have limited encoding extensions, which is why I mentioned it. However I wasn't  testifying to it's usability as I have never tried it.

 

I would say your options are as follows, if hardware acceleration isn't an option:

• Encode your media into a format that doesn't need transcoding in the first place.
• Implement a bit rate limit on transcoding.
• Try throttling the ffmpeg process by writing a nice wrapper around ffmpeg in shell script.
• Try a more lightweight distro / try disabling any unwanted services that consume resources.

I know your probably going to disagree with me, but I'd argue it's not really a great platform to act as a transcoding server in the first place.

[Waldonnis 148]

The va-api implementation did infact have limited encoding extensions, which is why I mentioned it. However I wasn't  testifying to it's usability as I have never tried it.

 

I would say your options are as follows, if hardware acceleration isn't an option:

• Encode your media into a format that doesn't need transcoding in the first place.
• Implement a bit rate limit on transcoding.
• Try throttling the ffmpeg process by writing a nice wrapper around ffmpeg in shell script.
• Try a more lightweight distro / try disabling any unwanted services that consume resources.

I know your probably going to disagree with me, but I'd argue it's not really a great platform to act as a transcoding server in the first place.

 

Pretty much this. I agree that a low-power solution like this isn't really a great platform if frequent transcoding is required.  From a file service angle, it should work rather nicely, though, so if you can eliminate transcoding as a requirement, you'd have a capable little server.  Most ARM SOCs like this are marketed to partners more for decoding/playback than encoding, so their implementations/API/docs can be wonky/lacking, and encoding is treated as an afterthought even though the SOCs technically support it.

 

I'd give the vaapi driver a shot, even if it's deprecated.  If it works decently, it would at least buy you some time to see what happens on the ffmpeg/MPP side.

[UltimateCoder 0]

Okay. Currently I haven't had the time to try out anything fancy. I currently just installed a RPI with LibreElec to play stuff directly from my NAS.

 

I hope in the next week's I have some time to try out the vaapi driver.

 

Thank you all for your ideas and your help.