On Mon, Jan 27, 2025 at 10:09:30AM +0100, Ingo Oppermann wrote:
> This fixes the criterion when to split the segments based on the
> elapsed time for the current segment instead of using the theoretical
> elapsed time since start based on hls_time and the number of written
> segments.
> 
> hls_time is used to define the minimum length of a segment, however
> this is not respected in all cases when a stream has variable GOP
> sizes.
> 
> Imagine a stream starts with a key frame every 10 seconds for
> e.g. 30 seconds. After that, key frames will come every second. This
> will result in segments that are first 10 seconds (as expected), then
> 1 second for some time (not as expected) and later 2 seconds (as
> expected).
> 
> How to reproduce:
> ffmpeg -t 30 -f lavfi -i testsrc2 -codec:v libx264 -g 250 part1.mp4
> ffmpeg -t 30 -f lavfi -i testsrc2 -codec:v libx264 -g 25 part2.mp4
> echo "file part1.mp4\nfile part2.mp4" > list.txt
> ffmpeg -f concat -i list.txt -codec copy \
>     -f hls -hls_time 2 -hls_list_size 0 parts.m3u8
> cat parts.m3u8
> 
> Signed-off-by: Ingo Oppermann <ingo@datarhei.com>
> ---
>  libavformat/hlsenc.c | 12 +++---------
>  1 file changed, 3 insertions(+), 9 deletions(-)

this breaks / needs to update
fate-hls-init-time

--- ./tests/ref/fate/hls-init-time	2025-01-28 13:58:16.733614814 +0100
+++ tests/data/fate/hls-init-time	2025-01-28 15:09:03.869138579 +0100
@@ -3,310 +3,308 @@
 #codec_id 0: pcm_s16le
 #sample_rate 0: 44100
 #channel_layout_name 0: mono
-0,          0,          0,     1152,     2304, 0x28123557
-0,       1152,       1152,     1152,     2304, 0x838c7e81
-0,       2304,       2304,     1152,     2304, 0x4fb8704c
-0,       3456,       3456,     1152,     2304, 0x5f787f9e
...

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus