My use case is essentially DIY internet radio. I've abstracted the real-world constraints into a toy problem for simplicity, but these constraints are real for me.
I'm shipping a 24/7 live HLS stream with only MP3 files. In a perfect world, the catch is that to support high fault tolerance, and these MP3 files are all individually generated from the source WAV files.
I've gotten a test version working with ffmpeg running inside of another process that feeds PCM data to its stdin:
ffmpeg \ -v info \ -i pipe:0 \ -f hls \ -ac 2 \ -c:a mp3 \ -b:a 128k \ -initial_offset 12345 \ -maxrate 128k \ -minrate 128k \ -start_number 12345 \ -hls_flags delete_segments \ -hls_list_size 20 \ -hls_playlist_type event \ -hls_segment_filename /tmp/radio-%d.mp3 \ -hls_time 10
Ideally, I can consume that stream using
ffplay without errors.
However, when I perfectly replicate the output of that
ffmpeg -f hls process above using manual ffmpeg runs, we hear audio discontinuities, tiny pieces of silent mortar between the bricks of audio. The reason for this is known. See this answer to this question on video StackExchange: Audio discontinuities when generating HLS segments in different processes:
ffmpeg I've got so far encoding from WAV files that we write to a temp folder on disk in advance of this step:
ffmpeg \ -i pathToWAV \ -id3v2_version 0 \ -ac 2 \ -c:a mp3 \ -b:a 128k \ -minrate 128k \ -maxrate 128k \ /tmp/radio-12345.wav
Is there some way to tell ffmpeg to use the last 1024 frames from the previously-encoded MP3 (e.g. radio-12344.mp3) in the transform overlapping the first 1024 frames of the next MP3 media segment in the HLS? Or maybe to do a second pass on each file using a muxer where I lop off those priming samples?