Recherche avancée

Sur d’autres sites (8308)

• What option controls whether GLSLang gets built in FFmpeg ?

  10 février 2023, par TigerhawkT3

  I'm using Media Autobuild Suite to build a more comprehensive FFmpeg executable for Windows than what's available in binaries distributed online, but I've encountered issues. I've resolved errors in a couple libraries by skipping them (commenting them out in ffmpeg_options.txt), but I'm stuck on the GLSLang module (OpenGL Shader Language). I've already disabled it and OpenGL in ffmpeg_options.txt as well as other switches labeled "options that add shared dependencies," and the suite is still trying to build it.

  


  Disabled options :

  


  #--enable-fontconfig
#--enable-libmfx
#--enable-decklink
#--enable-librist
#--enable-librtmp
#--enable-libssh
#--enable-libtesseract
#--enable-vapoursynth
#--enable-liblensfun
#--enable-libglslang
#--enable-vulkan
#--enable-opencl
#--enable-opengl
#--enable-cuda-nvcc
#--enable-libnpp
#--enable-libopenh264


  


  The failed build generates an entire folder of logs, but here's the error message that prints in the console :

  


    Running git clone for glslang...
  Running git update for glslang...
┌ glslang git  ........................................ [Recently updated]
├ Running dependencies...
Likely error (tail of the failed operation logfile):
CPPFLAGS: -D_FORTIFY_SOURCE=0 -D__USE_MINGW_ANSI_STDIO=1
CFLAGS: -mthreads -mtune=generic -O2 -pipe
CXXFLAGS: -mthreads -mtune=generic -O2 -pipe
LDFLAGS: -pipe -static-libgcc -static-libstdc++
/usr/bin/python ./update_glslang_sources.py
/usr/bin/python: can't open file '/build/glslang-git/./update_glslang_sources.py': [Errno 2] No such file or directory
dependencies failed. Check C:/mab_suite/build/glslang-git/ab-suite.dependencies.log
This is required for other packages, so this script will exit.
  Creating diagnostics file...

Attach C:\mab_suite\build\logs.zip to the GitHub issue.
Make sure the suite is up-to-date before reporting an issue. It might've been fixed already.

Try running the build again at a later time.


  


  What modules/libraries do I have to fix or skip to prevent this error from causing the build to fail ?

  


• Announcing TMPGEnc 4 : now with x264 !

  26 novembre 2010, par Dark Shikari — commercial, japan, licensing, x264

  A few months ago, we announced a commercial licensing program so that even companies unable to use GPL software in their products have a chance to use the open source x264 instead of proprietary alternatives. The system worked on two basic concepts. First, all licensees would still be required to give their changes to x264 back to us : x264 must forever remain free, with no useful contributions kept hidden from the community. Second, all the profits would go directly back to x264, primarily to the developers who’ve made the most significant contributions to x264 over the years, but also to funding future development, bounties for new features, as well as contributing to other related projects (e.g. Videolan and ffmpeg).

  Over the past couple of months, we’ve gotten an enormous response ; over 40 companies have inquired about licensing, with more contacting us every day. Due to the sheer volume of interest, we’ve partnered with CoreCodec, the creators of the free Matroska container format and developers of CoreAVC, to make x264 as widely available as possible in the world of commercial software as it is in the world of open source. All of this is already filtering back to benefiting x264 users, with many bugs being reported by commercial licensees as well as some code contributed.

  Today, we announce the first commercial consumer encoding software to switch to x264 : Pegasys Inc.’s TMPGEnc. Expect many more to follow : with x264 now available commercially as well as freely, there are few excuses left to use any other H.264 encoder. Vendors of overpriced, underpowered proprietary competitors should begin looking for new jobs.

  (Pegasys press release : English, Japanese)

• Why are some delay load DLLs immediately unloaded with FFMPEG ?

  21 avril 2020, par alvion

  I've built ffmpeg as DLLs and linked them to my application, which runs fine when the DLLs are in the executable folder. Because I would like to load different builds of ffmpeg for different project configurations, I need to put them in different folders than the .exe (ie "/bin/ffmpeg/config1", "/bin/ffmpeg/config2", etc). The only way I know how to do this without modifying the environment PATH is to mark the DLLs as "delay load" and then specify the full path via LoadLibrary calls at startup.

  



  This works fine for other DLLs, but for FFMPEG I'm having trouble getting it to work properly.

  



  I've specified the DLLs to DelayLoad in my vcxproj (actually in a linked .props file) :

  



    <delayloaddlls>&#xA;    avcodec-58.dll;avutil-56.dll;avformat-58.dll;swscale-5.dll;swresample-3.dll;&#xA;  </delayloaddlls>&#xA;

  



  And at startup, I'm loading them via LoadLibrary :

  



  LoadLibraryA("ffmpeg\\config1\\avcodec-58.dll");
LoadLibraryA("ffmpeg\\config1\\avutil-56.dll");
LoadLibraryA("ffmpeg\\config1\\avformat-58.dll");
LoadLibraryA("ffmpeg\\config1\\swscale-5.dll");
LoadLibraryA("ffmpeg\\config1\\swresample-3.dll");


  



  The strange thing is, when I make the LoadLibrary calls, it seems to be loading them and then unloading some of them immediately :

  



  'ffmpegtest.exe' (Win32): Loaded 'C:\ffmpegtest\bin\ffmpeg\medium\avcodec-58.dll'. Symbols loaded.
'ffmpegtest.exe' (Win32): Unloaded 'C:\ffmpegtest\bin\ffmpeg\medium\avcodec-58.dll'
'ffmpegtest.exe' (Win32): Loaded 'C:\ffmpegtest\bin\ffmpeg\medium\avutil-56.dll'. Symbols loaded.
'ffmpegtest.exe' (Win32): Loaded 'C:\ffmpegtest\bin\ffmpeg\medium\avformat-58.dll'. Symbols loaded.
'ffmpegtest.exe' (Win32): Unloaded 'C:\ffmpegtest\bin\ffmpeg\medium\avformat-58.dll'
'ffmpegtest.exe' (Win32): Loaded 'C:\ffmpegtest\bin\ffmpeg\medium\swscale-5.dll'. Symbols loaded.
'ffmpegtest.exe' (Win32): Loaded 'C:\ffmpegtest\bin\ffmpeg\medium\swresample-3.dll'. Symbols loaded.


  



  So, the problem DEFINITELY seems to be with the fact that it is choosing to unload some of the dlls. If I don't include any calls at all to LoadLibrary, then I get a crash in the very first line of code calling into these libraries, a function in avutil-56.dll. If I include the calls to LoadLibrary, then the first couple function calls succeed, and then we crash in the first call to an unloaded library, specifically "av_codec_iterate()" in avcodec-58.dll. If I copy the unloaded DLLs to the executable folder, then everything runs fine.

  



  Why are some of the DLLs being unloaded ? And how do I prevent it ?