ffmpeg 7.0.1 and Windows 7

[autodidact]

Still I would like to know which kind of ffmpeg builds you will distribute in the future. Should I better archive the older builds which still work on my ancient computer, or do you intend to continue providing older libzimg builds in the future?

The git master builds will continue to include the older libzimg, if you don't mind using those.

[manolito]

Still I would like to know which kind of ffmpeg builds you will distribute in the future. Should I better archive the older builds which still work on my ancient computer, or do you intend to continue providing older libzimg builds in the future?

The git master builds will continue to include the older libzimg, if you don't mind using those.

Thank you...
That's fine with me as long as those git master builds are not too "experimental". So far this has not been an issue for me, so yes, please...


Thanks again,

Cheers
manolito

[manolito]

Small issue with ETA display in FFmpeg 8.x

Hi autodidact,

the FFmpeg authors rewrote the ETA (Estimated Time of Arrival) display in version 8. I use this frequently in dmMediaEncoder, and the "improved" algorithm annoys me quite a bit. Looks like the authors only tested the algo with very short source files. For a regular movie (1 hour or longer) this new algo is totally unaccurate. The counter starts at a much longer time than the actual movie length, then it counts downwards at a much faster interval than the actual time, so at the end of the clip it will reach zero. Any ETA value in the middle of the movie is completely useless.

In FFmpeg 7.x this ETA display works differently. The display starts at the real movie length, during the first few minutes the displayed value jumps around a little, but soon the displayed value stabilizes. IMO this method is way better than the new method.

Here's my questions:
1. Can anyone else confirm my findings? Or is my ancient Thinkpad T530 to blame?
2. Would it be hard to just exchange the current ETA routine in the FFmpeg 8.x git master version with the old routine in version 7.x ?


Cheers
manolito

[cholla]

Hi manolito,
I have older computers also circa 2007 & 2009.
They have Windows 7 32-bit.
I have both ffmpeg 7 & 8 versions.
I do not have dmMediaEncoder installed.

I would test to see what the versions look like on my computers with a video.
What ffmpeg code are you using when you check the ETA ?
An image of the ETA would also be helpful.

[cholla]

@ autodidact,
I thought I had kept a ffmpeg version of 7.
I must have deleted it after I installed version 8.
If you still have them would you post the last ffmpeg version 7 for Windows 7 32-bit.
I saw they were removed from post #33.

[autodidact]

@manolito,
Unless you can point me to the code changes that relate to that function there probably isn't anything I can do about it.

@cholla,
I removed the git master builds in post #33 as I was about to upload new builds but discovered a compatibility problem.
Those were not version 7 anymore though and I don't keep the old git master builds. The last version 7 release build is in post #17.

[cholla]

The last version 7 release build is in post #17.

I gave that one a try but it doesn't have the codec for aac_at.

The last version 7 release build in post #33 did.
I was just going to use the version 7 release build to test for manolito.
To see if I got similar results.

The version 8 release build is working fine for me.
But I have not been trying to use ETA.

@ autodidact,
Can you tell if this is a version 7: ffmpeg version N-121473-gdc39a576ad-WIN7 Copyright (c) 2000-2025 the FFmpeg developers
built with gcc 15.2.0 (Rev8, Built by MSYS2 project)

[autodidact]

Can you tell if this is a version 7: ffmpeg version N-121473-gdc39a576ad-WIN7 Copyright (c) 2000-2025 the FFmpeg developers
built with gcc 15.2.0 (Rev8, Built by MSYS2 project)

That revision is from October 19 so probably early in the 8.x development cycle. Something from August might be more likely.

[cholla]

Can you tell if this is a version 7: ffmpeg version N-121473-gdc39a576ad-WIN7 Copyright (c) 2000-2025 the FFmpeg developers
built with gcc 15.2.0 (Rev8, Built by MSYS2 project)

That revision is from October 19 so probably early in the 8.x development cycle. Something from August might be more likely.

I could not find a ffmpeg from August but I had a Windows 7 OS backup from May 2025.
It had this ffmpeg version:
ffmpeg version N-119739-gab37c7e49f-WIN7 Copyright (c) 2000-2025 the FFmpeg developers
built with gcc 15.1.0 (Rev5, Built by MSYS2 project)
ffmpeg.exe 5/29/2025

The March 30 post (#33) and revised May 29 with new builds from git master which is a development branch so is newer than 7.1.1 (pre 7.2)
and has allowed for the testing of customized features.

[manolito]

Back after a lot more testing, and thanks a lot to cholla and autodidact for the help...

First of all I believe that hunting for FFmpeg 7.1 versions by autodidact is a lost cause, but it is easy to find older versions by AnimMouse which are very similar to the autodidact versions. The link is here:
https://forum.videohelp.com/threads/414767-ffmpeg-7-0-1-and-Windows-7#post2771155

I tried the latest release version 8.0 , it was apparent that the changes to the ETA display format started with FFmpeg 8. The latest FFmpeg 7 builds still use the older ETA algo which displays correct results.

This borked ETA display will not affect FFmpeg console users, for GUI users I am not too familiar with GUIs other than dmMediaConverter. This GUI has an ETA display in the regular conversion screen which is quite accurate in FFmpeg 7.1, but totally off in FFmpeg 8. Looks like a real bug to me, but the devs probably do not care for GUI users.


Here is a typical conversion using FFmpeg 7.1 for reference and FFmpeg 8.0 to demonstrate the issue. These were the conversion details:

Source: Half HD MP4 of 50 Min length
Target params: SD size 704 x 396 at 30 FPS. Used ColorMatrix for HD to SD correction.

Results:

FFmpeg 7.1
Conversion time 15 Min, ETA slighty unstable for about 1 minute, but overall correct time was displayed.

FFmpeg 8.0 (identical settings)
Conversion time identical, but ETA reading started at 48 minutes, no correction whatsoever. The time display changed way faster than the actual time, so it reached a value of 0 at the end of the encode.


I am quite sure that this is a programming bug in FFmpeg 8. It does not affect too many users, but I still think that it is unnecessary and should be fixed...


Alright, this is what I have to say concerning this issue. No big deal, but unnecessary...

Cheers
manolito

[cholla]

@manolito,
It took me a while to figure out the ETA was in the dmMediaEncoder GUI.
I had never used the program.
Then after I DLed it it took me a while to figure out how to test with ffmpeg v 8 & 7.
Once I did these are the results:
7 does start at approximately the movie length. Then jumps a bit. Then gives an approximate time longer than the movie but fairly stable.
With an occasional jump to what seems to be the movie time less what it has encoded.
8 does sort of the same but jumps a lot more.
I'm encoding a movie now with 8 & I will see how close to accurate the ETA is for it.

I did a test with a full movie one with 7 & one with 8.
The ETA was close enough for me about 16 minutes to short on both.
The ETA was 2:22:00 The time to complete the encode was 2:38:00.

I tested AnimMouse ffmpeg latest version 7.
It would not convert the Audio for Apple aac_at.
The autodidact version 7 does.
I believe I have the latest version 7 posted by autodidact.

[manolito]

I believe I have the latest version 7 posted by autodidact

If you have the 64bit version, could you please provide a download link?

Cheers
manolito

[cholla]

@ manolito ,
I rarely do conversions on my laptop which has Windows 7 64-bit.
So I did not update to the latest Windows 7 ffmpeg that autodidact posted.
The 64-bit version 7 I have is dated 4/8/2025.
It is in my 64-bit Program Files not the Program Files(x86) folder.
So it should be a 64-bit version.
My 32-bit version 7 is dated 5/29/2025.

Read post #54 & others around it for more information on the Apple itune files.
There are later versions here but I have not tested them.
https://github.com/AnimMouse/QTFiles/releases
The FFMPEG 7 version I have already has one of the older versions added & they are working.
This 64-bit version will also convert to libfdk_aac as well as Apple aac_at.
You need to copy the FFMPEG folder to where you want to use it from.
It works as a portable.

[Vidd]

Links to older 7 versions, but not the git builds. Archive.org saved to old forum posts, but sadly did not save the attachments for the git builds.


ffmpeg-7.1-full-static-WIN7_64.7z
https://forum.videohelp.com/attachments/82653-1728028686/ffmpeg-7.1-full-static-WIN7_64.7z

ffmpeg-7.1-full-static-WIN7_32.7z
https://forum.videohelp.com/attachments/82655-1728028780/ffmpeg-7.1-full-static-WIN7_32.7z

ffmpeg-7.1-full-shared-WIN7_64.7z
https://forum.videohelp.com/attachments/82654-1728028686/ffmpeg-7.1-full-shared-WIN7_64.7z

ffmpeg-7.1-full-shared-WIN7_32.7z
https://forum.videohelp.com/attachments/82656-1728028780/ffmpeg-7.1-full-shared-WIN7_32.7z



ffmpeg-7.1.1-full-static-WIN7_64.7z
https://forum.videohelp.com/attachments/85910-1741062463/ffmpeg-7.1.1-full-static-WIN7_64.7z

ffmpeg-7.1.1-full-static-WIN7_32.7z
https://forum.videohelp.com/attachments/85913-1741062536/ffmpeg-7.1.1-full-shared-WIN7_32.7z

ffmpeg-7.1.1-full-shared-WIN7_64.7z
https://forum.videohelp.com/attachments/85911-1741062463/ffmpeg-7.1.1-full-shared-WIN7_64.7z

ffmpeg-7.1.1-full-shared-WIN7_32.7z
https://forum.videohelp.com/attachments/85913-1741062536/ffmpeg-7.1.1-full-shared-WIN7_32.7z

[oniiz86]

@manolito
I did update zimg in the 8.1 release builds so that accounts for the slower performance on your machine.
Here is a build for you to test that has the more compatible libzimg.

Still I would like to know which kind of ffmpeg builds you will distribute in the future. Should I better archive the older builds which still work on my ancient computer, or do you intend to continue providing older libzimg builds in the future?

The git master builds will continue to include the older libzimg, if you don't mind using those.

@autodidact I was just curious as to why you felt it was necessary to make the change form libzimg to zimg if the older libzimg was fine and it will ensure greater compatibility performance-wise for your Windows 7 builds as @manolito had discovered? Is there any chance you could continue to use libzimg for your static & shared builds going forward as it had been prior to the 8.1 release builds?

[autodidact]

I was just curious as to why you felt it was necessary to make the change form libzimg to zimg if the older libzimg was fine and it will ensure greater compatibility performance-wise for your Windows 7 builds as @manolito had discovered? Is there any chance you could continue to use libzimg for your static & shared builds going forward as it had been prior to the 8.1 release builds?

I backport fixes and sometimes miss something. I wanted the release builds to have the latest code.
If that is not a concern I will include the older libzimg in all builds.

[autodidact]

Updated FFmpeg in post #33.

[manolito]

originally posted by autodidact

If that is not a concern I will include the older libzimg in all builds

This is very good news for me...

Thanks very much
manolito

[oniiz86]

@autodidact Thanks so very much for that, your work is so greatly appreciated along with your MKVToolNix builds, it's great to hear that libzimg will still be utilised for all builds going forward, I see that you updated FFmpeg but not the latest 8.1.1 release builds, only git master builds, what are the differences in this case?

[autodidact]

FFmpeg release version updated to 8.1.1 in post #89.

[autodidact]

@oniiz86
FFmpeg development is continuous so the git master builds have all the latest features and potential bugs.
The release versions are cut from master at a certain feature/api level and updates to that release are only bug fixes.
You will notice that the libav versions of the git master builds are higher.

[manolito]

I´m the party pooper (again)...

I feel bad, but I have to report that both current FFmpeg builds (git master and release version) do not like my old Thinkpad running Win 7 64. This is a Deja Vue, the same thing has happened before, please have a look at post #101 in this thread.

Any chance that this will be fixed, or is Win7 compatibility no longer an issue?


Whatever, thanks very much for keeping this project alive

Cheers
manolito

[autodidact]

@manolito
Are you seeing this in both 32-bit and 64-bit builds and is the error the same as in post #101?
I'll need the exact error to track down the source.

[manolito]

@autodidact

Thanks for your quick reply...

I only tested the 64-bit version because I do not use the 32-bit version. I will test the 32-bit version asap and report back.

The error message is in German, so I translated it. I will post the original German message when I report back...


Cheers
manolito

[manolito]

@autodidact

Test results:

32-bit version works, but ETA display in dmMediaConverter is still way off, unusuable for me.

64-bit crashes immediately after calling it, this is the German error message:


[Attachment 92279 - Click to enlarge]


I hope that this will be helpful...

Cheers
manolito

[autodidact]

@manolito
Thank you for testing and reporting.
The svt-AV1 library just added that function and the library is only included in the 64-bit build.
I will remove it for now and make new 64-bit builds.

[oniiz86]

@autodidact Thanks for the explanation & sorry to have troubled you about it, will the 32-bit build be updated too as @manolito had noted "ETA display in dmMediaConverter is still way off, unusuable for me", is there any way to correct that? Also I forgot to mention if your Windows 7 builds have DRC disabled (-drc_scale 0) for AC3/EAC3 decoding?

[autodidact]

Replaced the 64-bit builds in post #33 and #89.

[autodidact]

Thanks for the explanation & sorry to have troubled you about it, will the 32-bit build be updated too as @manolito had noted "ETA display in dmMediaConverter is still way off, unusuable for me", is there any way to correct that? Also I forgot to mention if your Windows 7 builds have DRC disabled (-drc_scale 0) for AC3/EAC3 decoding?

I don't know how that program interacts with ffmpeg but my guess is that it is an api change rather than faulty code
and it may be that the author of that program will have to adjust to the new version.

I haven't changed ffmpeg defaults but if that is a desired change and simple to implement I would consider it.

[manolito]

Thanks autodidact for the updated 64-bit versions. I only tested the release version, but no problems. The borked ETA display under dmMediaEncoder is still there, no change to the previous version...

Maybe it´s time for some info about dmMediaEncoder:

The Windows home page is here:
https://forum.doom9.org/showthread.php?t=170645

Download link for the last stable version:
https://github.com/mdalacu/dmMediaConverter/releases/tag/v2.5.5


One of the features of this GUI is that it does not try to interact with the FFmpeg console window. The GUI just collects encoding options and creates an FFmpeg command line from these option. It does not try to interfere with the FFmpeg executable at all. The dmMediaEncoder executable for Windows is 32-bit only, but it has no problems being paired with a 64-bit FFmpeg version.

During the encode the GUI intercepts the console output and creates a Windows progress screen which also displays the ETA information. I have no idea if this ETA information is directly taken from the console or if it is recalculated by the GUI. Whatever, it works fine under FFmpeg 7.x, and it fails under FFmpeg 8.x.

This is not really importand for me, the FFmpeg 7 versions work just fine here.


Cheers
manolito