Recherche avancée

Sur d’autres sites (7788)

• Decoder return of av_find_best_stream vs. avcodec_find_decoder

  7 octobre 2016, par Jason C

  The docs for libav’s av_find_best_stream function (libav 11.7, Windows, i686, GPL) specify a parameter that can be used to receive a pointer to an appropriate AVCodec :

  decoder_ret - if non-NULL, returns the decoder for the selected stream

  There is also the avcodec_find_decoder function which can find an AVCodec given an ID.

  However, the official demuxing + decoding example uses av_find_best_stream to find a stream, but chooses to use avcodec_find_decoder to find the codec in lieu of av_find_best_stream’s codec return parameter :

  ret = av_find_best_stream(fmt_ctx, type, -1, -1, NULL, 0);
  
  ...
  
  stream_index = ret;
  
  st = fmt_ctx->streams[stream_index];
  
  ...
  
  /* find decoder for the stream */
  
  dec = avcodec_find_decoder(st->codecpar->codec_id);

  As opposed to something like :

  ret = av_find_best_stream(fmt_ctx, type, -1, -1, &dec, 0);

  My question is pretty straightforward : Is there a difference between using av_find_best_stream’s return parameter vs. using avcodec_find_decoder to find the AVCodec ?

  The reason I ask is because the example chose to use avcodec_find_decoder rather than the seemingly more convenient return parameter, and I can’t tell if the example did that for a specific reason or not. The documentation itself is a little spotty and disjoint, so it’s hard to tell if things like this are done for a specific important reason or not. I can’t tell if the example is implying that it "should" be done that way, or if the example author did it for some more arbitrary personal reason.

• Anomalie #3630 : Logo d’auteur et fonction de recherche de logo

  13 août 2016, par b b

  Je dépose ici la discussion qui a eu lieu à ce sujet sur IRC pour en garder une trace :

  < marcimat‎ >  dans id_table_objet() je vois que ça fait un traitement même si on passe ’id_auteur’
  < marcimat‎ >  du coup, je me dis que quête logo
  < marcimat‎ >  pourrait tester si substr($type, 0, 3) !== ’id_’
  < marcimat‎ >  appeler id_table_objet($type)
  < marcimat‎ >  non ?
  < marcimat‎ >  c’est peut être un compromis
  < marcimat‎ >  ou un strcmp
  < phenix_spip‎ >  Pourquoi faire un test ?
  < marcimat‎ >  parce que je vois des calculs dans id_table_objet() systématiques
  < marcimat‎ >  même si on envoie déjà id_truc
  < phenix_spip‎ > ?
  < phenix_spip‎ >  Ha je vois
  < marcimat‎ >  @id_table_objet()
  < Edgard‎ >  Hop http://code.spip.net/@id_table_objet - Hop (sinon) http://code.spip.net/spip.php?page=recherche&recherche=id_table_objet
  < marcimat‎ >  https://core.spip.net/projects/spip/repository/entry/spip/ecrire/base/objets.php#L1066 donc
  < marcimat‎ >  mais effectivement, je pense que ça doit pas gêner si quête_logo est simplifié
  < phenix_spip‎ >  marcimat : ce serai plus logique que le test soit dans id_table_objet non ?
  < marcimat‎ >  enfin modifié pour accepter un vrai type
  < marcimat‎ >  certes, mais c’est déjà plus sensible ^^
  < phenix_spip‎ > ?
  < marcimat‎ >  ok
  < marcimat‎ >  en fait objet_type() teste déjà en enlevant id_
  < marcimat‎ >  donc, y pa pas spécialement besoin
  < phenix_spip‎ >  Ben voilà :)
  < marcimat‎ >  donc là https://core.spip.net/projects/spip/repository/entry/spip/ecrire/base/objets.php#L1070
  < marcimat‎ >  objet_type(’id_auteur’) doit ressortir ’auteur’
  < marcimat‎ >  oui, voilà :)
  < marcimat‎ >  all is fine
  

• Anomalie #3697 : Bug svn10000 SPIP 3

  14 février 2016, par MiKaël Navarro

  Cependant je m’étonne que cette erreur là « remplissent les logs du serveur Web », d’autant que l’erreur n’est pas critique.
  Normalement le if ($dir = opendir(...)) n’entre pas dans le if si opendir retourne false. Par contre, oui ça créait une erreur PHP si le dossier n’existait pas, mais qui ne devrait pas perturber il me semble la suite du processus de mise à jour. Je n’ai pas été vérifier cependant.

  Effectivement le if ($dir = opendir(...)) n’entre pas dans le if si opendir retourne false, mais ce n’est pas le code que j’ai dans l’archive spip-3.1.zip (r22707 aujourd’hui en date du 6 janvier), au lieu de ça j’ai seulement (sans le if) :
  

  $dir = opendir($base) ;
  while (($f = readdir($dir)) !== false) 
  ...
  

  De plus je suis d’accord, ce n’est pas une Erreur mais un simple Warning que l’on retrouve dans /var/log/nginx/error.log :
  

  2016/02/14 12:36:04 [error] 1141#0 : *197 FastCGI sent in stderr : "PHP message : PHP Warning :  opendir(baddir/) : failed to open dir : No such file or directory in /home/mickey/public_html/test-opendir.php on line 2
  PHP message : PHP Warning :  readdir() expects parameter 1 to be resource, boolean given in /home/mickey/public_html/test-opendir.php on line 3" while reading response header from upstream, client : 127.0.0.1, server : localhost, request : "GET / mickey/test-opendir.php HTTP/1.1", upstream : "fastcgi ://unix :/var/run/php5-fpm.sock :", host : "localhost" 
  

  
  Ensuite le test while (($f = readdir($dir)) !== false) rentre dans une boucle infinie et c’est avec ça que j’ai créé un log de plus de 2Go !

  D’après les commit, je vois que c’était déjà corrigé dans la version SVN, mais un test supplémentaire mange pas de pain ça sera plus robuste et évitera l’écriture d’un Warning dans les logs pour rien :)

  En tout cas merci pour votre réactivité.