Recherche avancée

Sur d’autres sites (12928)

• FFMPEG Compilation on Windows 32 bit Vs 64 bit

  15 janvier 2016, par ARK

  When I try to compile ffmpeg using MinGW, targeting 32-bit, I observed below error for several files :

  c :\mingw\include\unistd.h:79:1 : error : expected ’,’ or ’ ;’ before
  ’int’
  int __mingw_sleep( unsigned long, unsigned long ) ;
  ^
  In file included from c :\mingw\include\zconf.h:452:0,
  from c :\mingw\include\zlib.h:34,
  from c :/Work/FFMPEG_2.8.4/src/libavcodec/pngenc.c:35 :
  c :\mingw\include\unistd.h:105:1 : error : expected ’,’ or ’ ;’ before
  ’int’
  int nanosleep( const struct timespec *, struct timespec * ) ;
  ^
  c :\mingw\include\unistd.h:125:28 : error : expected ’,’ or ’ ;’
  before ’usleep’
  int _cdecl __MINGW_NOTHROW usleep( useconds_t
  )__MINGW_ATTRIB_DEPRECATED ;
  ^
  c :\mingw\include\unistd.h:138:10 : error : conflicting types for ’_cdecl’
  unsigned _cdecl
  __MINGW_NOTHROW sleep( unsigned ) ;
  ^
  c :\mingw\include\unistd.h:125:5 : note : previous declaration of ’_cdecl’ was here

  int _cdecl _MINGW_NOTHROW usleep( useconds_t
  )_MINGW_ATTRIB_DEPRECATED ;
  ^
  c :\mingw\include\unistd.h:138:33 : error : expected ’,’ or ’ ;’ before ’sleep’
  unsigned _cdecl _MINGW_NOTHROW sleep( unsigned ) ;
  ^
  c :\mingw\include\unistd.h:153:12 : error : expected ’=’, ’,’, ’ ;’, ’asm’ or ’_att
  ribute__’ before
  ’ftruncate’ int _cdecl ftruncate( int, off_t ) ;
  ^
  make : *** [libavcodec/pngenc.o] Error 1

  Similar issue was faced by someone and I provided a solution (workaround) in another forum

  Recently, I started FFMPEG compilation targeting to 64-bit. FFMPEG code (version 2.8.4) downloaded from the ffmpeg site compiled straight for 64-bit. I was expecting errors, but surprisingly I don’t see above errors. Then I thought FFMPEG could have fixed the issues, but it started showing up above errors again when I compiled it for 32-bit. Initially I thought it may be to do with my compilation environment, but similar issue was faced by some other people as well. So, I can confidently rule out the compilation environment factor.

  So the question here is, how come above error is specific to 32-bit. I couldn’t understand a bit, any idea about this behavior ??

• aarch64 : Make transpose_4x4H do a regular transpose

  25 mars 2016, par Martin Storsjö

  aarch64 : Make transpose_4x4H do a regular transpose
  Previously, ff_h264_idct_add_neon (originally in the arm version) used
  
  a non-regular transpose in order to be able to use more instructions
  
  that deal with registers as 128 bit register pairs. The aarch64
  
  translation doesn’t do it to the same extent, but brought along the
  
  same structure since it was a straight translation.
  This reshuffles ff_h264_idct_add_neon, bringing it closer to
  
  the C implementation, making the transpose_4x4H macro do a regular
  
  transpose, usable for other algorithms as well.
  Previously, the third and fourth output from transpose_4x4H were
  
  swapped, and prior to cc29d96d5a, the same inputs as well. In
  
  addition to just swapping the outputs, also renumber the intermediate
  
  registers for better readability (making the register order match
  
  transpose_4x8B).
  This runs with the same number of cycles as before.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DBH] libavcodec/aarch64/h264idct_neon.S
  • [DBH] libavcodec/aarch64/neon.S

• lavc/utils : Introduce ff_bprint_to_codecpar_extradata for avformat

  31 mars 2016, par Hendrik Leppkes

  lavc/utils : Introduce ff_bprint_to_codecpar_extradata for avformat
  It will be used by text subtitle demuxers to construct format instructions
  
  straight into extradata. They all currently a similar function that accepts
  
  an AVCodecContext instead.
  Signed-off-by : Derek Buitenhuis <derek.buitenhuis@gmail.com>
  

  • [DH] libavformat/internal.h
  • [DH] libavformat/utils.c