reassign -1 ffmpeg thanks On Sun, Sep 20, 2026 at 07:56:10AM +0200, Sebastian Ramacher wrote: > Source: libmedia-convert-perl > Version: 1.5.2-1 > Severity: serious > X-Debbugs-Cc: [email protected] > > Dear maintainer, > > libmedia-convert-perl fails its autopkgtests with ffmpeg 9.0:
So, this happens only on armhf. The problem is this: > 549s progress: 84 > 549s progress: 85 > 549s progress: 87 > 549s progress: 89 > 549s progress: 91 > 549s progress: 93 > 549s progress: 95 > 549s progress: 96 > 549s progress: 97 > 549s progress: 99 > 549s progress: 92 > 549s progress: 93 > 549s progress: 94 > 549s progress: 100 > 549s not ok 6 - progress information is strictly incresing when doing > multipass As you can see, the progress information here jumps from 99 to 92%. This is as received from ffmpeg. I ran, on amdahl, in a sid armhf chroot, the following command: 'ffmpeg' '-progress' '/dev/stdout' '-loglevel' 'warning' '-y' '-i' 't/testvids/bbb.mp4' '-threads' '1' '-c:v' 'libvpx' '-speed' '4' '-pass' '2' '-passlogfile' 't/testvids/out.webm-multipass' '-c:a' 'libvorbis' '-t' '10' 't/testvids/out.webm' | grep -E '(out_time|progress)' (the command as shown in the log, with the "-progress" and grep bits added) And this resulted in output similar to the following: [...] out_time_us=8823583 out_time_ms=8823583 out_time=00:00:08.823583 progress=continue out_time_us=8826485 out_time_ms=8826485 out_time=00:00:08.826485 progress=continue out_time_us=9019501 out_time_ms=9019501 out_time=00:00:09.019501 progress=continue out_time_us=9357642 out_time_ms=9357642 out_time=00:00:09.357642 progress=continue out_time_us=8416667 out_time_ms=8416667 out_time=00:00:08.416667 progress=continue out_time_us=8625000 out_time_ms=8625000 out_time=00:00:08.625000 progress=continue out_time_us=N/A out_time_ms=N/A out_time=N/A progress=continue out_time_us=N/A out_time_ms=N/A out_time=N/A progress=continue out_time_us=N/A out_time_ms=N/A out_time=N/A progress=continue out_time_us=N/A out_time_ms=N/A out_time=N/A progress=continue out_time_us=10000000 out_time_ms=10000000 out_time=00:00:10.000000 progress=end As you can see, the time indexes here jump backwards at the 8.625 second mark. As I don't expect an encoder to jump backwards in time, and as I don't see the problem occurring anywhere except on armhf, I believe this to be a bug in ffmpeg. As such, I'm reassigning this to ffmpeg, with the understanding that I might be wrong :) (if ffmpeg does in fact document that time stamps in progress information may jump backwards, then obviously that would be a strong indication that I'm wrong -- I looked but didn't see any documentation hinting this) -- "I never had a C in history!" "Yeah, but there was so much less of it when you were my age!" -- Joe Brockmeier recounting a conversation with his father, cfgmgmtcamp 2026, Ghent
