Recherche avancée

Sur d’autres sites (7015)

• 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

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