FFmpeg Windows builds at gyan.dev

[Gyan]

This is the thread to post queries or requests about the ffmpeg binaries for Windows available at https://www.gyan.dev/ffmpeg/builds/

[ProWo]

Any Git Full static linked 32-Bit version?

[Gyan]

That needs a separate build environment. Too much hassle for too little demand. I think LigH.de makes them from time to time.

[muhahah]

Hello. Thanks for your efforts. We 'd also need a LGPL version to include ffmpeg in commercial software.

Best,

[Gyan]

A LGPL build is possible but workhorse libraries like x264 can't be included, and frequency of updates will be lower (probably monthly). Which libraries are useful for commercial bundlers?

[Antonis Savvidis]

Hello there mate and thank you for putting this effort to provide nicely packed .7z builds!
However I noticed a small error. While you do mention libvpx being present in the builds it actually isn't!

DEV.L. vp9 Google VP9 (decoders: vp9 libvpx-vp9 vp9_cuvid vp9_qsv ) (encoders: vp9_qsv )

it's just listed as a decoder but not as an encoder lib.
Thank you for your time once again.

[Gyan]

It's due to the latest commit in libvpx. A new header was added but isn't installed with the static lib, so ffmpeg disables the encoders during configure. Google's been informed.

[Antonis Savvidis]

Thank you for your reply, that does mane sense. However the people at https://github.com/BtbN/FFmpeg-Builds/releases seem to have found a workaround as libvpx works as an encoder there, however I prefer your builds so maybe you could somehow include their fix as well. Anyway, take care mate and thank you once again.

[Gyan]

They clamp libvpx to a commit from Sep 16 2020. Mine uses the latest available at time of build.

[Antonis Savvidis]

Yes your sounds like a better solution meaning it's not prone to forgetting an old trick after the codebase was updated back to functional. Makes sense. Thank you for your answer mate.

[Selur]

You might want to add:
a. vapoursynth support
b. libplacebo support

[Gyan]

libplacebo isn't useful as the wrapper has not been added yet. And merge will wait till one of the devs finishes their work on the Vulkan backend.

Will consider Vaouursynth.

[therobin]

I'd also be interested in seeing vapoursynth support in your builds.

[burt123]

Hi, just wondering if E-AC3 7.1 conversion / encoding will be incorporated into FFMPEG any time soon.

5.1 is nice, but nearly everything else is 7.1.

Cheers

[Selur]

@burt123: Not unless writes an encoder for it.
There's a feature request for it for 7 years (https://trac.ffmpeg.org/ticket/3595), 7.1 deocding was added three years ago, but no one wrote code for supporting 7.1 encoding.
-> I would be surprised if 7.1 e-ac3 encoding support would be added any time soon.

Cu Selur

[burt123]

@burt123: Not unless writes an encoder for it.
There's a feature request for it for 7 years (https://trac.ffmpeg.org/ticket/3595), 7.1 deocding was added three years ago, but no one wrote code for supporting 7.1 encoding.
-> I would be surprised if 7.1 e-ac3 encoding support would be added any time soon.

Cu Selur

Hi Cu Selur, thanks for your reply, and that's interesting that it WAS added, but no one carried on with it.....surely there is someone capable of "finishing this off".

I noticed LigH mentioned in that link you attached, I wonder if he knows something.

How could I contact him, other than a PM from any Forum he's commented on ??

I think it should be looked into, as it is being asked for more & more, these days.

Cheers

[Selur]

Cu = See ya

and that's interesting that it WAS added,

No is was not!
Only decoding, not encoding was written and added.

I doubt LigH has more to say than this, but contacting via PM here in the forum will probably work fine.

I think it should be looked into, as it is being asked for more & more, these days.

Sadly that does not means mean anyone with the means, knowledge and motivation is reengineering (iirc e-ac3 isn't free standard) code for it.
Also it does not seem to be that much asked for as nobody has even commented on it in the ffmpeg bug tracker for 10 month.

Cu Selur

[burt123]

Cu = See ya

and that's interesting that it WAS added,

No is was not!
Only decoding, not encoding was written and added.

I doubt LigH has more to say than this, but contacting via PM here in the forum will probably work fine.

I think it should be looked into, as it is being asked for more & more, these days.

Sadly that does not means mean anyone with the means, knowledge and motivation is reengineering (iirc e-ac3 isn't free standard) code for it.
Also it does not seem to be that much asked for as nobody has even commented on it in the ffmpeg bug tracker for 10 month.

Cu Selur

Well, I got a few things wrong, then didn't I, sorry "Selur" , I really should have known what "Cu" mean't.

OK, I misunderstood the added bit, so that's unfortunate.

OK, so I guess we'll have to be satisfied with 5.1, and that's all I can use anyway, I just thought it wouldn't hurt to ask.

Regards

[Selur]

I just thought it wouldn't hurt to ask.

it doesn't, but sadly asking here also doesn't change anything about it.
-> your best bet is probably asking in the bug tracker whether there was been any updates regarding 7.1 encoding support.

Cu Selur

[therobin]

Any chance of seeing vapoursynth support added to your builds? https://ffmpeg.org/general.html#VapourSynth

[Gyan]

Will look into it.

[Guernsey]

Do you have an all purpose build that will allow for pretty basic conversion?

[Gyan]

All builds will allow for pretty basic conversions.

[therobin]

Gyan, can you include the new libaom-av1 3.3.0 RC1 release into the builds? https://aomedia.googlesource.com/aom/+/refs/tags/v3.3.0-rc1

I would love to experiment with the improvements made.

Also, have you looked into --enable-vapoursynth yet?

[Gyan]

The libaom linked in the last two git builds are newer than the 3.3.0 RC1 tag commit.

Will look into VS time permitting.

[therobin]

When I encode with libaom-av1 using latest Feb 7th build it shows [libaom-av1 @ 00000000038a2b40] 3.2.0-468-g371db7fdf in the output when the encode begins.

Is that information being posted in the output incorrect or is the wrong version being built?

[Gyan]

That looks to be related to how aom sets its version string. In 3.2.0-468-g37b7fd1df, 37b7fd1df is the commit hash of the src which is built. This is newer than 3.3.0 RC1.

[Secoast]

Relatively new to ffmpeg. Just wondering.

At gyan.dev it says...
This site offers builds in a couple of variants: the essentials build variant contains commonly used libraries, whereas the full build variant also contains most of the remainder. All variants contain all internal components available for Windows.

Does this essentially mean there is no benefit to installing the full version on windows?

Thankyou.

[poisondeathray]

Relatively new to ffmpeg. Just wondering.

At gyan.dev it says...
This site offers builds in a couple of variants: the essentials build variant contains commonly used libraries, whereas the full build variant also contains most of the remainder. All variants contain all internal components available for Windows.

Does this essentially mean there is no benefit to installing the full version on windows?

Thankyou.

The "benefit" of the full version is additional libraries

https://www.gyan.dev/ffmpeg/builds/#about-these-builds

eg. if you don't need libbluray or opencl , or any in the list, you might consider the essentials version

libraries in essentials build

 avisynth+ libaom libass libfreetype libfribidi libgme libgsm libmp3lame libopencore-amrnb libopencore-amrwb libopenjpeg libopenmpt libopus librubberband libspeex libsrt libssh libtheora libvidstab libvmaf libvo-amrwbenc libvorbis libvpx libwebp libx264 libx265 libxvid libzimg libzmq mediafoundation sdl2

additional libraries in full build

 chromaprint frei0r ladspa libbluray libbs2b libcaca libcdio libdav1d libdavs2 libflite libilbc libmodplug libmysofa libplacebo librav1e librist libshaderc libshine libsnappy libsoxr libsvtav1 libtwolame libuavs3d libxavs2 libzvbi opencl vulkan

[Secoast]

Thankyou for your prompt response.

I was mistakenly reading this as the full build contains libraries that are not designed for Windows. I had a look at the libraries list and came to the conclusion that I don't know what I will, or won't need in the future, so will just stay with the full build.

Thanks again.