Recherche avancée

Médias (91)

Autres articles (51)

  • Publier sur MédiaSpip

    13 juin 2013

    Puis-je poster des contenus à partir d’une tablette Ipad ?
    Oui, si votre Médiaspip installé est à la version 0.2 ou supérieure. Contacter au besoin l’administrateur de votre MédiaSpip pour le savoir

  • Les autorisations surchargées par les plugins

    27 avril 2010, par

    Mediaspip core
    autoriser_auteur_modifier() afin que les visiteurs soient capables de modifier leurs informations sur la page d’auteurs

  • D’autres logiciels intéressants

    12 avril 2011, par

    On ne revendique pas d’être les seuls à faire ce que l’on fait ... et on ne revendique surtout pas d’être les meilleurs non plus ... Ce que l’on fait, on essaie juste de le faire bien, et de mieux en mieux...
    La liste suivante correspond à des logiciels qui tendent peu ou prou à faire comme MediaSPIP ou que MediaSPIP tente peu ou prou à faire pareil, peu importe ...
    On ne les connais pas, on ne les a pas essayé, mais vous pouvez peut être y jeter un coup d’oeil.
    Videopress
    Site Internet : (...)

Sur d’autres sites (7490)

  • How to integrate shared object file of libx264 while using ffmpeg for android ?

    5 août 2014, par user3665376

    I am working with integrating ffmpeg for android .

    Since I needed H.264 encoding I need to integrate libx264 with ffmpeg . Given below are the steps I followed .

    1) Build the latest libx264 using android compiler tool-chain to obtain libx264.so.142 .

    2) Build ffmpeg v 2.3 referring to this with —enable -libx264 option while configuring ffmpeg . The method explained in the blog included some editing in configure file of ffmpeg to generate shared object files with extension format [lib name].so rather than the generating shared object file with extension format [lib name].so.[version] (Since android build system supports files with extension .so only).

    The building process was successful but since the generated .so files (after building ffmpeg) has dynamic dependency with libx264.so.142,I need to package libx264.so.142 also with the android .apk file . But since the above format (.so.142) is not supported with android apk building system I cannot package it with the .apk .

    So I think the only option I have is to make some changes in configure file of ffmpeg to change the dynamic dependency of libx264.so.142 to libx264.so . Am I right ??

    What changes do I need to make to ffmpeg configure file to achieve this ?

  • How to integrate shared object file of libx264 while using ffmpeg for android ?

    5 août 2014, par user3665376

    I am working with integrating ffmpeg for android .

    Since I needed H.264 encoding I need to integrate libx264 with ffmpeg . Given below are the steps I followed .

    1) Build the latest libx264 using android compiler tool-chain to obtain libx264.so.142 .

    2) Build ffmpeg v 2.3 referring to this with —enable -libx264 option while configuring ffmpeg . The method explained in the blog included some editing in configure file of ffmpeg to generate shared object files with extension format [lib name].so rather than the generating shared object file with extension format [lib name].so.[version] (Since android build system supports files with extension .so only).

    The building process was successful but since the generated .so files (after building ffmpeg) has dynamic dependency with libx264.so.142,I need to package libx264.so.142 also with the android .apk file . But since the above format (.so.142) is not supported with android apk building system I cannot package it with the .apk .

    So I think the only option I have is to make some changes in configure file of ffmpeg to change the dynamic dependency of libx264.so.142 to libx264.so . Am I right ??

    What changes do I need to make to ffmpeg configure file to achieve this ?

  • x86 : h264 : Don’t keep data in the redzone across function calls on 64 bit unix

    20 février 2012, par Martin Storsjö
    x86 : h264 : Don’t keep data in the redzone across function calls on 64 bit unix

    We know that the called function (ff_chroma_inter_body_mmxext)
    
doesn’t touch the redzone, and thus will be kept intact - thus,
    
this doesn’t fix any bug per se.
    

    However, valgrind’s memcheck tool intentionally assumes that the
    
redzone is clobbered on every function call and function return
    
(see a long comment in valgrind/memcheck/mc_main.c). This avoids
    
false positives in that tool, at the cost of an extra stack pointer
    
adjustment.
    

    The other alternative would be a valgrind suppression for this issue,
    
but that’s an extra burden for everybody that wants to run libavcodec
    
within valgrind.
    

    Signed-off-by : Martin Storsjö <martin@martin.st>
    • [DBH] libavcodec/x86/h264_deblock.asm

Navigation