[FFmpeg-user] On the recovery behavior of HLS muxer when slaved to tee'd fifo muxers in ffmpeg.

[Dennis Mungai]

On Wed, 25 Mar 2020 at 08:27, Dennis Mungai <dmngaie at gmail.com> wrote:

> Four months ago, I posted a ticket on trac, #8387, see
> https://trac.ffmpeg.org/ticket/8387
>
> Which described an anomaly with the recovery behavior of the underlying
> HLS muxers called up via the tee's fifo slaves. More details in the ticket.
>
> What I've discovered by extensively studying this behavior is that when
> dealing with fragmented mp4, the HLS muxer (as configured above) will
> definitely fail to re-create the init.mp4 file should the target path (on a
> local or remote filesystem) go missing.
>
> This is still present with ffmpeg git head, compiled a few hours ago.
>
> Case in point: Simulating failures with unstable NFS mounts, using the
> same recovery options for fifo work flawlessly for DASH where the init
> segments per variant are successfully re-created but the same doesn't carry
> over for HLS.
>
> What gives?
>
> Are there specific tee and fifo muxer settings I can try out to resolve
> this?
>
> Thanks,
>
> Dennis.
>

Update: A bit too soon, perhaps I should also update the subject.
DASH demonstrates something similar:
In effect, the muxer tries to re-create the init segment(s) for each
variant stream(s), but fails with the ominous message:

"Application provided invalid, non monotonically increasing dts to muxer in
stream 0"