The DebConf video team streaming setup gives users access to HLS (HTTP Live Streaming) streams, that are very easy to wrap for web-based consumption. To push the streams to the backends, RTMP streams are used on the backend.
Our streaming infrastructure is split in two layers: streaming backends receive a H.264 encoded stream from each room via RTMP, and generate HLS (HTTP Live Streaming) streams on HTTPS. Streaming frontends are currently simple caching HTTPS reverse proxies, allowing load distribution and geographic redirections to reduce the latency downlading video segments for the clients.
All TLS certificates (for HTTPS) are handled using either Let’s Encrypt or by generating self-signed certificates. To accommodate geographic redirections or other DNS manipulations, when using Let’s Encrypt, all of the challenges are centralized on the streaming backend host, while all frontends redirect their requests there.
Streaming backends are nginx instances, using the nginx RTMP module to listen to RTMP feeds pushed by the rooms. For DebConf, only one backend is used.
The backend is configured as two RTMP applications (
show), as well as a HTTPS virtual host.
stream RTMP application¶
videoteam-stream script in each room pushes the feeds to the
RTMP application, at URL
application has two purposes:
- It dumps the incoming stream as a last ditch backup
- It runs ffmpeg to downscale the incoming stream to lower bandwidth variants.
This ffmpeg instance pushes its synchronized downscaled streams to the
showRTMP application at
rtmp://<backend>:1935/show/<room>_<quality>. The original stream is also pushed unchanged to
show RTMP application¶
show RTMP application generates the client-oriented adaptive bandwidth
HLS playlists , which are in the end served through its HTTPS virtual host.
- main adaptive HLS playlist, referencing all the following playlists, with the bandwidth settings from the configuration
- HLS playlist for the “source quality” stream
- HLS playlist for downscaled streams
The streaming backend HTTPS virtual host¶
The streaming backend virtual host mostly serves the live HLS data under the
/live/ directory. It also serves the centralized
used for the frontends to answer the Let’s Encrypt challenges.
Streaming frontends are nginx instances as well, with a single HTTPS virtual
host. As of now, these nginx instances only perform caching of the HLS playlists
and segments for use by clients, using the nginx proxy module for the
To improve latency of client connections to streams, our streaming frontends are geographically distributed.
Frontends are expected to have a virtual host that supports all possible domain names under the “live” subdomain, allowing on-the-fly DNS rearrangements:
- af (Africa)
- an (Antarctica)
- as (Asia)
- eu (Europe)
- na (North America)
- oc (Oceania)
- sa (South America)
- local (Clients local to the conference venue)
When using Let’s Encrypt to generate certificates, challenge data in the
.well-known directory is centralized on the backend host, and all frontends
redirect to it, so that they can generate certificates for all domains
indifferently of the current DNS configuration.
To help geographic-aware redirections of clients, all streaming frontends support two specific (sets of) HTTPS endpoints (URLs):
- This single endpoint returns a
text/plainresponse containing the GeoIP continent code, or
- Redirects clients (those are players, e.g. vlc) to
https://<code>.<live-domain>/<uri>, i.e. the proper geographic frontend detected for their IP address. For example,
https://local.live.debconf.org/redir/<room_name>.m3u8could redirect to
https://eu.live.debconf.org/live/<room_name>.m3u8. To bypass redirection, one can use the latter directly.
|||Adaptive bandwidth means, that depending on the detected user’s bandwidth and cpu capacity a different quality stream is served. HLS (http live streaming) means, that the stream is broken down to several chunks, that are downloadable via http/s.|