On Wed, 25 Mar 2020 at 08:27, Dennis Mungai <[email protected]> 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" _______________________________________________ ffmpeg-user mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
