Recherche avancée

Sur d’autres sites (6992)

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

• ARM compiler update

  15 janvier 2010, par Mans — ARM, Compilers

  Since my last shootout, all the tested vendors have updated their compilers. Here is a quick update on each of them.

  Both the 4.3 and 4.4 branches of FSF GCC have had bugfix releases, bringing them to 4.3.4 and 4.4.2, respectively. Neither update contains anything particularly noteworthy.

  The CodeSourcery 2009q3 release sees an update to a GCC 4.4 base, a significant change from the 4.3 base used in 2009q1. The update is a mixed blessing. In fact, it is mostly a curse and hardly a blessing at all. On the bright side, the floating-point speed regressions in 2009q1 are gone, 2009q3 being a few per cent faster even than 2007q3. Unfortunately, this improvement is completely overshadowed by a major speed regression on integer code, a whopping 24% in one case. This ties in with the slowdown previously observed with FSF GCC 4.4 compared to 4.3.

  ARM RVCT 4.0 is now at Build 697. This update fixes some bugs and introduces others. Notably, it no longer builds FFmpeg correctly. The issue has been reported to ARM.

  Texas Instruments, finally, have made a formal release, v4.6.1, of their TMS470 compiler incorporating various fixes allowing it to build a moderately patched FFmpeg. The performance remains somewhere between GCC and RVCT on average.

  In light of the above, my recommendations remain unchanged :

  • For a free compiler, choose CodeSourcery 2009q1. It beats GCC 4.3.4 by 5-10% in most cases.
  • GNU purists are best served by GCC 4.3.4, which is up to 20% faster than 4.4.2 and rarely slower.
  • When price is not a concern, ARM RCVT is a good option, outperforming GCC by up to a factor 2.
  • In all cases, disable any auto-vectorisation features.

  Regardless of which compiler is chosen, I cannot overstress the importance of testing. All compilers are crawling with bugs, and even the most innocent-looking code change can trigger one of them. When using a compiler other than GCC, extra caution is advised considering a lot of code is developed using only GCC and may thus fall prey to bugs unique to said other compiler.

• JavaCV RedHat Linux 6.6 x64 NoClassDefFound : Could not initialize class org.bytedeco.javacpp.avutil

  28 novembre 2015, par ChrisGeo

  I want to run a simple .flv to .mp4 conversion on a Linux machine

  Till now I was including the following dependencies and it was working fine on Ubuntu 12.x and CentOS

  <dependency>
  
     <groupid>org.bytedeco.javacpp-presets</groupid>
  
     <artifactid>ffmpeg</artifactid>
  
     <version>2.7.1-1.0</version>
  
     <classifier>linux-x86_64</classifier>
  
  </dependency>

  Red Hat uname -a

  x86_64 #1 SMP Tue Sep 16 01:56:35 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux
  
  
  
  Red Hat lsb_release -a
  
  LSB Version:    :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
  
  Distributor ID: RedHatEnterpriseServer
  
  Description:    Red Hat Enterprise Linux Server release 6.6 (Santiago)
  
  Release:        6.6
  
  Codename:       Santiago

  CentOS uname -a

  .x86_64 #1 SMP Tue Nov 3 19:10:07 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

  However when trying it in RedHat Linux I get the following exceptions

  Application startup failed

  java.lang.NoClassDefFoundError: Could not initialize class org.bytedeco.javacpp.avutil
  
      at java.lang.Class.forName0(Native Method)
  
      at java.lang.Class.forName(Class.java:270)
  
      at org.bytedeco.javacpp.Loader.load(Loader.java:390)
  
      at org.bytedeco.javacpp.Loader.load(Loader.java:358)
  
      at org.bytedeco.javacpp.avformat$AVFormatContext.<clinit>(avformat.java:2539)
  
      at org.bytedeco.javacv.FFmpegFrameGrabber.startUnsafe(FFmpegFrameGrabber.java:383)
  
      at org.bytedeco.javacv.FFmpegFrameGrabber.start(FFmpegFrameGrabber.java:377)
  
      at com.example.Application.convert(Application.java:53)
  
      at com.example.Application.run(Application.java:103)
  
      at org.springframework.boot.SpringApplication.runCommandLineRunners(SpringApplication.java:674)
  
      at org.springframework.boot.SpringApplication.afterRefresh(SpringApplication.java:693)
  
      at org.springframework.boot.SpringApplication.run(SpringApplication.java:322)
  
      at org.springframework.boot.SpringApplication.run(SpringApplication.java:969)
  
      at org.springframework.boot.SpringApplication.run(SpringApplication.java:958)
  
      at com.example.Application.main(Application.java:28)
  
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
  
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  
      at java.lang.reflect.Method.invoke(Method.java:606)
  
      at org.springframework.boot.loader.MainMethodRunner.run(MainMethodRunner.java:53)
  
      at java.lang.Thread.run(Thread.java:745)
  
  </clinit>

  I tried with 32 bit version :

  <dependency>
  
     <groupid>org.bytedeco.javacpp-presets</groupid>
  
     <artifactid>ffmpeg</artifactid>
  
     <version>2.7.1-1.0</version>
  
     <classifier>linux-x86</classifier>
  
  </dependency>

  Same result.

  Then I tried with simply

  org.bytedeco
  javacv
  1.0

  and mvn package -Dplatform.dependencies=true so I got ALL dependencies.

  Still the same. Any one have an idea what I’m doing wrong ?