One binary between your upload and an HLS playlist.
Api-pr probes what you give it, builds an adaptive HLS ladder with ffmpeg and serves the segments straight off local disk. No broker, no bucket, no control plane. It runs on the same box that serves the playback.
Resumable multipart uploads and pull-from-URL. Probes the source, rejects what it cannot decode, keeps the original untouched.
ffmpeg under the hood, ladder defined per profile. Hardware encode used when the host exposes it, software otherwise.
HLS with byte-range segments, cache headers tuned for a plain reverse proxy or a CDN in front.
Quick start
curl -sSL https://api-pr.barmalei.com/get | sh
api-pr init --data /var/lib/api-pr
api-pr serve --listen 127.0.0.1:8080
Put your own TLS terminator in front. Api-pr deliberately does not speak TLS.
Push one file through it
# create an asset
curl -X POST https://api-pr.barmalei.com/v1/assets \
-H 'Authorization: Bearer $TOKEN' \
-d '{"profile":"web-1080p","title":"clip.mp4"}'
# upload the source
curl -X PUT https://api-pr.barmalei.com/v1/assets/as_497af92b/source \
-H 'Authorization: Bearer $TOKEN' \
--data-binary @clip.mp4
# poll until ready, then play
curl https://api-pr.barmalei.com/v1/assets/as_497af92b
# -> {"state":"ready","playback":"/p/as_497af92b/master.m3u8"}
Why it exists
Every hosted transcoder I tried billed per minute of output and wanted my media in their bucket. For a personal archive of a few hundred hours that is absurd.
It is not a CDN, not a DRM stack and not a media asset manager. If you need signed multi-region playback with per-viewer entitlements, this is the wrong tool. If you need to turn a directory of camera files into something a browser can play, it does that and stops there.
Status
Used in production for exactly one thing: the archive this domain was set up for. The API is stable within a minor version; the on-disk layout is not yet. Read the API reference before wiring anything permanent to it, and the changelog before upgrading.