Recherche avancée

Sur d’autres sites (2946)

• 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 ?

• lavu/log,opt : detect setting non-runtime options post-init

  28 septembre 2024, par Anton Khirnov

  lavu/log,opt : detect setting non-runtime options post-init
  Add a mechanism to AVClass to allow objects to signal their state to
  
  generic code. When an object flags itself with the 'initialized' state,
  
  print an error (and fail, after the next major bump) if the caller
  
  attempts to set non-runtime options.
  

  • [DH] doc/APIchanges
  • [DH] libavutil/log.h
  • [DH] libavutil/opt.c
  • [DH] libavutil/version.h

• What's FFmpeg doing with avcodec_send_packet() ?

  4 avril, par Jim

  I'm trying to optimise a piece of software for playing video, which internally uses the FFmpeg libraries for decoding. We've found that on some large (4K, 60fps) video, it sometimes takes longer to decode a frame than that frame should be displayed for ; sadly, because of the problem domain, simply buffering/skipping frames is not an option.

  


  However, it appears that the FFmpeg executable is able to decode the video in question fine, at about 2x speed, so I've been trying to work out what we're doing wrong.

  


  I've written a very stripped-back decoder program for testing ; the source is here (it's about 200 lines). From profiling it, it appears that the one major bottleneck during decoding is the avcodec_send_packet() function, which can take up to 50ms per call. However, measuring the same call in FFmpeg shows strange behaviour :

  


  

  


  (these are the times taken for each call to avcodec_send_packet() in milliseconds, when decoding a 4K 25fps VP9-encoded video.)

  


  Basically, it seems that when FFmpeg uses this function, it only really takes any amount of time to complete every N calls, where N is the number of threads being used for decoding. However, both my test decoder and the actual product use 4 threads for decoding, and this doesn't happen ; when using frame-based threading, the test decoder behaves like FFmpeg using only 1 thread. This would seem to indicate that we're not using multithreading at all, but we've still seen performance improvements by using more threads.

  


  FFmpeg's results average out to being about twice as fast overall as our decoders, so clearly we're doing something wrong. I've been reading through FFmpeg's source to try to find any clues, but it's so far eluded me.

  


  My question is : what's FFmpeg doing here that we're not ? Alternatively, how can we increase the performance of our decoder ?

  


  Any help is greatly appreciated.