Recherche avancée

Sur d’autres sites (5487)

• FFmpeg Has A Native VP8 Decoder

  24 juin 2010, par Multimedia Mike — VP8

  Thanks to David Conrad and Ronald Bultje who committed their native VP8 video decoder to the FFmpeg codebase yesterday. At this point, it can decode 14/17 of the VP8 test vectors that Google released during the initial open sourcing event. Work is ongoing on those 3 non-passing samples (missing bilinear filter). Meanwhile, FFmpeg’s optimization-obsessive personalities are hard at work optimizing the native decoder. The current decoder is already profiled to be faster than Google/On2’s official libvpx.

  Testing
  So it falls to FATE to test this on the ridiculous diversity of platforms that FFmpeg supports. I staged individual test specs for each of the 17 test vectors : vp8-test-vector-001 ... vp8-test-vector-017. After the samples have propagated through to the various FATE installations, I’ll activate the 14 test specs that are currently passing.

  Initial Testing Methodology
  Inspired by Ronald Bultje’s idea, I built the latest FFmpeg-SVN with libvpx enabled. Then I selected between the reference and native decoders as such :

  $ for i in 001 002 003 004 005 006 007 008 009 \
   010 011 012 013 014 015 016 017
  do
    echo vp80-00-comprehensive-$i.ivf
    ffmpeg -vcodec libvpx -i \
      /path/to/vp8-test-vectors-r1/vp80-00-comprehensive-$i.ivf \
      -f framemd5 - 2> /dev/null
  done > refs.txt
  $ for i in 001 002 003 004 005 006 007 008 009 \
  
   010 011 012 013 014 015 016 017
  
  do
  
    echo vp80-00-comprehensive-$i.ivf
  
    ffmpeg -vcodec vp8 -i \
  
      /path/to/vp8-test-vectors-r1/vp80-00-comprehensive-$i.ivf \
  
      -f framemd5 - 2> /dev/null
  
  done > native.txt
  $ diff -u refs.txt native.txt
  

  That reveals precisely which files differ.

• x264 configure linking and building problems

  16 janvier 2014, par Pie

  I am trying to build x264 from source on Ubuntu 32bit in order to convert a sequence of jpg or png images into mp4 video : x264 site, sample images

  The downloaded binaries is able to convert the sequence into an mkv video (or few other formats) when I run this command :

  ./x264dist ~/Dev/x264emp/img/FLYOVER%4d.JPG -o abc.mkv

  x264dist is the renamed name of the binary I download from the site.

  However, when I grab the source and compile with simple configure :

  $ ./configure --enable-shared --enable-static --enable-pic

  platform:      X86
  
  system:        LINUX
  
  cli:           yes
  
  libx264:       internal
  
  shared:        yes
  
  static:        yes
  
  asm:           yes
  
  interlaced:    yes
  
  avs:           avxsynth
  
  lavf:          no
  
  ffms:          no
  
  mp4:           no
  
  gpl:           yes
  
  thread:        posix
  
  opencl:        yes
  
  filters:       crop select_every 
  
  debug:         no
  
  gprof:         no
  
  strip:         no
  
  PIC:           yes
  
  bit depth:     8
  
  chroma format: all

  then $ make. Then I use the binaries to run the exactly same command as above but there is this error :

  ./x264 ~/Dev/x264emp/img/FLYOVER%4d.JPG -o abc.mkv
  
  raw [error]: raw input requires a resolution.
  
  x264 [error]: could not open input file `/home/tmd/Dev/x264emp/img/FLYOVER%4d.JPG' via any method!

  It seems like it can’t read any input at all. But at least I am still able to run --help on that binaries.

  Then I realized that the downloaded binaries is 3.5Mb while my custom compilation results in 1.5Mb binaries.

  So I just want to know what are the build configurations used by the official build, and/or is there any dependency I am missing that leads to this problem.

  The reason I am trying to build myself because I want to port the x264 lib into Javascript using Emscripten. There has been a solution using FFmpeg but it seems like I don’t need the whole video processing library but only a simple H264 codec. So I need to solve the configure/compile/linking problem to port it rightly.

  Possibly similar How to configure X264 build before running make on OS X

• NDK r8c warning for asm objects regarding "Cortex-A8 erratum" - should I be worried ?

  7 décembre 2012, par Alex Cohn

  Question : What is the meaning of this warning ? If there are no real-life consequences, I can live with it for a while... But I am concerned with what will happen if our program gets loaded on one of the faulty chips.

  Background : With NDK r8c, linking of X264 encoder issues warnings :

  cannot scan executable section 1 of libx264.a(dct-a.o) for Cortex-A8 erratum because it has no mapping symbols

  ... same warning for all assembly files in libx264.

  libx264.a itself was cross-compiled on the same machine with the same 4.6 toolchain taken from NDK.

  Here are the instructions to easily reproduce the problem (Ubuntu or MacOS) :

  1. Download x264-snapshot-20121203-2245 from ftp://ftp.videolan.org/pub/x264/snapshots/last_x264.tar.bz2

  2. Run ./configure --enable-pic --enable-strip --enable-static --cross-prefix=~/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi- --sysroot=~/android-ndk-r8c/platforms/android-14/arch-arm --host=arm-linux

  3. Run ~/android-ndk-r8c/prebuilt/linux-x86/bin/make

  It will build the static library, and after that display the Cortex-A8 warning while linking the x265 executable. I am not worried about the compiler warnings, because building libx264.a is done offline, it is not part of our official daily build.

  I have reported this as http://code.google.com/p/android/issues/detail?id=40794.

  I tried to add the mapping symbols manually to dct-a.S following the ARM.com instructions, but this had no effect.