Control: reassign -1 libmedia-convert-perl 1.5.2-1 Hi Wouter
On 2026-10-04 17:39:28 +0200, Wouter Verhelst wrote: > 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. No, it doesn't. See for example here https://ci.debian.net/packages/libm/libmedia-convert-perl/testing/ppc64el/76474853/ > > 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 :) ffmpeg calculates the progress timestamp as the maximum DTS among unfinished output streams. When the stream providing that maximum finishes, it is excluded from the calculation, so the next reported timestamp can be lower. In the case of this test, there are two streams: the audio and the video stream. So one stream finishes early and then out_time goes backwards. I couldn't find any FFmpeg documentation. Therefore I don't think the test should require it to increase monotonically. A consumer needing monotonic progress will need to keep the maximum value seen so far. Reassining it back to libmedia-convert-perl. It is making assumptions on out_time that are not documented and not guaranteed. Cheers > > (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 > -- Sebastian Ramacher
