Recherche avancée

Sur d’autres sites (11863)

• Crash in ffmpeg avcodec_free_context in one application but not in other

  5 novembre 2017, par geekowl

  I am building an application in C++ on Windows 10 using Microsoft Visual Studio 2012 Professional.

  I have created a wrapper library around ffmpeg (libavcodec) to encode video in H.264 format using libx264. This wrapper contains following functions :

  Initialize()
  
  Open()
  
  EncodeFrame()
  
  Close()
  
  Uninitialize()

  I created a test application to test the wrapper library. The test application works perfectly fine.

  When I use the wrapper library in my actual main application, the main application crashes in Close() API. Inside close, it crashes in avcodec_free_context(). The difference between the main application and the test application is that the main application links with some more dependent libraries that test application does not link with.

  To debug the problem in the main application, I put avcodec_free_context() in Open() after the context is allocated. The crash occurs if avcodec_free_context() is put at a certain point as shown below.

  pCodecContext = avcodec_alloc_context3(pCodec);
  
  
  
  // <---- No crash here.
  
  
  
  pCodecContext->bit_rate = 200000;
  
  pCodecContext->width = 320;
  
  pCodecContext->height = 240;
  
  .
  
  .
  
  .
  
  if (pCodec->id == AV_CODEC_ID_H264)
  
  {
  
      av_opt_set(pCodecContext->priv_data, "preset", "slow", 0);
  
      av_opt_set(pCodecContext->priv_data, "tune", "zerolatency", 0);
  
  }
  
  
  
  pCodecContext->flags |= CODEC_FLAG_GLOBAL_HEADER;
  
  
  
  // <-- No crash here
  
  
  
  if (avcodec_open2(pCodecContext, pCodec, NULL) < 0)
  
  {
  
      return -1;
  
  }
  
  
  
  // <-- Crash here [avcodec_free_context(&pCodecContext);]

  What is a correct approach to identify and resolve this problem ?

  Thanks in advance.

  Update

  I found out that ffmpeg was built using gcc. That was causing the crash. I rebuilt ffmpeg using Visual Studio. That solved problem.

• Crash in ffmpeg avcodec_free_context in one application but not in other

  5 novembre 2017, par geekowl

  I am building an application in C++ on Windows 10 using Microsoft Visual Studio 2012 Professional.

  I have created a wrapper library around ffmpeg (libavcodec) to encode video in H.264 format using libx264. This wrapper contains following functions :

  Initialize()
  
  Open()
  
  EncodeFrame()
  
  Close()
  
  Uninitialize()

  I created a test application to test the wrapper library. The test application works perfectly fine.

  When I use the wrapper library in my actual main application, the main application crashes in Close() API. Inside close, it crashes in avcodec_free_context(). The difference between the main application and the test application is that the main application links with some more dependent libraries that test application does not link with.

  To debug the problem in the main application, I put avcodec_free_context() in Open() after the context is allocated. The crash occurs if avcodec_free_context() is put at a certain point as shown below.

  pCodecContext = avcodec_alloc_context3(pCodec);
  
  
  
  // <---- No crash here.
  
  
  
  pCodecContext->bit_rate = 200000;
  
  pCodecContext->width = 320;
  
  pCodecContext->height = 240;
  
  .
  
  .
  
  .
  
  if (pCodec->id == AV_CODEC_ID_H264)
  
  {
  
      av_opt_set(pCodecContext->priv_data, "preset", "slow", 0);
  
      av_opt_set(pCodecContext->priv_data, "tune", "zerolatency", 0);
  
  }
  
  
  
  pCodecContext->flags |= CODEC_FLAG_GLOBAL_HEADER;
  
  
  
  // <-- No crash here
  
  
  
  if (avcodec_open2(pCodecContext, pCodec, NULL) < 0)
  
  {
  
      return -1;
  
  }
  
  
  
  // <-- Crash here [avcodec_free_context(&pCodecContext);]

  What is a correct approach to identify and resolve this problem ?

  Thanks in advance.

  Update

  I found out that ffmpeg was built using gcc. That was causing the crash. I rebuilt ffmpeg using Visual Studio. That solved problem.

• Anomalie #3398 (Nouveau) : Date du thread modifiée lorsqu’un message de forum est soumis, sans ten...

  6 mars 2015, par Pascal Verrier

  Bonjour,

  Configuration : un SPIP neuf 3.0.17 avec le plugin Comments 3.3.2 permettant l’affichage en thread (et donc de répondre à un message, ce qui n’est pas possible avec le core seul).
  Concerné : plugin-dist forum.

  Je constate sur SPIP 3.0.17 ce fonctionnement curieux :
  - j’ai configuré dans un premier temps le forum d’un article en modération à postériori
  - j’ai posté un premier message puis y ai fait une réponse : je constate bien le changement de la date du thread qui se recale sur la date du dernier posté (et donc publié)
  - j’ai modifié la configuration pour passer en modération à priori
  - j’ai ajouté dans le même thread un troisième message (qui donc cette fois n’est pas publié, car modéré)
  - dans la base de données je constate que la date_thread s’est de nouveau calée sur le dernier message, alors qu’il n’est pas publié (statut "prop")

  Cela ne me semble pas normal ; sur mon site de production (http://www.harmoweb.cnrs.fr/spip.php?rubrique28) intégrant l’affichage de la liste des threads, du plus récent au plus ancien (en se basant sur date_thread) cela a pour effet de "faire remonter" des messages anciens sur lesquels des messages viennent d’être posté même s’ils ne sont pas publiés (dans notre cas des spams interceptés par nospam, nous n’avons pas de modération à priori, mais le mécanisme posant problème est le même).

  Dans mes recherches je suis également tombé sur cette correction d’anomalie https://core.spip.net/issues/852 où le problème de base était similaire mais si j’ai bien compris ne concernait que les mises à jour de statut de messages publiés à priori ; l’évolution de date_thread est normale dans ce cas, contrairement à la situation où le message n’est pas publié d’office, la date de thread ne tenant donc pas compte du statut du message fraîchement posté : lors de l’enregistrement d’un nouveau message, date_thread ne devrait être changé sur tous les messages du fil que si ce message est publié, et non dans les autres cas.