rffmpeg-worker's Introduction

rffmpeg-worker for jellyfin-rffmpeg

This container can be used for both dedicated boxes (or with rffmpeg-autoscaler) and Kubernetes!

Setup

The workers only need access to the following directories:
- /config/cache (by default it's /cache unless you're using my Jellyfin image)
- /config/transcodes
- /config/data/subtitles

Kubernetes

On Kubernetes you can use OpenEBS to create RWX from RWO volume or Longhorn RWX volumes (NFSv4) and mount said paths to Jellyfin host and workers (must be exactly the same mount points!).

Here's a Helm chart repo with instuctions

Contributions

This project wouldn't be possible without panubo!

rffmpeg-worker's People

Contributors

Stargazers

Watchers

rffmpeg-worker's Issues

Helm chart instead of example manifests

Hello!
It would be veeery nice to have helm chart for this instead of plain manifests so things could be configurable without modifying it by hand!

Can only connect once

This is my docker config

When first start my jellyfin docker can connect to the worker docker, and trancscode is correct
When my jellyfin docker restart it can not connect, i have to restart my jellyfin docker and the worker docker

Add option to add ssh user to render group

Currently the SSH_USERS env var allows a pair of uid and gid, which in one of the common setups with Jellyfin and the whole *arr stack, would mean a Jelyfin uid, and a common gid shared among these media server applications. But doing so would mean that the jellyfin user within this Docker container can't access /dev/dri/render*.

One work around is to specify the render group's gid as the gid in SSH_USERS, but that feels dirty since render is a system group, and could potentially screw up permissions when it writes. It'll be great if the user can specify a gid for the render group when running this container instead, and the entrepoint.sh would have one groupadd line to add that in-container user to that gid.

Recommend Projects