Recherche avancée

Sur d’autres sites (7416)

• ARM compiler shoot-out, round 2

       
  20 août 2009, par Mans — ARM, Compilers

  In my recent test of ARM compilers, I had to leave out Texas Instrument’s compiler since it failed to build FFmpeg. Since then, the TI compiler team has been busy fixing bugs, and a snapshot I was given to test was able to build enough of a somewhat patched FFmpeg that I can now present round two in this shoot-out.

  The contenders this time were the fastest GCC variant from round one, ARM RVCT, and newcomer TI TMS470. With the same rules as last time, the exact versions and optimisation options were like this :

  • CodeSourcery GCC 2009q1 (based on 4.3.3), -mfpu=neon -mfloat-abi=softfp -mcpu=cortex-a8 -std=c99 -fomit-frame-pointer -O3 -fno-math-errno -fno-signed-zeros -fno-tree-vectorize
  • ARM RVCT 4.0 Build 591, -mfpu=neon -mfloat-abi=softfp -mcpu=cortex-a8 -std=c99 -fomit-frame-pointer -O3 -fno-math-errno -fno-signed-zeros
  • TI TMS470 4.7.0-a9229, --float_support=vfpv3 -mv=7a8 -O3 -mf=5

  
  To keep things fair, I left the vectoriser off also with the TI compiler. The table below lists the decoding times for the sample files, this time normalised against the participating GCC compiler. Remember, smaller numbers are better. Also keep in mind that this test was done with a development snapshot of TMS470, not an approved release.

  Sample name	Codec	Code type	GCC	RVCT	TI
  cathedral	H.264 CABAC	integer	1.00	0.95	1.02
  NeroAVC	H.264 CABAC	integer	1.00	0.96	1.05
  indiana_jones_4	H.264 CAVLC	integer	1.00	0.92	1.02
  NeroRecodeSample	MPEG-4 ASP	integer	1.00	1.01	1.08
  Silent_Light	MP3	64-bit integer	1.00	0.48	0.72
  When_I_Grow_Up	FLAC	integer	1.00	0.87	0.93
  Lumme-Badloop	Vorbis	float	1.00	0.94	1.05
  Canyon	AC-3	float	1.00	0.88	1.01
  lotr	DTS	float	1.00	1.00	1.08

  Overall, the TI TMS470 compiler comes off slightly worse than GCC. In two cases, however, it was significantly better than GCC, but not as good as RVCT. Incidentally, those were also the ones where RVCT scored the biggest win over GCC.

  My conclusions from this test are twofold :

  • ARM’s own compiler is very hard to beat. They do seem to know how their chips work.
  • GCC is incredibly bad at 64-bit arithmetic on 32-bit machines.

  The logical next step is to test these compilers with vectorisation enabled. FFmpeg should offer plenty of opportunities for this feature to shine. Unfortunately, that test will have to wait until the RVCT vectoriser is fixed. The current release does not compile FFmpeg with vectorisation enabled.

• Cross-compiling for ffmpeg : libvpx decoder version must be >=0.9.1

  13 octobre 2016, par bot1131357

  (Note : I know the title is almost identical to this question, but its solution is only applicable if I were building on my own system. I am building for an embedded ARM device.)

  I am trying to build a cross-compile FFmpeg library to be targeted on an arm device, and the ./configure command tells me that libvpx is outdated.

  My version of libvpx is as follows :

  $ pkg-config --modversion vorbis 
  
  1.3.2

  When I run ./configure

  $ ./configure --prefix=/home/test/Dev/build-arm/ffmpeg-armhf/ --enable-cross-compile --cross-prefix=${CCPREFIX} --arch=armhf --target-os=linux --pkg-config-flags="--libs vpx --static --cflags" --enable-shared --enable-libvpx 
  
  ERROR: libvpx decoder version must be >=0.9.1
  
  
  
  If you think configure made a mistake, make sure you are using the latest
  
  version from Git.  If the latest version fails, report the problem to the
  
  ffmpeg-user@ffmpeg.org mailing list or IRC #ffmpeg on irc.freenode.net.
  
  Include the log file "config.log" produced by configure as this will help
  
  solve the problem.

  My vpx.pc file is located in /usr/share/pkgconfig. Since it’s for a different target (arm), Should I be putting this file somewhere else ? :

  # pkg-config file from libvpx v1.6.0-322-gc325fb7
  
  prefix=/home/test/Dev/build-arm/libvpx
  
  exec_prefix=${prefix}
  
  libdir=${prefix}/lib
  
  includedir=${prefix}/include
  
  
  
  Name: vpx
  
  Description: WebM Project VPx codec implementation
  
  Version: 1.6.0
  
  Requires:
  
  Conflicts:
  
  Libs: -L${libdir} -lvpx -lm
  
  Libs.private: -lm -lpthread
  
  Cflags: -I${includedir}

  In my config.log I see this :

  (...lots of text...)
  
  arm-openwrt-linux-gnueabi-gcc -Werror=missing-prototypes -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -march=armv7-a -std=c99 -fomit-frame-pointer -marm -fPIC -pthread -c -o /tmp/ffconf.cZcBLWc3.o /tmp/ffconf.sWjTIULb.m
  
  arm-openwrt-linux-gnueabi-gcc: /tmp/ffconf.sWjTIULb.m: Objective-C compiler not installed on this system
  
  check_pkg_config vpx >= 0.9.1 vpx/vpx_decoder.h vpx/vp8dx.h vpx_codec_vp8_dx
  
  false --exists --print-errors vpx >= 0.9.1
  
  check_lib2 vpx/vpx_decoder.h vpx/vp8dx.h vpx_codec_dec_init_ver -lvpx
  
  check_func_headers vpx/vpx_decoder.h vpx/vp8dx.h vpx_codec_dec_init_ver -lvpx
  
  check_ld cc -lvpx
  
  check_cc
  
  BEGIN /tmp/ffconf.gM9G9FSQ.c
  
      1   #include <vpx></vpx>vpx_decoder.h>
  
      2   #include <vpx></vpx>vp8dx.h>
  
      3   long check_vpx_codec_dec_init_ver(void) { return (long) vpx_codec_dec_init_ver; }
  
      4   int main(void) { return 0; }
  
  END /tmp/ffconf.gM9G9FSQ.c
  
  arm-openwrt-linux-gnueabi-gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -march=armv7-a -std=c99 -fomit-frame-pointer -marm -fPIC -pthread -c -o /tmp/ffconf.cZcBLWc3.o /tmp/ffconf.gM9G9FSQ.c
  
  /tmp/ffconf.gM9G9FSQ.c:1:29: fatal error: vpx/vpx_decoder.h: No such file or directory
  
  compilation terminated.
  
  ERROR: libvpx decoder version must be >=0.9.1

  It looks like the include and library paths are not provided to the compiler, but I don’t know how I should go around solving that.
  I would really appreciate it if you could offer some guidance.

• Why I became a HTML5 co-editor

  15 août 2012, par silvia

  A few weeks ago, I had the honor to be appointed as part of the editorial team of the W3C HTML5 specification.

  Since Ian Hickson had recently decided to focus solely on editing the WHATWG HTML living standard specification, the W3C started looking for other editors to take the existing HTML5 specification to REC level. REC level is what other standards organizations call a “ratified standard”.

  But what does REC level really mean for HTML ?

  In my probably somewhat subjective view, recommendation level means that a snapshot is taken of the continuously evolving HTML spec, which has a comprehensive feature set, that is implemented in a cross-browser interoperable way, has a complete test set for the features, and has received wide review. The latter implies that other groups in the W3C have had a chance to look at the specification and make sure it satisfies their basic requirements, which include e.g. applicability to all users (accessibility, internationalization), platforms, and devices (mobile, TV).

  Basically it means that we stop for a “moment”, take a deep breath, polish the feature set that we’ve been working on this far, and make sure we all agree on it, before we get back to changing the world with cool new stuff. In a software project we would call it a release branch with feature freeze.

  Now, as productive as that may sound for software – it’s not actually that exciting for a specification. Firstly, the most exciting things happen when writing new features. Secondly, development of browsers doesn’t just magically stop to get the release (REC) happening. And lastly, if we’ve done our specification work well, there should be only little work to do. Basically, it’s the unthankful work of tidying up that we’re looking at here.

  So, why am I doing it ? I am not doing this for money – I’m currently part-time contracting to Google’s accessibility team working on video accessibility and this editor work is not covered by my contract. It wasn’t possible to reconcile polishing work on a specification with the goals of my contract, which include pushing new accessibility features forward. Therefore, when invited, I decided to offer my spare time to the W3C.

  I’m giving this time under the condition that I’d only be looking at accessibility and video related sections. This is where my interest and expertise lie, and where I’m passionate to get things right. I want to make sure that we create accessibility features that will be implemented and that we polish existing video features. I want to make sure we don’t digress from implementations which continue to get updated and may follow the WHATWG spec or HTML.next or other needs.

  I am not yet completely sure what the editorship will entail. Will we look at tests, too ? Will we get involved in HTML.next ? This far we’ve been preparing for our work by setting up adequate version control repositories, building a spec creation process, discussing how to bridge to the WHATWG commits, and analysing the long list of bugs to see how to cope with them. There’s plenty of actual text editing work ahead and the team is shaping up well ! I look forward to the new experiences.