Adaptive bitrate livestreams

[lastcanal]

Hello! This PR includes all of #113 and adds adaptive bit-rate transcoding to the live streaming pipeline. The wonderful team over at Membrane have merged the changes I needed to the RTMP plugin and made this PR possible. Although not everything in this PR has been tested, anything un-tested is only available behind a feature flag. I have added issue #115 to track these features as they are tested.

3 transcoding backends are available: Software (ffmpeg), Nvidia, and Xilinx. I have only tested the Software backend. Transcoding in the pipeline can be configured with the TRANSCODING environment variable. The format is <height>p<framerate>@<bitrate> separated by a pipe |. For example: 1440p30@4000000|720p30@2000000.

To avoid overloading the application servers I have setup the pipelines to run inside FLAME, which will in theory use Fly to boot a new server and start the pipeline there. I have only tested the local backend.

H265 video is supported, but unfortunately Vidstack offers both h264 and h265 tracks to the viewer if h265 tracks are supported by their browser. H265 can be disabled with SUPPORTS_H265=false.

The following new environment variables have been added:

RESUME_RTMP=true
RESUME_RTMP_ON_UNPUBLUSH=false
RESUME_RTMP_TIMEOUT=3600
SUPPORTS_H265=false
TRANSCODE=4320p60@32000000|2160p60@16000000|1440p60@8000000|1440p30@4000000|720p30@2000000|360p30@1000000|180p30@500000
FLAME_BACKEND=local
FLAME_MAX=1
FLAME_MAX_CONCURRENCY=10
FLAME_IDLE_SHUTDOWN_AFTER=30
#FLAME_MIX_TARGET=nvidia

The following configuration should allow the pipeline to operate how it does today, except with re-connectable RTMP:

RESUME_RTMP=true
RESUME_RTMP_ON_UNPUBLUSH=true
RESUME_RTMP_TIMEOUT=3600
SUPPORTS_H265=false
FLAME_BACKEND=local

[zcesur]

Amazing!

Love to see you used FLAME for this. With :syn the pipelines can resume from another FLAME runner/node right?

Can we keep the source rendition in the manifest as well?

[lastcanal]

Yes, the pipeline should resume even under FLAME. The RTMP stream connects to an already running application server which will then launch the Pipeline on a FLAME node and forward audio and video messages via RPC. This means that the RTMP stream will be connected to a public-facing application server while the pipeline and transcoding will happen on a non-public-facing FLAME server (with the fly backend). If the streamer reconnects to another application server then syn will find the FLAME node running their pipeline and the stream of RPC messages starts again. I still haven't actually tried this with FLAME's Fly backend, only with multiple nodes running locally; I am going to try to get it running on Fly this week, I also want to try out the hardware transcoding.

As for including the source in the manifest, absolutely! I will add an extra configuration option to allow the un-trans-coded source version to be included in the manifest. It is currently only included if you disable all transcoding by unsetting the TRANSCODE environment variable.

My mornings are much more open this week (I'm UTC-5), I will set up a meeting and can walk you through everything.