Recherche avancée

Médias (1)

Mot : - Tags -/swfupload

Autres articles (72)

  • Submit bugs and patches

    13 avril 2011

    Unfortunately a software is never perfect.
    If you think you have found a bug, report it using our ticket system. Please to help us to fix it by providing the following information : the browser you are using, including the exact version as precise an explanation as possible of the problem if possible, the steps taken resulting in the problem a link to the site / page in question
    If you think you have solved the bug, fill in a ticket and attach to it a corrective patch.
    You may also (...)

  • MediaSPIP 0.1 Beta version

    25 avril 2011, par

    MediaSPIP 0.1 beta is the first version of MediaSPIP proclaimed as "usable".
    The zip file provided here only contains the sources of MediaSPIP in its standalone version.
    To get a working installation, you must manually install all-software dependencies on the server.
    If you want to use this archive for an installation in "farm mode", you will also need to proceed to other manual (...)

  • MediaSPIP v0.2

    21 juin 2013, par

    MediaSPIP 0.2 is the first MediaSPIP stable release.
    Its official release date is June 21, 2013 and is announced here.
    The zip file provided here only contains the sources of MediaSPIP in its standalone version.
    To get a working installation, you must manually install all-software dependencies on the server.
    If you want to use this archive for an installation in "farm mode", you will also need to proceed to other manual (...)

Sur d’autres sites (7174)

  • 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.
    }
  • avcodec/dvdsubdec : reject some broken packets

    21 septembre 2015, par wm4
    avcodec/dvdsubdec : reject some broken packets
    

    If cmd_pos is broken, this would just keep accumulating packets in the
    reassembly buffer, until it fails and flushes the buffer on overflow.
    Since packets are usually rather small, this will take a lot of subtitle
    packets. The perceived effect is that subtitles are not displayed
    anymore after the faulty packet was passed to the decoder.

    I’m not terribly sure about this, but on the other hand this code is
    active only when fragmented packets need to be reassembled.

    Fixes sample file in trac issue #4872.

    • [DH] libavcodec/dvdsubdec.c