Recherche avancée

Sur d’autres sites (9129)

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

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

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