Recherche avancée

Sur d’autres sites (9023)

• Unresolved externals with statically built ffmpeg on Windows

  7 juillet 2013, par user1764961

  I built ffmpeg 1.2.1 as a static lib - x64, debug. And I tried to open one of my older projects that links against it. After modifying some changed APIs and similar in my source, it compiled fine, but I have major problems with linking.

  EDITED : the complete latest build output :

  1>libavformat.a(mov.o) : error LNK2019: unresolved external symbol __imp__gmtime64 referenced in function mov_read_mvhd
  
  1>libavutil.a(parseutils.o) : error LNK2001: unresolved external symbol __imp__gmtime64
  
  1>libavformat.a(os_support.o) : error LNK2019: unresolved external symbol __imp__wsopen referenced in function ff_win32_open
  
  1>libavcodec.a(pthread.o) : error LNK2019: unresolved external symbol __imp__beginthreadex referenced in function ff_thread_init
  
  1>libavcodec.a(frame_thread_encoder.o) : error LNK2001: unresolved external symbol __imp__beginthreadex
  
  1>libavutil.a(parseutils.o) : error LNK2019: unresolved external symbol __imp__localtime64 referenced in function av_parse_time
  
  1>libavutil.a(parseutils.o) : error LNK2019: unresolved external symbol __imp__time64 referenced in function av_parse_time
  
  1>libavutil.a(parseutils.o) : error LNK2019: unresolved external symbol __imp__mktime64 referenced in function av_parse_time
  
  1>libmingwex.a(lib64_libmingwex_a-mingw_output_format.o) : error LNK2019: unresolved external symbol __mingw_get_msvcrt_handle referenced in function __mingw_set_output_format
  
  1>libmingwex.a(lib64_libmingwex_a-mingw_get_codepage.o) : error LNK2001: unresolved external symbol __mingw_get_msvcrt_handle

  What am I doing wrong ?
  What am I missing here ?
  Does ffmpeg even work today on Windows platform as a static lib, or it becomes less functional on Windows with each new version ?

• FFmpeg development on Eclipse on Windows

  10 juillet 2013, par Juan Ayala

  The first thing I did was to refer to tutorial on FFmpeg site.

  I set up MSYS+MinGW64, I cloned all the relevant pre-requisites (i.e OpenSSL, x264, rtmpdump),
  I successfully cross-compiled them all. I ran the configure for FFmpeg, and I was able to cross-compile that as well. And my statically linked ffmpeg.exe works to my satisfaction.

  In Eclipse I was able to create a project, load up the source code, navigate it, make some changes, even compile and step-through debug. The problem I am having is with the Eclipse design-time error, and I think this is more of an Eclipse/C++ thing than FFmpeg.

  For example in ffmpeg.c I find this error "Field 'bitstream_filters' could not be resolved" at this line :

  AVBitStreamFilterContext *bsfc = output_streams[i]->bitstream_filters;

  that output_streams is of type

  OutputStream **output_streams

  and when I try to open the declaration for OutputStream Eclipse gives me the option of two locations. Obviously Eclipse is not sure which of these declarations it is, hence the "could not be resolved" error. OutputStream is defined in the following 2 files

  • ffmpeg.h
  • libavformat/smoothstreamingenc.c

  (hmm nice to know FFmpeg can do smooth streaming...) but anyway the correct definition would of been the one in ffmpeg.h.

  So... the whole goal of getting the source into an IDE was so that I could enjoy the benefits of such things like intelisense. What can I do in Eclipse to set some sort of order or rule as to how it should resolve types in cases where the names clash like this ?

• libFLAC : Add more checks to partial_tukey and punchout_tukey windows.

  13 novembre 2014, par Martijn van Beurden

  libFLAC : Add more checks to partial_tukey and punchout_tukey windows.
  Signed-off-by : Erik de Castro Lopo <erikd@mega-nerd.com>
  

  • [DH] src/libFLAC/window.c