Recherche avancée

Médias (91)

Autres articles (99)

  • Mise à jour de la version 0.1 vers 0.2

    24 juin 2013, par

    Explications des différents changements notables lors du passage de la version 0.1 de MediaSPIP à la version 0.3. Quelles sont les nouveautés
    Au niveau des dépendances logicielles Utilisation des dernières versions de FFMpeg (>= v1.2.1) ; Installation des dépendances pour Smush ; Installation de MediaInfo et FFprobe pour la récupération des métadonnées ; On n’utilise plus ffmpeg2theora ; On n’installe plus flvtool2 au profit de flvtool++ ; On n’installe plus ffmpeg-php qui n’est plus maintenu au (...)

  • Personnaliser en ajoutant son logo, sa bannière ou son image de fond

    5 septembre 2013, par

    Certains thèmes prennent en compte trois éléments de personnalisation : l’ajout d’un logo ; l’ajout d’une bannière l’ajout d’une image de fond ;

  • Multilang : améliorer l’interface pour les blocs multilingues

    18 février 2011, par

    Multilang est un plugin supplémentaire qui n’est pas activé par défaut lors de l’initialisation de MediaSPIP.
    Après son activation, une préconfiguration est mise en place automatiquement par MediaSPIP init permettant à la nouvelle fonctionnalité d’être automatiquement opérationnelle. Il n’est donc pas obligatoire de passer par une étape de configuration pour cela.

Sur d’autres sites (9543)

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

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