VideoHelp Forum

+ Reply to Thread
Page 1 of 2
1 2 LastLast
Results 1 to 30 of 34
Thread
  1. This is the thread to post queries or requests about the ffmpeg binaries for Windows available at https://www.gyan.dev/ffmpeg/builds/
    Quote Quote  
  2. Any Git Full static linked 32-Bit version?
    Quote Quote  
  3. That needs a separate build environment. Too much hassle for too little demand. I think LigH.de makes them from time to time.
    Quote Quote  
  4. Hello. Thanks for your efforts. We 'd also need a LGPL version to include ffmpeg in commercial software.

    Best,
    Quote Quote  
  5. 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?
    Quote Quote  
  6. 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.
    Quote Quote  
  7. 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.
    Quote Quote  
  8. 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.
    Quote Quote  
  9. They clamp libvpx to a commit from Sep 16 2020. Mine uses the latest available at time of build.
    Quote Quote  
  10. 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.
    Quote Quote  
  11. You might want to add:
    a. vapoursynth support
    b. libplacebo support
    users currently on my ignore list: deadrats, Stears555
    Quote Quote  
  12. 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.
    Quote Quote  
  13. Member
    Join Date
    Oct 2020
    Location
    Canada
    Search PM
    I'd also be interested in seeing vapoursynth support in your builds.
    Quote Quote  
  14. Member
    Join Date
    Mar 2018
    Location
    Australia
    Search Comp PM
    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
    Quote Quote  
  15. @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
    users currently on my ignore list: deadrats, Stears555
    Quote Quote  
  16. Member
    Join Date
    Mar 2018
    Location
    Australia
    Search Comp PM
    Originally Posted by Selur View Post
    @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
    Quote Quote  
  17. 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
    users currently on my ignore list: deadrats, Stears555
    Quote Quote  
  18. Member
    Join Date
    Mar 2018
    Location
    Australia
    Search Comp PM
    Originally Posted by Selur View Post
    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
    Quote Quote  
  19. 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
    users currently on my ignore list: deadrats, Stears555
    Quote Quote  
  20. Member
    Join Date
    Oct 2020
    Location
    Canada
    Search PM
    Any chance of seeing vapoursynth support added to your builds? https://ffmpeg.org/general.html#VapourSynth
    Quote Quote  
  21. Will look into it.
    Quote Quote  
  22. Member
    Join Date
    May 2016
    Location
    Lithopolis, OH United States
    Search Comp PM
    Do you have an all purpose build that will allow for pretty basic conversion?
    Quote Quote  
  23. All builds will allow for pretty basic conversions.
    Quote Quote  
  24. Member
    Join Date
    Oct 2020
    Location
    Canada
    Search PM
    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?
    Quote Quote  
  25. 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.
    Quote Quote  
  26. Member
    Join Date
    Oct 2020
    Location
    Canada
    Search PM
    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?
    Quote Quote  
  27. 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.
    Quote Quote  
  28. 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.
    Quote Quote  
  29. Originally Posted by Secoast View Post
    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
    Code:
     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
    Code:
     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
    Quote Quote  
  30. 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.
    Quote Quote  



Similar Threads