Recherche avancée

Sur d’autres sites (8903)

• huffyuvdec : remove somewhat deprecated code

  15 juin 2014, par Christophe Gisquet

  huffyuvdec : remove somewhat deprecated code
  The old code was reserving the 0xFFFF entry to represent an inexisting
  
  entry/codeword. These entries are now detected through their length
  
  being <= 0. As this entry is often used for the residuals (-1,-1), which
  
  should be among the most frequent, it is particularly important to not
  
  reserve it.
  Signed-off-by : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] libavcodec/huffyuvdec.c

• lavu/riscv : indent code

  18 novembre 2023, par Rémi Denis-Courmont

  lavu/riscv : indent code
  This reindents code to prepare for the next changeset.
  
  No functional changes.
  

  • [DH] libavutil/riscv/cpu.c

• building c++ code into a shared library

  11 avril 2016, par gaurav

  I have some c++ code which i use as shared library in a java application.My c++ code uses some libraries like ffmpeg and boost. and ffmpeg libraries in turn depend on libx264. my first question is - can i build my c++ into a "fat" shared library which contains all the symbols from all libraries used so that on a new machine if i just copy the fat .so file everything works.
  If thats not possible then can you help me fix my current build process. This is what i am doing currently -

  1)on a local VM(ubuntu 64) i compile ffmpeg code using -fPIC flag and install h264 and boost using apt-get commands.
  2) on the same VM i compile my code using make file which looks like this-

  INCLUDES =   -I/opt/ffmpeg/include -I/usr/lib/jvm/java-7-openjdk-   amd64/include -I/usr/lib/jvm/java-7-openjdk-amd64/include/linux
  
  
  
  LDFLAGS =   -L/home/ubuntu/ffmpeg_shared
  
  
  
  LIBRARIES = -lavformat -lavcodec -lswscale -lavutil -lpthread  -lx264 -lboost_system -lboost_thread -lboost_chrono 
  
  
  
  CC = g++ -std=c++11 -fPIC
  
  
  
  all:clean final
  
  
  
  final:Api.o ImageSequence.o OverlayAnimation.o Utils.o ImageFrame.o 
  
  $(CC)  -o final.so Api.o ImageSequence.o OverlayAnimation.o Utils.o  ImageFrame.o $(LDFLAGS) $(LIBRARIES) -shared 

  3) on a new machine where java app will run. i install h264 and boost using apt-get commands and copy ffmpeg’s compiled library files to /usr/local/lib.

  4) copy the final.so file to this new machine. but when the java code tries to use the final.so file i see it tries to use wierdly named files. for example - it tries to find libavcodec.so.57 , libavformat.so.57 etc. to fix this i just created a copy of these files ie libavcodec.so copied to libavcodec.so.57.

  5)But these ffmpeg libraries in turn uses a differently named lib264.so file. on my new machine the apt-get command for x264 installed a file named libx264.so.148 but one of ffmpeg libraries is searching for file libx264.so.142 even if i rename this libx264.so file i get new errors where ffmpeg libraries tries to call libx264’s methods which has these numbers attached.

  6) at this time the only working option for me is to bring the c++ code on every new machine and build final.so file locally. this is something i want to avoid since i want to distribute the .so file along with jar file to my clients which they can easily use without having to build and install stuff.