Recherche avancée

Sur d’autres sites (5252)

• Fluent-ffmpeg "not a suitable output format"

  5 septembre 2015, par J4G

  I’m using the fluent-ffmpeg module for Node.js to convert audio files. I have a .mp3 file that I’d like to convert to .wma

  Here’s what that looks like :

  var proc = new ffmpeg({
  
     source: 'file.mp3',
  
     nolog: false
  
  }).toFormat('wma')                                                
  
    .saveToFile('file.wma', function(stdout, stderr)
  
  {                                                 
  
      console.log(stderr);
  
  });

  Unfortunately, I get the error :

  Requested output format 'wma' is not a suitable output format

  This is the entire error log :

  ffmpeg version 0.8.9-4:0.8.9-0ubuntu0.12.04.1, Copyright (c) 2000-2013 the Libav developers
  
    built on Nov  9 2013 19:25:10 with gcc 4.6.3
  
  *** THIS PROGRAM IS DEPRECATED ***
  
  This program is only provided for compatibility and will be removed in a future release. Please use avconv instead.
  
  Input #0, mp3, from 'song_downloads/You Suffer.mp3':
  
    Metadata:
  
      title           : You Suffer
  
      artist          : Napalm Death
  
      album           : Scum
  
      genre           : Death Metal
  
      track           : 12
  
      date            : 1987
  
    Duration: 00:00:04.98, start: 0.000000, bitrate: 381 kb/s
  
      Stream #0.0: Audio: mp3, 44100 Hz, stereo, s16, 193 kb/s
  
  Requested output format 'wma' is not a suitable output format

  I know this isn’t an ffmpeg issue because

  ffmpeg -i file.mp3 file.wma

  Works fine. Any ideas ?

• Anomalie #3748 (Fermé) : La fonction recuperer_lapage est obsolète ; à remplacer par recuperer_url

  10 mars 2016

  Après la release de 3.1.1, en local et chez OVH, la détection de version de SPIP affichée en pied du backoffice ne fonctionnait plus.
  Je n’avais pas l’annonce "La mise à jour 3.1.1 de SPIP est disponible" même après lancement du genie mise_a_jour.

  En local mon /tmp/cache/xml/archives.xml restait vide

  Apparement le problème vient de :
  genie/mise_a_jour.php
  $res = recuperer_lapage($url, false, ’GET’, _COPIE_LOCALE_MAX_SIZE, ’’, false, $a) ;
  qui ne renvoie rien
  en remplacant par la fonction non obsolète
  $res = recuperer_url($url) ;
  on récupère bien l’archive et résout le bug

• Including objects to a shared library from a C++ archive (.a)

  1er septembre 2021, par El Sampsa

  I am trying to include some object files into a shared library I am building. Take the following command (things in [ETC] have been omitted for brevity) :

  



  


  /usr/bin/c++ -fPIC -std=c++14 -pthread -Iinclude/ext/liveMedia -Iinclude/ext/groupsock [ETC] -g -shared -Wl,-soname,libValkka.so -o lib/libValkka.so CMakeFiles/Valkka.dir/src/avthread.cpp.o CMakeFiles/Valkka.dir/src/opengl.cpp.o [ETC] CMakeFiles/Valkka.dir/src/decoders.cpp.o -lX11 -lGLEW -lGLU -lGL -Wl,—whole-archive lib/libavcodec.a -Wl,—no-whole-archive

  


  



  So basically I am just creating a shared library where most of the objects come from my own source code (i.e. CMakeFiles/Valkka.dir/src/*.o), but some of them come from an external static library, located at "lib/libavcodec.a". I get the following error :

  



  


  /usr/bin/ld : lib/libavcodec.a(h264_cabac.o) : relocation R_X86_64_PC32 against symbol 'ff_h264_cabac_tables' can not be used when making a shared object ; recompile with -fPIC
 /usr/bin/ld : final link failed : Bad value
 collect2 : error : ld returned 1 exit status

  


  



  But that is so untrue ! I can extract "libavcodec.a" with

  



  ar x libavcodec.a


  



  And after that check that

  



  readelf --relocs h264_cabac.o | egrep '(GOT|PLT|JU?MP_SLOT)' 


  



  does give some **it :

  



  


  00000000175d 003100000004 R_X86_64_PLT32 0000000000000000 __stack_chk_fail - 4
 000000001926 003100000004 R_X86_64_PLT32 0000000000000000 __stack_chk_fail - 4

  
 


  ...

  


  



  As does

  



  objdump -r h264_cabac.o | grep -i "relocation"


  



  So, indeed, the object files in "libavcodec.a" have been compiled to get PIC (position independent code).

  



  Why does the linker believe otherwise !?

  



  Related links :

  



  How to include all objects of an archive in a shared object ?

  



  Linking archives (.a) into shared object (.so)

  



  Is there a way to determine that a .a or .so library has been compiled as position indepenent code ?

  



  How can I tell, with something like objdump, if an object file has been built with -fPIC ?