Transcode Server v0.1.0-beta

VLC Transcode Server — v0.1.0-beta

A self-hosted companion for the VLC Tizen TV app. It runs on a small always-on
box (e.g. an AM6b+), reads your media from an SMB share, and transcodes
only what the TV can't decode — DTS / TrueHD audio, or an unsupported video
codec — into a TV-friendly HLS stream. Files the TV can already play are
remuxed untouched.

The TV keeps browsing the share exactly as before; the only thing that changes
is where the bytes come from when you press play — so DTS/TrueHD files finally
play with sound.

⚠️ Beta — not yet verified on real TV hardware. Builds, unit tests and the
full media plane are validated with stubbed ffmpeg, but AVPlay HLS playback on
an actual Samsung TV still needs a real-world test. Feedback welcome.

Run it (no clone, no build)

docker run -d --name vlc-transcode --restart unless-stopped \
  -p 8200:8200 -v "$PWD/vlc-data:/data" --device /dev/dri \
  ghcr.io/patrickst1991/vlc-transcode:0.1.0-beta

Then open http://<box-ip>:8200, enter your SMB share, and pair with the TV
(Settings → Transcode server → Pair). A multi-arch image (amd64 + arm64) is
published to GHCR by this release's CI. Bare Linux binaries are attached below
for non-Docker setups (ffmpeg must be installed separately).

How it decides

Source	Treatment
Video + audio both TV-friendly	Remux only (copy/copy, ~no CPU)
Only audio is DTS/TrueHD	Copy video, transcode audio → AC3 (5.1) / AAC (stereo)
Video codec unsupported	Hardware-transcode video → H.264, fix audio

The H.264 encoder is auto-detected at startup
(rkmpp → vaapi → nvenc → qsv → v4l2m2m → libx264), so the same image runs on
Rockchip, Intel/AMD, Nvidia, generic ARM, or a plain VM.

Known limitations

• Seeking works within the already-transcoded range; jumping far ahead waits
  for the encode to reach that point.
• Subtitles are not yet muxed into the HLS stream (the app handles subs
  separately).
• Rockchip rkmpp needs a custom ffmpeg build; stock falls back to V4L2/software.
• One active stream per file.