Recherche avancée

Médias (91)

Autres articles (75)

  • MediaSPIP v0.2

    21 juin 2013, par

    MediaSPIP 0.2 est la première version de MediaSPIP stable.
    Sa date de sortie officielle est le 21 juin 2013 et est annoncée ici.
    Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
    Comme pour la version précédente, il est nécessaire d’installer manuellement l’ensemble des dépendances logicielles sur le serveur.
    Si vous souhaitez utiliser cette archive pour une installation en mode ferme, il vous faudra également procéder à d’autres modifications (...)

  • MediaSPIP version 0.1 Beta

    16 avril 2011, par

    MediaSPIP 0.1 beta est la première version de MediaSPIP décrétée comme "utilisable".
    Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
    Pour avoir une installation fonctionnelle, il est nécessaire d’installer manuellement l’ensemble des dépendances logicielles sur le serveur.
    Si vous souhaitez utiliser cette archive pour une installation en mode ferme, il vous faudra également procéder à d’autres modifications (...)

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

Sur d’autres sites (10477)

  • Evolution #4080 : Raccourci puce : se débarasser de l’image

    24 janvier 2018, par b b

    Je nuancerais, d’après ce que j’ai vu, je suis presque sûr que des fois c’est volontaire, pour des raisons esthétiques à priori.

    Oui, il faut faire attention aux effets de bord, je vois souvent des gens utiliser les puces graphiques pour décorer un paragraphe et le distinguer de ceux qui suivent. Si on active un comportement "à la belles puces", les pages contiendront des vraies listes avec un seul li...

  • Anomalie #4107 (Nouveau) : Warning Zend OPcache

    2 mars 2018, par Mathieu L

    Je travaille sur un serveur qui n’est pas le mien (que je n’ai pas configuré et sur lequel je n’ai pas la main), désolé si cette demande n’est pas suffisamment précise.

    OPcache est activé sur le serveur, le formulaire de login à /ecrire/ me renvoie le warning suivant :

    Warning : Zend OPcache API is restricted by "restrict_api" configuration directive in /srv/users/xxx/apps/yyy/public/ecrire/inc/flock.php on line 468
    


    Impossible ensuite de se connecter (headers already sent).
    En rendant silencieux l’appel à l’invalidation d’OPcache ça fonctionne.

    @opcache_invalidate($filepath, true) ;
  • FFMPEG API - Recording video and audio - Performance issues

    24 juillet 2015, par Solidus

    I’m developing an app which is able to record video from a webcam and audio from a microphone. I also need to process user input at the same time as they can, for example, draw on top of the video, in real time. I’ve been using QT but unfortunately the camera module does not work on windows which led me to use ffmpeg to record the video/audio.

    My Camera module is now working well besides a slight problem with syncing (which I asked for a solution in another thread). The problem is that when I start recording the performance drops (around 50-60% cpu usage). I’m not sure where or if I can improve on this. I figure the problem comes from the running threads. I have followed the dranger tutorial to help me develop my code and I am use 3 threads in total. One for capturing the video and audio packets, adding them to a queue, one to process the video packets and one to process the audio packets. While processing the video packets I also have to convert the frame (which comes raw from the camera feed) to a RGB format so that QT is able to show it. The frame also has to be converted to YUV420P to be saved to the mp4 file. This could also be hindering performance.

    Every time I try to get a packet from the queue I verify if it is empty and, if it is, I tell the thread to sleep until more data is available as this helps saving CPU usage. The problem is sometimes the threads don’t wake up on time and the queue starts filling up with packages adding a cumulative delay, which never stops.

    Bellow is a part of the code I am using for the 3 threads.

    One thread is capturing both audio and video packets and adding them on a queue :

    void FFCapture::grabFrames(int videoStream, int audioStream) {
       grabActive = true;
       videoQueue.clear();
       audioQueue.clear();

       AVPacket pkt;
       while (av_read_frame(iFormatContext, &pkt) >= 0 && active) {
           if(pkt.stream_index == videoStream) {
               enqueueVideoPacket(pkt);
           }
           else if(pkt.stream_index == audioStream) {
               enqueueAudioPacket(pkt);
           }
           else {
               av_free_packet(&pkt);
           }
           //QThread::msleep(20);
       }
       //Wake up threads that might be sleeping
       videoWait.wakeOne();
       audioWait.wakeOne();
       grabActive = false;
       cleanupAll();
    }

    And then I have one thread for each stream (video and audio) :

    void FFCapture::captureVideoFrames() {
       videoActive = true;
       outStream.videoPTS = 2;

       int min = 0;
       if(cacheMs > 0) {
           QThread::msleep(cacheMs);
           min = getVideoQueueSize();
       }

       while(active || (!active && (getVideoQueueSize() > min))) {
           qDebug() << "Video:" << videoQueue.size() << min;
           AVPacket pkt;
           if(dequeueVideoPacket(pkt, min) >= 0) {
               if(processVideoPacket(&pkt) < 0) {
                   av_free_packet(&pkt);
                   break;
               }
               av_free_packet(&pkt);
           }
       }
       videoActive = false;
       cleanupAll();
    }

    void FFCapture::captureAudioFrames() {
       audioActive = true;
       outStream.audioPTS = 0;

       int min = 0;
       if(cacheMs > 0) {
           QThread::msleep(cacheMs);
           min = getAudioQueueSize();
       }

       while(active || (!active && (getAudioQueueSize() > min))) {
           qDebug() << "Audio:" << audioQueue.size() << min;
           AVPacket pkt;

           if(dequeueAudioPacket(pkt, min) >= 0) {
               if(recording) {
                   if(processAudioPacket(&pkt) < 0) break;
               }
               else av_free_packet(&pkt);
           }
       }
       audioActive = false;
       cleanupAll();
    }

    When I remove a packet from the queue I verify if it is empty and if it is I tell the thread to wait for more data. The code is as follows :

    void FFCapture::enqueueVideoPacket(const AVPacket &pkt) {
       QMutexLocker locker(&videoQueueMutex);
       videoQueue.enqueue(pkt);
       videoWait.wakeOne();
    }

    int FFCapture::dequeueVideoPacket(AVPacket &pkt, int sizeConstraint) {
       QMutexLocker locker(&videoQueueMutex);
       while(1) {
           if(videoQueue.size() > sizeConstraint) {
               pkt = videoQueue.dequeue();
               return 0;
           }
           else if(!active) {
               return -1;
           }
           else {
               videoWait.wait(&videoQueueMutex);
           }
       }
       return -2; //Should never happen. Just to avoid compile error.
    }