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
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-receiverappliance which emits video payloads as well as a newvttpayload type. (Thevttwould 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
vttpayloads 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