Recherche avancée

Sur d’autres sites (14930)

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

  


• Audio drift issue. Creating video frames programmatically and syncing with midi/audio in java

  6 septembre 2017, par user6688986

  I want to create a video that changes to the notes on a midi file. I am recording the midi then outputting it as wav.

  In java I read the midi file, create images based on the notes played. I am calculating the time between notes and using this to determine the number of frames with this code :

      for(int i = 0; i < noteImages.size(); i++) {
  
          for(int j = 0; j < frameRate * (noteLengths.get(i) / 1000); j++) {
  
              videoFrames.add(noteImages.get(i));
  
              frameCount++;
  
          }
  
      }

  I then use ffmpeg to create the video from the images with audio using this command :

  ffmpeg -r 60 -f image2 -i pic%05d.png -itsoffset 3 -i audio.wav -c:v libx264 -c:a aac -pix_fmt yuv420p -crf 23 -r 24 -shortest -y output.mp4 

  The audio starts okay then gradually goes out of sync. If I use higher fps when creating the images it is less pronounced, but I need to use at least 300fps to get it close and it is still not quite right. Any ideas on how to correct this ?

• avformat/concatdec : add fallback for calculating file duration

  29 août 2017, par Justin Ruggles

  avformat/concatdec : add fallback for calculating file duration
  If a file does not have a known duration, this leads to the timestamps
  
  starting over for the next file, causing non-monotonic timestamps.
  
  To prevent this, track the duration during demuxing and use it to
  
  determine the current file duration before opening the next file.
  Signed-off-by : Derek Buitenhuis <derek.buitenhuis@gmail.com>
  

  • [DH] libavformat/concatdec.c