Recherche avancée

Sur d’autres sites (11046)

• avformat/segment : Don't overwrite AVCodecParameters after init

  6 septembre 2020, par Andreas Rheinhardt

  avformat/segment : Don't overwrite AVCodecParameters after init
  The segment muxer copies the user-provided AVCodecParameters to the
  
  newly created child streams in its init function before initializing the
  
  child muxer ; and since commit 8e6478b723affe4d44f94d34b98e0c47f6a0b411,
  
  it does this again before calling avformat_write_header() if that is
  
  called from seg_write_header(). The reason for this is complicated :
  At that time writing the header was delayed, i.e. it was not triggered
  
  by avformat_write_header() (unless the AVFMT_FLAG_AUTO_BSF was unset),
  
  but instead by writing the very first packet. The rationale behind this
  
  was to allow to run bitstream filters on the packets in the interleavement
  
  queue in order to generate missing extradata from them before the muxer's
  
  write_header function is actually called.
  The segment muxer went even further : It initialized the child muxer and
  
  ran the child muxer's check_bitstream functions on the packets in its
  
  own muxing queue and stole any bitstream filters that got inserted. The
  
  reason for this is that the segment muxer has an option to write the
  
  header to a separate file and for this it is needed to write the child
  
  muxer's header without delay, but with correct extradata. Unsetting
  
  AVFMT_FLAG_AUTO_BSF for the child muxer accomplished the first goal and
  
  stealing the bitstream filters the second ; and in order for the child
  
  muxer to actually use the updated extradata, the old AVCodecParameters
  
  (set before avformat_init_output()) were overwritten with the new ones.
  Updating the extradata proceeded as follows : The bitstream filter itself
  
  simply updated the AVBSFContext's par_out when processing a packet, in
  
  violation of the new BSF API (where par_out may only be set in the init
  
  function) ; the muxing code then simply forwarded the updated extradata,
  
  overwriting the par_in of the next BSF in the BSF chain with the fresh
  
  par_out of the last one and the AVStream's par with the par_out of the
  
  last BSF. This was an API violation, too, of course, but it made
  
  remuxing ADTS AAC into mp4/matroska work.
  But this no longer serves a useful purpose since the aac_adtstoasc BSF
  
  was updated to propagate new extradata via packet side data in commit
  
  f63c3516577d605e51cf16358cbdfa0bc97565d8 ; the next commit then removed
  
  the code in mux.c passing new extradata along the filter chain. This
  
  alone justifies removing the code for setting the AVCodecParameters a
  
  second time.
  But there is even another reason to do so : It is harmful. The ogg muxer
  
  parses the extradata of Theora and Vorbis in its init function and keeps
  
  pointers to parts of it. Said pointers become dangling when the
  
  extradata is overwritten by the segment muxer, leading to
  
  use-after-frees as has happened in ticket #8881 which this commit fixes.
  Ticket #8517 is about another issue caused by this : Immediately after
  
  having overwritten the old AVCodecParameters the segment muxer checks
  
  whether the codec_tag is ok (the codec_tag is set generically when
  
  initializing the child muxer based upon muxer-specific lists). The check
  
  used is : If the child output format has such a list and if the codec tag
  
  of the non-child stream does not match the codec id given the list of
  
  codec tags and if there is a match for the codec id in the codec tag
  
  list, then set the codec tag to zero (and not to the existing match),
  
  otherwise set the codec tag of the child stream to the codec tag
  
  of the corresponding stream of the main AVFormatContext (which is btw
  
  redundant given that the child AVCodecParameters have just been
  
  overwritten with the AVCodecParameters of the corresponding stream of
  
  the main AVFormatContext).
  Reviewed-by : Ridley Combs <rcombs@rcombs.me>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavformat/segment.c

• _stricoll is unsolved while linking the libmingwex.a with vs2010

  19 septembre 2013, par damantou

  I am tending to build some app which staticly links the ffmpeg libs on windows 8. I have successfully build the static lib of ffmpeg in mingw/msys env on windows 8. Then I use cmake to generate the vs2010 project to start work with my app.

  While I am trying to build the first dead simple main program, I got quite some link errors.

  extern "C" {
  
  
  
  // to work around error:
  
  // 'UINT64_C': identifier not found
  
  #ifndef __STDC_CONSTANT_MACROS
  
  #define __STDC_CONSTANT_MACROS
  
  #endif
  
  
  
  
  
  #include <libavcodec></libavcodec>avcodec.h>
  
  #include <libavformat></libavformat>avformat.h>
  
  #include <libswscale></libswscale>swscale.h>
  
  
  
  }
  
  
  
  
  
  int main(int argc, char *argv[])
  
  {
  
      av_register_all();
  
      return 0;
  
  }

  After struggling with a bunch of unresolved symbols, I come up with the following libraries to link with in order :

  c:/MinGW/mingw32/lib/libiconv.a
  
  libavcodec.a
  
  libavdevice.a
  
  libavfilter.a
  
  libavformat.a
  
  libavutil.a
  
  libswresample.a
  
  libswscale.a
  
  c:/MinGW/lib/gcc/mingw32/4.8.1/libgcc.a
  
  c:/MinGW/mingw32/lib/libws2_32.a
  
  c:/MinGW/mingw32/lib/libmingw32.a
  
  c:/MinGW/mingw32/lib/libmingwex.a

  Finally there is one unresolved symbol issue not able to fix :

  libmingwex.a(glob.o) : error LNK2019: unresolved external symbol 
  
                         _stricoll referenced in function _glob_match

  I tried to add some a fake function, but still not help :(

  int  __cdecl _stricoll(_In_z_  const char * _Str1, _In_z_  const char * _Str2)
  
  {
  
      return 0;
  
  };

  I googled it the whole morning, but nobody ever mentioned this problem. I guess there should be simple reason and solution for this, maybe because of my ignorance on simple knowledge.

• _stricoll is unsolved while linking the libmingwex.a with vs2010

  14 mai 2018, par damantou

  I am tending to build some app which staticly links the ffmpeg libs on windows 8. I have successfully build the static lib of ffmpeg in mingw/msys env on windows 8. Then I use cmake to generate the vs2010 project to start work with my app.

  While I am trying to build the first dead simple main program, I got quite some link errors.

  extern "C" {
  
  
  
  // to work around error:
  
  // 'UINT64_C': identifier not found
  
  #ifndef __STDC_CONSTANT_MACROS
  
  #define __STDC_CONSTANT_MACROS
  
  #endif
  
  
  
  
  
  #include <libavcodec></libavcodec>avcodec.h>
  
  #include <libavformat></libavformat>avformat.h>
  
  #include <libswscale></libswscale>swscale.h>
  
  
  
  }
  
  
  
  
  
  int main(int argc, char *argv[])
  
  {
  
      av_register_all();
  
      return 0;
  
  }

  After struggling with a bunch of unresolved symbols, I come up with the following libraries to link with in order :

  c:/MinGW/mingw32/lib/libiconv.a
  
  libavcodec.a
  
  libavdevice.a
  
  libavfilter.a
  
  libavformat.a
  
  libavutil.a
  
  libswresample.a
  
  libswscale.a
  
  c:/MinGW/lib/gcc/mingw32/4.8.1/libgcc.a
  
  c:/MinGW/mingw32/lib/libws2_32.a
  
  c:/MinGW/mingw32/lib/libmingw32.a
  
  c:/MinGW/mingw32/lib/libmingwex.a

  Finally there is one unresolved symbol issue not able to fix :

  libmingwex.a(glob.o) : error LNK2019: unresolved external symbol 
  
                         _stricoll referenced in function _glob_match

  I tried to add some a fake function, but still not help :(

  int  __cdecl _stricoll(_In_z_  const char * _Str1, _In_z_  const char * _Str2)
  
  {
  
      return 0;
  
  };

  I googled it the whole morning, but nobody ever mentioned this problem. I guess there should be simple reason and solution for this, maybe because of my ignorance on simple knowledge.