> This change has caused regressions for many users and consumers. See: - https://www.reddit.com/r/mpv/comments/181yu2z/problem_streaming_radio/ - https://github.com/mpv-player/mpv/issues/13428
In my case: Restreaming HLS to HLS. The source provides segments of 15s length, while output is 3/6s segments. This causes segments in the output playlist to be added "in waves", i.e. 5 segments are added (roughly) at the same time after which no more segments are added for the next 15s. As the HLS demuxer reloads the playlist in intervals of the segment length, it can easily happen that will reload the playlist more than 3 times until a new segment appears in the playlist. Other example: Since the HLS demuxer uses the duration of the last segment instead of the target duration for the reload interval, it can also happen that one segment is comparably short (which is perfectly valid) which can cause the 3 reloads to be done even before a regular segment duration has passed. Example cases for why 1000 is a reasonable default: When receiving (e.g. for recording) from an HLS service which looses its upstream connection for whatever reason (network outage, DDOS, etc.) it might recover after some time, delivering all segments since the start of the situation. A TV receiver streams via HLS and reception gets interrupted due to weather conditions. The missed content is lost, but the HLS playlist can indicate a discontinuity and resume serving segments. sw _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
