HLS Writer Module

[kumaakh]

Is your feature request related to a problem? Please describe. HLS (HTTP Live streaming) from apple is a popular streaming protocol for delivering live media to apple (macos, ios, tvos) devices. Apra Pipes must support it so that we can avoid using 3rd party applications for this need.

Typical pipeline ingest from a live camera ->h264 encoding->HLSFilewriter HLS file writer chunks the incoming video frames into *.ts files and maintains a playlist file (playlist.m3u8)

Describe the solution you'd like

1. HLS File writer module should be able to write transport stream (*.ts) chunks into a directory and maintain a playlist.m3u8 file as per the apple specification
2. The module will only be responsible fo rmaintaining files, while an external HTTP server (e.g. apache or node.js) will be responsible for serving the files to players. the current implementation should not worry about the HTTP side for now
3. While HLS allows multiple video, audio, text, metadata channels to be embedded into a single HLS stream we will first focus on getting the video playable on apple devices. Caveat: annecdotally, we may have to embedded a "mute/silent" audio stream as part of the video stream but this should be vetted before implementing.
4. A requirement here is that the HLS stream produced by this module should be compatible with various streaming engines (wowza, evo, red5 etc.) and content distribution networks such as LimeLight, Akamai, wowza etc.

Describe alternatives you've considered use a 3rd party library such as FFMPEG or 3rd party software such as evo. but these approaches make the worklow long and clumsy

Additional context The above requirement should be considered in the context of a surviellance scenario where delivery live low latency video to apple devices is the key.

Proposed Module properties:

1. outputPath: The folder where all the .ts/.m3u8 files will be stored.
2. streamName (stream)
3. cleanupOutput (true/false): If true, all .ts and .m3u8 files in the output folder will be removed before we start writing
4. playlistType (appending/rolling) (appending playlist is typically used for Video On Demand applications e.g. for storing recording for future. while rolling is used for live streaming
5. playlistLength(10): for rolling playlist: the number of fragments before the server starts to overwrite the older chunks. for appending playList: ignored
6. playlistFileName (playlist.m3u8) : name of the playlist file. It is very rare that a different name is chosen
7. staleRetentionCount (default to playlistLength): The number of old files kept besides the ones listed in the current version of the playlist. Only applicable for rolling playlists
8. chunkLengthTarget (1.0s): The time durartion in seconds of each playlist chunk (*.ts file). e.g. 1.5 seconds. Note this just a target and does not have to be precise.
9. chunkOnIDR (true/false): We should always start a new chunk on seeing an IDR frame. previous chunk is closed on the last non-IDR frame and new chunk is written starting at the IDR frame. However if chunkOnIDR is false we close a chunk as soon as chunkLengthTarget is met and new chunks can start at nonIDR frame also.
10. resume(true/false): chunk writing would resume by appending to an existing playlist (e.g if we had a restart).
11. useSystemTime(true/false): by default we use universal (UTC) time in playlist, however if this flag is enabled we should use the system time.

--

[kumaakh]

Brainstorm

One implementation option is to reuse the MultimediaQueue Module and improve it such that it relases all frames of a ts chunk in a burst and then a filewriter improvement can write the .ts file. Anyhow we need to cache data to be able to write in a optimized fashion instead of writing one tiny p frame every now and then. We will need some module to be able to create the ts file from it's frame and other props.