Dear maintainer:

When I try to build this package on AWS machines of type m7a.medium,
which incidentally have a single CPU, test "seek-hls" always fails.

I have no idea why this happen, but it happens 100% of the time here,
and it's concerning, because it means the output of a given test does
not necessarily follow from its input. I would say that the test is
wrongly designed.

I'm including the relevant part below. The full build log is available
here:

https://people.debian.org/~sanvila/build-logs/202609/


If this happens because the encoder works differently depending on the
number of available threads, you probably can reproduce the build
failure by booting with GRUB_CMDLINE_LINUX="nr_cpus=1".

If this is not enough, I can offer a VM to reproduce, as always.

Thanks.
--------------------------------------------------------------------------------
[...]
/<<PKGBUILDDIR>>/debian/standard/ffmpeg -nostdin \
        -f lavfi -i "testsrc2=size=128x72:rate=10:d=6" \
        -f lavfi -i "aevalsrc=cos(2*PI*t)*sin(2*PI*(440+4*t)*t):d=6" \
        -map 0:v -map 1:a -c:v mpeg2video -bf 2 -g 15 -dct int -idct int -flags +bitexact -c:a mp2fixed \
        -f hls -hls_time 2 -hls_list_size 0 \
        -var_stream_map "v:0,agroup:a a:0,agroup:a,default:yes" -master_pl_name hls-seek.m3u8 \
        -hls_segment_filename /<<PKGBUILDDIR>>/debian/standard/tests/data/hls-seek-s%v-%d.ts \
        /<<PKGBUILDDIR>>/debian/standard/tests/data/hls-seek-v%v.m3u8 2>/dev/null
TEST    seek-hls
/<<PKGBUILDDIR>>/tests/fate-run.sh fate-seek-hls "" "" "/<<PKGBUILDDIR>>/debian/standard" 'run libavformat/tests/seek /<<PKGBUILDDIR>>/debian/standard/tests/data/hls-seek.m3u8 -duration 6' '' '/<<PKGBUILDDIR>>/tests/ref/seek/hls' '' '1' '' '' '' '' '' '' '' '' '' ''
 /<<PKGBUILDDIR>>/debian/standard/libavformat/tests/seek /<<PKGBUILDDIR>>/debian/standard/tests/data/hls-seek.m3u8 -duration 6
--- /<<PKGBUILDDIR>>/tests/ref/seek/hls	2026-08-03 22:14:48.000000000 +0000
+++ tests/data/fate/seek-hls	2026-09-19 22:29:54.772290931 +0000
@@ -6,7 +6,7 @@
 ret: 0         st: 0 flags:0  ts: 0.788333
 ret: 0         st: 1 flags:1 dts: 1.400000 pts: 1.500000 pos:    564 size:  3913
 ret: 0         st: 0 flags:1  ts: 1.682500
-ret: 0         st: 1 flags:0 dts: 1.600000 pts: 1.600000 pos:   8836 size:  2330
+ret: 0         st: 1 flags:0 dts: 1.600000 pts: 1.600000 pos:   8836 size:  2289
 ret: 0         st: 1 flags:0  ts: 2.576667
 ret: 0         st: 0 flags:1 dts: 2.586233 pts: 2.586233 pos:  55836 size:  1254
 ret: 0         st: 1 flags:1  ts: 3.470833
@@ -40,7 +40,7 @@
 ret: 0         st:-1 flags:1  ts: 3.989173
 ret: 0         st: 1 flags:1 dts: 1.400000 pts: 1.500000 pos:    564 size:  3913
 ret: 0         st: 0 flags:0  ts: 4.883344
-ret: 0         st: 1 flags:0 dts: 4.800000 pts: 5.100000 pos:  20492 size:  3860
+ret: 0         st: 1 flags:0 dts: 4.800000 pts: 5.100000 pos:  20492 size:  3904
 ret: 0         st: 0 flags:1  ts:-0.222489
 ret: 0         st: 1 flags:1 dts: 1.400000 pts: 1.500000 pos:    564 size:  3913
 ret: 0         st: 1 flags:0  ts: 0.671678
Test seek-hls failed. Look at tests/data/fate/seek-hls.err for details.
[hls @ 0x55be417c2fc0] Opening '/<<PKGBUILDDIR>>/debian/standard/tests/data/hls-seek-v1.m3u8' for reading
[hls @ 0x55be417c2fc0] Opening '/<<PKGBUILDDIR>>/debian/standard/tests/data/hls-seek-v0.m3u8' for reading
[...]
--------------------------------------------------------------------------------

I found this:

- The gen command in "tests/fate/seek.mak", lines 204 to 211,
does not pin the thread count (i.e. it does not have `-threads 1`).

- There are a lot of tests which use -threads 1 when encoding video, for
example, just do this from the top level directory:

rgrep '\-threads 1'

They do that presumably to make sure that the output is always the same.

So, it would seem that upstream actually intends for those tests to be
reproducible and independent of number of available threads in the
building machine, but forgot to do the same in the test which is
failing here.

So, my suggestion is to disable the test in the Debian package and
forward the bug upstream.

Thanks.