Recherche avancée

Sur d’autres sites (5905)

• Build FFMPEG under Cygwin in Windows OS for Android

  8 juin 2017, par Jun Kim

  For the past couple days, I have been trying hard to build FFMPEG for a Android project on Windows Operating System using android-ndk-14d using Cygwin.
  I have followed many tutorials out there, and I ahve encountered so many errors while building FFMPEG using build_android.sh.

  Here are the steps that I have taken so far.

  I downloaded Cygwin and configured all the dependencies that I need for building FFMPEG.

  I opened ffmpeg-3.3.1/configure file with a text editor, and changed to the following lines.

  SLIBNAME_WITH_MAJOR='$(SLIBPREF)$(FULLNAME)-$(LIBMAJOR)$(SLIBSUF)'
  
  LIB_INSTALL_EXTRA_CMD='$$(RANLIB) "$(LIBDIR)/$(LIBNAME)"'
  
  SLIB_INSTALL_NAME='$(SLIBNAME_WITH_MAJOR)'
  
  SLIB_INSTALL_LINKS='$(SLIBNAME)'

  my build_android.sh is as below

  #!/bin/bash
  
  NDK=C:/~/ndk-bundle
  
  SYSROOT=$NDK/platforms/android-21/arch-arm/
  
  TOOLCHAIN=$NDK/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64
  
  function build_one
  
  {
  
  ./configure \
  
      --prefix=$PREFIX \
  
      --enable-shared \
  
      --disable-static \
  
      --disable-doc \
  
      --disable-ffmpeg \
  
      --disable-ffplay \
  
      --disable-ffprobe \
  
      --disable-ffserver \
  
      --disable-avdevice \
  
      --disable-doc \
  
      --disable-symver \
  
      --cross-prefix=$TOOLCHAIN/bin/arm-linux-androideabi-\
  
      --target-os=android \
  
      --arch=arm \
  
      --cpu=armv7-a \
  
      --enable-cross-compile \
  
      --sysroot=$SYSROOT \
  
      --extra-cflags="-Os -fpic $ADDI_CFLAGS" \
  
      --extra-ldflags="$ADDI_LDFLAGS" \
  
      $ADDITIONAL_CONFIGURE_FLAG
  
  make clean
  
  make
  
  make install
  
  }
  
  CPU=arm
  
  PREFIX=$(pwd)/android/$CPU
  
  ADDI_CFLAGS="-marm"
  
  build_one

  I ran these commands

  dos2unix build_android.sh 
  
  chmod +x build_android.sh
  
  ./build_android.sh

  and,,,currently getting this error

  c :/users/sonic/appdata/local/android/sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/p
  rebuilt/windows-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.9.x/../../../../arm-linux-an
  droideabi/bin/ld.exe : error : libavutil/libavutil.so:1:1 : syntax error,
  unexpected ’ !’, exp ecting $end

  c :/users/sonic/appdata/local/android/sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/p
  rebuilt/windows-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.9.x/../../../../arm-linux-an
  droideabi/bin/ld.exe : error : libavutil/libavutil.so : not an object or
  archive collect2.exe : error : ld returned 1 exit status
  make : *** [library.mak:94 : libswscale/libswscale-4.so] Error 1 LD

  libswscale/libswscale-4.so
  c :/users/sonic/appdata/local/android/sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/p
  rebuilt/windows-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.9.x/../../../../arm-linux-an
  droideabi/bin/ld.exe : error : libavutil/libavutil.so:1:1 : syntax error,
  unexpected ’ !’, exp ecting $end

  c :/users/sonic/appdata/local/android/sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/p
  rebuilt/windows-x86_64/bin/../lib/gcc/arm-linux->androideabi/4.9.x/../../../../arm-linux-an
  droideabi/bin/ld.exe : error : libavutil/libavutil.so : not an object or
  archive collect2.exe : error : ld returned 1 exit status make : ***
  [library.mak:94 : libswscale/libswscale-4.so] Error 1

  How to compile ffmpeg-2.5.3 on windows with android-ndk-r10d

  From the comments that were commented on the above link, it seems like it is
  easier to build FFMPEG in Linux/Unix OS. My first can be a dumb question. But If there is anyone who can guide me through this, i will be really appreciated it.

  If I build FFMPEG on Linux for Android, could I possibly copy or move those
  resulted output (The arm/lib folder contains the shared libraries, while arm/include folder contains the header files for libavcodec, libavformat, libavfilter, libavutil, libswscale etc.) to Windows OS and utilize them for
  my Android project ?

  Since my company only provides Windows OS for a project, I have to utilize them on Windows OS.

  Thank you for your time, and if there is any feedback that you can provide it will definitely be helpful.

  For the reference, here is my config.log

  END c :/ffmpegtmp/ffconf.qoBF6X98.c
  C :/Users/sonic/AppData/Local/Android/sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/bin/arm-linux-androideabi-gcc —sysroot=C :/Users/sonic/AppData/Local/Android/sdk/ndk-bundle/platforms/android-9/arch-arm/

  -isysroot C :/Users/sonic/AppData/Local/Android/sdk/ndk-bundle/platforms/android-9/arch-arm/
  -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Dstrtod=avpriv_strtod -DPIC -Os -fpic -marm -march=armv7-a -std=c11 -fomit-frame-pointer -fPIC -marm -pthread -g -Wdeclaration-after-statement -Wall -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes -Wno-pointer-to-int-cast -Wstrict-prototypes -Wempty-body -Wno-parentheses -Wno-switch -Wno-format-zero-length -Wno-pointer-sign -O3 -fno-math-errno -fno-signed-zeros -fno-tree-vectorize -Werror=format-security -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=return-type -Werror=vla -Wformat -c -o c :/ffmpegtmp/ffconf.8joa74tC.o

  c :/ffmpegtmp/ffconf.qoBF6X98.c
  check_cflags -fdiagnostics-color=auto test_cflags
  -fdiagnostics-color=auto check_cc -fdiagnostics-color=auto BEGIN c :/ffmpegtmp/ffconf.qoBF6X98.c
  1 int x ; END c :/ffmpegtmp/ffconf.qoBF6X98.c C :/Users/sonic/AppData/Local/Android/sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/bin/arm-linux-androideabi-gcc —sysroot=C :/Users/sonic/AppData/Local/Android/sdk/ndk-bundle/platforms/android-9/arch-arm/

  -isysroot C :/Users/sonic/AppData/Local/Android/sdk/ndk-bundle/platforms/android-9/arch-arm/
  -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Dstrtod=avpriv_strtod -DPIC -Os -fpic -marm -march=armv7-a -std=c11 -fomit-frame-pointer -fPIC -marm -pthread -g -Wdeclaration-after-statement -Wall -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes -Wno-pointer-to-int-cast -Wstrict-prototypes -Wempty-body -Wno-parentheses -Wno-switch -Wno-format-zero-length -Wno-pointer-sign -O3 -fno-math-errno -fno-signed-zeros -fno-tree-vectorize -Werror=format-security -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=return-type -Werror=vla -Wformat -fdiagnostics-color=auto -c -o c :/ffmpegtmp/ffconf.8joa74tC.o c :/ffmpegtmp/ffconf.qoBF6X98.c test_cflags -Wmaybe-uninitialized check_cc -Wmaybe-uninitialized BEGIN

  c :/ffmpegtmp/ffconf.qoBF6X98.c
  1 int x ; END c :/ffmpegtmp/ffconf.qoBF6X98.c C :/Users/sonic/AppData/Local/Android/sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/bin/arm-linux-androideabi-gcc —sysroot=C :/Users/sonic/AppData/Local/Android/sdk/ndk-bundle/platforms/android-9/arch-arm/

  -isysroot C :/Users/sonic/AppData/Local/Android/sdk/ndk-bundle/platforms/android-9/arch-arm/
  -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Dstrtod=avpriv_strtod -DPIC -Os -fpic -marm -march=armv7-a -std=c11 -fomit-frame-pointer -fPIC -marm -pthread -g -Wdeclaration-after-statement -Wall -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes -Wno-pointer-to-int-cast -Wstrict-prototypes -Wempty-body -Wno-parentheses -Wno-switch -Wno-format-zero-length -Wno-pointer-sign -O3 -fno-math-errno -fno-signed-zeros -fno-tree-vectorize -Werror=format-security -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=return-type -Werror=vla -Wformat -fdiagnostics-color=auto -Wmaybe-uninitialized -c -o c :/ffmpegtmp/ffconf.8joa74tC.o c :/ffmpegtmp/ffconf.qoBF6X98.c

• checkasm : Explicitly declare function prototypes

  16 août 2015, par Henrik Gramner

  checkasm : Explicitly declare function prototypes
  Now we no longer have to rely on function pointers intentionally
  
  declared without specified argument types.
  This makes it easier to support functions with floating point parameters
  
  or return values as well as functions returning 64-bit values on 32-bit
  
  architectures. It also avoids having to explicitly cast strides to
  
  ptrdiff_t for example.
  

  • [DH] tests/checkasm/Makefile
  • [DH] tests/checkasm/bswapdsp.c
  • [DH] tests/checkasm/checkasm.c
  • [DH] tests/checkasm/checkasm.h
  • [DH] tests/checkasm/h264pred.c
  • [DH] tests/checkasm/h264qpel.c
  • [DH] tests/checkasm/x86/checkasm.asm

• avutil/mathematics : speed up av_gcd by using Stein’s binary GCD algorithm

  11 octobre 2015, par Ganesh Ajjanagadde

  avutil/mathematics : speed up av_gcd by using Stein’s binary GCD algorithm
  This uses Stein’s binary GCD algorithm :
  
  https://en.wikipedia.org/wiki/Binary_GCD_algorithm
  
  to get a roughly 4x speedup over Euclidean GCD on standard architectures
  
  with a compiler intrinsic for ctzll, and a roughly 2x speedup otherwise.
  
  At the moment, the compiler intrinsic is used on GCC and Clang due to
  
  its easy availability.
  Quick note regarding overflow : yes, subtractions on int64_t can, but the
  
  llabs takes care of that. The llabs is also guaranteed to be safe, with
  
  no annoying INT64_MIN business since INT64_MIN being a power of 2, is
  
  shifted down before being sent to llabs.
  The binary GCD needs ff_ctzll, an extension of ff_ctz for long long (int64_t). On
  
  GCC, this is provided by a built-in. On Microsoft, there is a
  
  BitScanForward64 analog of BitScanForward that should work ; but I can’t confirm.
  
  Apparently it is not available on 32 bit builds ; so this may or may not
  
  work correctly. On Intel, per the documentation there is only an
  
  intrinsic for _bit_scan_forward and people have posted on forums
  
  regarding _bit_scan_forward64, but often their documentation is
  
  woeful. Again, I don’t have it, so I can’t test.
  As such, to be safe, for now only the GCC/Clang intrinsic is added, the rest
  
  use a compiled version based on the De-Bruijn method of Leiserson et al :
  
  http://supertech.csail.mit.edu/papers/debruijn.pdf.
  Tested with FATE, sample benchmark (x86-64, GCC 5.2.0, Haswell)
  
  with a START_TIMER and STOP_TIMER in libavutil/rationsl.c, followed by a
  
  make fate.
  aac-am00_88.err :
  
  builtin :
  
  714 decicycles in av_gcd,    4095 runs,      1 skips
  de-bruijn :
  
  1440 decicycles in av_gcd,    4096 runs,      0 skips
  previous :
  
  2889 decicycles in av_gcd,    4096 runs,      0 skips
  Signed-off-by : Ganesh Ajjanagadde <gajjanagadde@gmail.com>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavutil/intmath.h
  • [DH] libavutil/mathematics.c