Recherche avancée

Médias (91)

Autres articles (49)

  • Installation en mode ferme

    4 février 2011, par

    Le mode ferme permet d’héberger plusieurs sites de type MediaSPIP en n’installant qu’une seule fois son noyau fonctionnel.
    C’est la méthode que nous utilisons sur cette même plateforme.
    L’utilisation en mode ferme nécessite de connaïtre un peu le mécanisme de SPIP contrairement à la version standalone qui ne nécessite pas réellement de connaissances spécifique puisque l’espace privé habituel de SPIP n’est plus utilisé.
    Dans un premier temps, vous devez avoir installé les mêmes fichiers que l’installation (...)

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

  • Le plugin : Gestion de la mutualisation

    2 mars 2010, par

    Le plugin de Gestion de mutualisation permet de gérer les différents canaux de mediaspip depuis un site maître. Il a pour but de fournir une solution pure SPIP afin de remplacer cette ancienne solution.
    Installation basique
    On installe les fichiers de SPIP sur le serveur.
    On ajoute ensuite le plugin "mutualisation" à la racine du site comme décrit ici.
    On customise le fichier mes_options.php central comme on le souhaite. Voilà pour l’exemple celui de la plateforme mediaspip.net :
    < ?php (...)

Sur d’autres sites (4355)

  • Compiling x264 on a Mac : "No working C compiler found" and "arm-linux-androideabi-gcc : command not found"

    29 novembre 2014, par Xavi Gil

    I am trying to compile the x264 library for Android, following this post.

    I have cloned the x264 project git clone git://git.videolan.org/x264.git and tried to compile with the following configuration :

    NDK=~/development/android-ndk-r10c    
    
TOOLCHAIN=$NDK/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86_64
    
PLATFORM=$NDK/platforms/android-21/arch-arm
    

    
./configure \
    
--cross-prefix=$TOOLCHAIN/bin/arm-linux-androideabi- \
    
--sysroot=$PLATFORM \
    
--host=arm-linux \
    
--enable-pic \
    
--enable-static \
    
--disable-cli

    The problem is that I get a No working C compiler found. error.

    The conftest.log output :

    $ cat conftest.log 
    
./configure: line 153: arm-linux-androideabi-gcc: command not found

    But the arm-linux-androideabi-gcc is the toolchain’s bin folder !!

    Looking at this other question it looks like for some reason, even though the file exists, since it is a 64bit Mac, it won’t execute the arm-linux-androideabi-gcc file and will return this weird error and log.

    I am in a Mac OS X 10.10 and I have installed the XCode Command Line Tools :

    $ xcode-select -p
    
/Applications/Xcode.app/Contents/Developer

    GCC version :

    $ gcc --version
    
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
    
Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
    
Target: x86_64-apple-darwin14.0.0
    
Thread model: posix

    Can anyone tell me how to fix this please ?

  • lavc/libopenjpegenc : move opj_create_compress, opj_cio_open and opj_set_event_mgr...

    2 février 2015, par Jean First
    lavc/libopenjpegenc : move opj_create_compress, opj_cio_open and opj_set_event_mgr to libopenjpeg_encode_frame

     libopenjpegenc crashes with "pointer being freed was not allocated" when threading
    
 is enabled with :
    
 ffmpeg -i tests/vsynth1/01.pgm -vcodec libopenjpeg file.j2k
    
 this appears to be a bug in libopenjpeg
    

    Signed-off-by : Michael Niedermayer <michaelni@gmx.at>
    • [DH] libavcodec/libopenjpegenc.c

  • mov : Implement parsing of the "HandlerName" from the MP4 HDLR atom

    3 février 2015, par Hendrik Leppkes
    mov : Implement parsing of the "HandlerName" from the MP4 HDLR atom

    This atom typically is used for a track title. The handler name is stored
    
as a Pascal string in the QT specs (first byte is the length of the string),
    
so do not export it.
    

    A second length check based on the first character is added to avoid
    
overwriting an already specified handler_name (it happens with YouTube
    
videos for instance, the handler_name get masked), or specifying an
    
empty string metadata.
    

    The Pascal string fix and the second length check are written
    
by Clément Bœsch <clement.boesch@smartjog.com>.
    

    Signed-off-by : Vittorio Giovara <vittorio.giovara@gmail.com>
    
Signed-off-by : Luca Barbato <lu_zero@gentoo.org>
    • [DBH] libavformat/mov.c

Navigation