Create HLS receiver appliance

[slifty]

We need to ingest HLS content in a way that doesn't lose any referenced captions. The most clean way to accomplish this would be if we could have ffmpeg mux the HLS playlist into an mpegts stream that includes subtitles, but that doesn't appear to be currently supported.

Given that, I think we would want to create an hls-receiver appliance which emits video payloads as well as a new vtt payload type. (The vtt would be full VTT files as extracted from the HLS playlist).

This will be our first appliance that generates two fundamentally different types of payload, which means taking a moment to think about naming convention, but I think the video prefix is appropriate and the fact that there is a VTT is more of an implementation byproduct / reflection of the fact that we can't mux subtitles in an HLS context.

Appliance design notes

We may decide that it's more appropriate for the HLS receiver to emit not vtt payloads but rather something more generic like "resourceURL" payloads and then create a middleware appliance that consumes "resource urls", figures out their format, and emits the appropriate payload type (in this case vtt, srt, or other caption format depending on the resource used by a given HLS playlist). This approach would limit the scope of the HLS appliance to simply parsing HLS caption playlist and forwarding the resources along (plus the whole "have ffmpeg mux the video itself" thing)

Related Issues

• Issue Ingesting m3u8s #148

[slifty]

Note: I toyed briefly with the idea of this being two different appliances; one for video and one for the captions.

That's still possible, but in thinking through it I'm leaning to just the one (as reflected in the issue description)

[slifty]

This may be a very handy resource for the implementation (and might avoid the need for any kind of VTT processing)

https://www.npmjs.com/package/hls.js

Not clear if it's going to be possible / easy to use that without a client side. Here's hoping.