Recherche avancée

Médias (0)

Mot : - Tags -/xmlrpc

Aucun média correspondant à vos critères n’est disponible sur le site.

Autres articles (55)

  • Other interesting software

    13 avril 2011, par

    We don’t claim to be the only ones doing what we do ... and especially not to assert claims to be the best either ... What we do, we just try to do it well and getting better ...
    The following list represents softwares that tend to be more or less as MediaSPIP or that MediaSPIP tries more or less to do the same, whatever ...
    We don’t know them, we didn’t try them, but you can take a peek.
    Videopress
    Website : http://videopress.com/
    License : GNU/GPL v2
    Source code : (...)

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

  • 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

Sur d’autres sites (8257)

  • FFmpeg insufficient thread locking only when deploying application using homebrew

    20 décembre 2012, par Kikohs

    I have the strangest bug of my life.
    I have installed ffmpeg using homebrew. I use it from a dll.
    I have set a lock manager because I use ffmpeg from multiple threads.

    In Engine.h :

    class EXPORT_LIB Engine
    {
    public:
       static int initEngine();    
       static int closeEngine();
    };

    In Engine.cpp :

    static int ff_lockmgr(void **mutex, enum AVLockOp op)
    {
    if (NULL == mutex)
       return -1;

    switch(op)
    {
    case AV_LOCK_CREATE:
    {
       *mutex = NULL;
       boost::mutex * m = new boost::mutex();
       *mutex = static_cast(m);
       break;
    }
    case AV_LOCK_OBTAIN:
    {
       boost::mutex * m =  static_cast(*mutex);
       m->lock();
       break;
    }
    case AV_LOCK_RELEASE:
    {
       boost::mutex * m = static_cast(*mutex);
       m->unlock();
       break;
    }
    case AV_LOCK_DESTROY:
    {
       boost::mutex * m = static_cast(*mutex);
       delete m;
       break;
    }
    default:
       break;
    }
    return 0;
    }


    int Engine::initEngine()
    {
       int res = -1;
       res = av_lockmgr_register(&ff_lockmgr);
       av_register_all();
       av_log_set_level(AV_LOG_QUIET); // ERROR, PANIC
       // Av lock manager success
       if( res == 0 ) {
           res = MULTITHREAD;
       }
       else {
           res = SINGLETHREAD;
       }
       return res;
    }

    int Engine::closeEngine()
    {
       int res = 0;
       res = av_lockmgr_register(NULL);
       return res;
    }

    So far so good, everything works as expected.

    When I deploy my app using CMake fix_bundle. I have an error message

    insufficient thread locking around avcodec_open/close()

    If I compile ffmpeg by hand in a custom location, when I deploy the app everything works as expected. What is wrong with homebrew ?

  • The same FFmpeg commands run fast on the command line and slow in Flutter, how to Debug ?

    3 septembre 2024, par QIAOMO

    It's a simple task to watermark an image :

    


    ffmpeg -hide_banner -y -i image.AVIF -i watermark.png -filter_complex "overlay=(main_w-overlay_w-50):(main_h-overlay_h-50)" output.AVIF


    


    It takes almost seconds on the command line, but half a minute in Flutter.

    


    await Process.run('ffmpeg', [
    '-hide_banner',
    '-y',
    '-i',
    'image.AVIF',
    '-i',
    'watermark.png',
    '-filter_complex',
    'overlay=(main_w-overlay_w-50):(main_h-overlay_h-50)',
    'output.AVIF',
]);



    


    I am developing a macOS App using Flutter, please help !

    


  • arm : vp9itxfm : Reorder iadst16 coeffs

    31 décembre 2016, par Martin Storsjö
    arm : vp9itxfm : Reorder iadst16 coeffs
    

    This matches the order they are in the 16 bpp version.

    There they are in this order, to make sure we access them in the
    same order they are declared, easing loading only half of the
    coefficients at a time.

    This makes the 8 bpp version match the 16 bpp version better.

    Signed-off-by : Martin Storsjö <martin@martin.st>

    • [DBH] libavcodec/arm/vp9itxfm_neon.S