Jump to content

SBC with proper software support for hardware video transcoding


Werner

Recommended Posts

At the moment I run a local Jellyfin server on an older amd64 system which @NicoD would call a giant space heater :lol:

Anyway it would be nice if a proper SBC could replace this thing, last but not least to save a decent amount of space :P

 

The question is which board is capable and has the proper software support? Anyone here does have experience with video acceleration on SBCs using media servers like plex, emby, jellyfin or whatever they all may called and if so which board, which kernel and how well do things work?

 

Since the data backend is network storage the board does not need either lots of USB3 connectors (one decent is enough for caching) nor other fance stuff like PCIe or SATA.

 

Lots of SoCs are advertised to support lots of en- an decoding but in reality not often proper software support is there...

 

Link to comment
Share on other sites

Looking at the documentation of jellyfin, only the rpi3 or 4 seems to be the supported boards based on an arm architecture.

Other than that, I think that JMCC have a script to install such stuff on most rk boards based on 4.4 kernel if I remember well, but I'm not sure transcoding is working: 

Myy is also working on porting vpu rk lib to mainline for rk3399;

I'm not up to date about cedrus features for transcoding concerning Allwinner socs. I'm quite sure that my previous server sbc based on H3 was able to transcode using plex several years ago.

My current server is based on an amlogic soc and I didn't investigate the vpu for now. A few years ago plex didn't see any transcoding engine.

Link to comment
Share on other sites

15 minutes ago, Werner said:

@NicoD would call a giant space heater

Winter is coming, got my old spaceheaters running too :) Old pc's are only to be used for fun, not for productivity.
afbeelding.png.50add228e909e22a8a80a4ab079eda3d.png

I would think the RockPiX should be able to do that since it's x86. AtomicPi is even cheaper. But not from EU.
I've never used anything like that.
I use plain Armbian Bionic legacy on rk3399 to watch all media, and my OPi+ fileserver also Bionic desktop with all my back-up/network storage.

Maybe I should look into plex and see what the fuss is all about. :)

Link to comment
Share on other sites

On 11/1/2020 at 8:01 PM, jeanrhum said:

Looking at the documentation of jellyfin, only the rpi3 or 4 seems to be the supported boards based on an arm architecture.

 

The  transcoding is handled by the jellyfin-ffmpeg package, which is basically a fork of ffmpeg. You can specify your own path to ffmpeg binary in settings, as the supplied binary is linked with raspberry libs (which is the only rpi specific code of jellyfin).

Raspberry pi is ok for VPU.

 

@Wernertry jellyfin on your NEO3 and compile ffmpeg with --enable-version3 --enable-rkmpp --enable-drm

 

Personally I don't use transcoding but leave it all to the RPI3 (LibreElec) which happily plays all formats from SMB except for 10bit x265.

Link to comment
Share on other sites

At the moment I run a local Jellyfin server on an older amd64 system which [mention=8801]NicoD[/mention] would call a giant space heater
Anyway it would be nice if a proper SBC could replace this thing, last but not least to save a decent amount of space
 
The question is which board is capable and has the proper software support? Anyone here does have experience with video acceleration on SBCs using media servers like plex, emby, jellyfin or whatever they all may called and if so which board, which kernel and how well do things work?
 
Since the data backend is network storage the board does not need either lots of USB3 connectors (one decent is enough for caching) nor other fance stuff like PCIe or SATA.
 
Lots of SoCs are advertised to support lots of en- an decoding but in reality not often proper software support is there...
 
TL;DR: Odroid XU4/HC1/MC1

Sorry, I didn't see this post before. I have a jellyfin server on a Odroid HC1, working like a charm since long ago. HW transcoding can do 1080p with no problem. I have special ffmpeg packages for Armbian buster, in case you want them.



Enviado desde mi moto g(6) plus mediante Tapatalk

Link to comment
Share on other sites

On 11/4/2020 at 9:55 PM, JMCC said:

TL;DR: Odroid XU4/HC1/MC1

Sorry, I didn't see this post before. I have a jellyfin server on a Odroid HC1, working like a charm since long ago. HW transcoding can do 1080p with no problem. I have special ffmpeg packages for Armbian buster, in case you want them.
 

Did you try to do multiple transcodings in parallel?

Link to comment
Share on other sites

2 hours ago, Werner said:

Did you try to do multiple transcodings in parallel?

Yep. In my tests, I've been able to transcode one HEVC 1080p and one 480p at the same time, or five simultaneous 480p (though it will depend on the bitrate of the source material). It may have trouble if you feed some HEVC 4k  material to it, particularly if it is 10-bit or high bitrate.

Link to comment
Share on other sites

The only Armbian-supported VPUs that can handle that are Rockchips. But there is no FFmpeg support for encoding, only Gstreamer. So no Jellyfin either.

You can try SW transcoding in a Odroid N2+, and see if it can cope with it. Otherwise, you must go for some Intel SBC, or probably RPi4.

Enviado desde mi moto g(6) plus mediante Tapatalk



Link to comment
Share on other sites

50 minutes ago, gounthar said:

Isn't there a port of ffmpeg that permits hardware encoding for RK3399? I think I saw it there.

I think you refer to JMCC work, but it only works with kernel 4.4 if I'm right. The problem is to be able to compile rkmpp with mainline and then ffmeg or gstreamer.

Link to comment
Share on other sites

@jeanrhum AFAIK, there is only decoding support for Rockchip's mpp in FFmpeg. There is active development for Rockchip VPU in mainline, not using mpp but instead the standard v4l2-m2m API. However, again they are focusing only on decoding, so far.

 

@gounthar Are you sure you saw some FFmpeg fork with rkmpp encoding? That would be great, but I never heard about it.

Link to comment
Share on other sites

something that could handle two 1080p h264 or HEVC in parallel
Wait, you mentioned h264. You are aware that h264 normally doesn't need transcoding, right? The server just feeds the stream to the client, so the limit is set by your network connection and/or your storage device. You can stream many h264 streams of any resolution at once, even 4k.
 
Transcoding is only needed when the file is in a format that the client cannot handle natively. So, for example, if you are using Chrome browser as client, it cannot handle HEVC, and therefore it needs transcoding. But, if your client is Kodi with Jellyfin plugin, then you won't need transcode either for HEVC, since Kodi can handle it.
 
Since almost all clients support h264, it will normally not be transcoded. And, if you want, you can convert all your videos to h264, and then you can use any SBC as server, even with a weak CPU.

Link to comment
Share on other sites

11 minutes ago, JMCC said:

ranscoding is only needed when the file is in a format that the client cannot handle natively.

Now I understand. I never knew what it was used for. I also stream from my OPi+ NAS on M4V2. Never needed transcoding.
And don't watch TV/Netflix. Is it for that too? Capturing it and sending it in a readable format like h264?

Link to comment
Share on other sites



TV/Netflix. Is it for that too? Capturing it and sending it in a readable format like h264?


Yes, I use tvheadend with Jellyfin. So when I am watching a SD channel, which uses MPEG2-ts, it does transcoding.

Enviado desde mi moto g(6) plus mediante Tapatalk

Link to comment
Share on other sites

1 hour ago, Werner said:

Did a few tests with the Neo3 and the 1+. Could not make use of va on either one of them. Guess I have to wait until I have access to an rk3399 board and try 4.4 rk kernel on.

The only HW acceleration that is going to work among Armbian-supported boards is XU4. Besides that, it's Intel or RPi. Or, of course, SW transcoding.

Link to comment
Share on other sites

Good news! I got to compile a highly optimized ffmpeg binary from a current git, with XU4 tweaks, that is able to encode two simultaneous 1080p@25, as long as the source bitrate is not excessive.

 

You can download and give it a try from here. It is completely static, so you can install it on any distro. It will install the binary in "/opt/ffmpeg-xu4/bin/ffmpeg", and a symlink "/usr/local/bin/ffmpeg-xu4". Therefore, it can be installed along the system ffmpeg without conflicts.

Link to comment
Share on other sites

3 hours ago, Werner said:

I probably try something else

Excellent! Good luck with it.

 

However, I want to make some clarifications for people following the thread. As I said above, when I talk about transcoding, I am always thinking about HEVC sources, since h.264 sources don't need transcoding. XU4, therefore, will use SW to decode the HEVC, and HW to encode into h.264. That is how acceleration works.

 

As a matter of fact, if you force ffmpeg in command line to do both HW decoding and encoding (e.g., from h.264 to h.264 in XU4), it will have a negative impact on performance, versus using SW decoding and HW encoding. Again, we are always talking about the XU4 v4l2-m2m encoder, AFAIK the only ARM encoder currently supported by ffmpeg besides RPi.

Link to comment
Share on other sites

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 :)

 

Edited by edrex
accuracy
Link to comment
Share on other sites

7 hours ago, JMCC said:

Is there any particular reason why you are specifying the number of buffers? And also, are you specifying some bitrate?

Without it I get a deadlock at around 21s:

[h264_v4l2m2m @ 0x2be3250] All capture buffers returned to userspace. Increase num_capture_buffers to prevent device deadlock or dropped packets/frames.

and heuristically 32 seems to work. Curious that you haven't seen that. I'm on Armbian bullseye, so maybe it's something new in userland? same kernel I assume..

 

I left the default quality (`-cbf 12` like regular h.264 encoding?) for testing. I'm wanting to add configurable encoding to filestash's on-demand transcoding settings. Expecting a deep dive into ffmpeg lore to get all those stream-oriented settings working with hardware encoding :)

Link to comment
Share on other sites

5 minutes ago, edrex said:

I'm wanting to add configurable encoding to filestash's on-demand transcoding settings.

If you are interested, here are the sources for the package: https://github.com/teacupx/ffmpeg-xu4

The default number of capture buffers are set here: https://github.com/teacupx/ffmpeg-xu4/blob/53b4276b74b28cb195c0a040f1b1d2bf34da275c/patches/ffmpeg/0500-fix-num-buffers-for-exynos5422.patch#L9

 

These numbers were figured out by memeka, from the Odroid community, I'm not sure the procedure he followed. And I found them to be more stable than the default FFmpeg. If you find some better numbers, you can let me know after you test with different sources, either through this forum or a PR in github, and we can modify the patch.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines