Recherche avancée

Sur d’autres sites (10612)

• avcodec_decode_video2 fails to decode after frame resolution change

  7 octobre 2016, par Krzysztof Kansy

  I’m using ffmpeg in Android project via JNI to decode real-time H264 video stream. On the Java side I’m only sending the the byte arrays into native module. Native code is running a loop and checking data buffers for new data to decode. Each data chunk is processed with :
  

  int bytesLeft = data->GetSize();
  
  int paserLength = 0;
  
  int decodeDataLength = 0;
  
  int gotPicture = 0;
  
  const uint8_t* buffer = data->GetData();
  
  while (bytesLeft > 0) {
  
      AVPacket packet;
  
      av_init_packet(&packet);
  
      paserLength = av_parser_parse2(_codecPaser, _codecCtx, &packet.data, &packet.size, buffer, bytesLeft, AV_NOPTS_VALUE, AV_NOPTS_VALUE, AV_NOPTS_VALUE);
  
      bytesLeft -= paserLength;
  
      buffer += paserLength;
  
  
  
      if (packet.size > 0) {
  
          decodeDataLength = avcodec_decode_video2(_codecCtx, _frame, &gotPicture, &packet);
  
      }
  
      else {
  
          break;
  
      }
  
      av_free_packet(&packet);
  
  }
  
  
  
  if (gotPicture) {
  
  // pass the frame to rendering
  
  }

  The system works pretty well until incoming video’s resolution changes. I need to handle transition between 4:3 and 16:9 aspect ratios. While having AVCodecContext configured as follows :

  _codecCtx->flags2|=CODEC_FLAG2_FAST;
  
  _codecCtx->thread_count = 2;
  
  _codecCtx->thread_type = FF_THREAD_FRAME;
  
  
  
  if(_codec->capabilities&CODEC_FLAG_LOW_DELAY){
  
      _codecCtx->flags|=CODEC_FLAG_LOW_DELAY;
  
  }

  I wasn’t able to continue decoding new frames after video resolution change. The got_picture_ptr flag that avcodec_decode_video2 enables when whole frame is available was never true after that.
  This ticket made me wonder if the issue isn’t connected with multithreading. Only useful thing I’ve noticed is that when I change thread_type to FF_THREAD_SLICE the decoder is not always blocked after resolution change, about half of my attempts were successfull. Switching to single-threaded processing is not possible, I need more computing power. Setting up the context to one thread does not solve the problem and makes the decoder not keeping up with processing incoming data.
  Everything work well after app restart.
  

  I can only think of one workoround (it doesn’t really solve the problem) : unloading and loading the whole library after stream resolution change (e.g as mentioned in here). I don’t think it’s good tho, it will propably introduce other bugs and take a lot of time (from user’s viewpoint).

  Is it possible to fix this issue ?

  EDIT :
  I’ve dumped the stream data that is passed to decoding pipeline. I’ve changed the resolution few times while stream was being captured. Playing it with ffplay showed that in moment when resolution changed and preview in application froze, ffplay managed to continue, but preview is glitchy for a second or so. You can see full ffplay log here. In this case video preview stopped when I changed resolution to 960x720 for the second time. (Reinit context to 960x720, pix_fmt: yuv420p in log).

• FFmpeg transcoding mpeg2 to H264 and compare frames

  11 novembre 2016, par Ivan Kolesnikov

  I have the following mpeg2 source file :
  

  Stream #0:0[0x900] : Video : mpeg2video (Main) ([2][0][0][0] / 0x0002),
  yuv420p(tv, top first), 720x576 [SAR 16:15 DAR 4:3], 4540 kb/s, 25
  fps, 25 tbr, 90k tbn, 50 tbc

  And transcoding it to H264 with the following command :
  

  ffmpeg -i source.mpg -vcodec h264_nvenc -r 25 -g 25 -acodec copy
  -copyts -f mpegts example1.mpg

  After this I want to extract identical frames from the both video files :
  

  ffmpeg -y -ss 00:44:16 -i source.mpg -frames:v 1 source.png

  ffmpeg -y -ss 00:44:16 -i example1.mpg -frames:v 1 example1.png

  But pictures(source.png and example1.png) are different. Please see the source.png :
  

  And the example1.png
  

  How can I catch the same moment(frame) at the both video ?

• Anomalie #3860 (Nouveau) : Non prise en compte de la balise `genie` d’un paquet.xml lors du vidage...

  9 novembre 2016, par marcimat ☺☮☯♫

  La balise genie dans un paquet.xml n’ajoute pas l’entrée adéquat dans tmp/charger_pipelines.php
  dès lors qu’on vide le cache. Il faut repasser sur la page admin_plugins pour qu’elle soit prise en compte.

  Le problème vient du code suivant :
  

  if (charger_fonction($nom, "genie", true)) 
      $prepend_code[’taches_generales_cron’] .= "\$val[’$nom’] = $periode ;\n" ;
   else 
      spip_log("Fonction genie_$nom introuvable", _LOG_ERREUR) ;
  
  

  Effectivement à ce moment là, le chemin des plugins n’est pas encore pris en compte par SPIP et du coup, le charger_fonction() retourne toujours false.
  Je vois deux possibilités pour corriger :
  A) Ignorer ce if tout simplement, considérant que job_queue écrira un log (certes pas du niveau _LOG_ERREUR) en cas où il ne trouve pas la fonction demandée
  B) Remonter le chargement des chemins des plugins : il est effectué juste avant le chargement des fichiers d’options, à la fin de la fonction.
  La partie de chargement des chemins (include_once(_CACHE_PLUGINS_PATH);) pourrait être monté en tête de cette fonction, au niveau de $prepend_code = array();

  Des avis ?