Recherche avancée

Sur d’autres sites (7768)

• no difference between h264 and h264_cuvid

  10 juillet 2020, par Ruslan Ablyazov

  I use libav to decode an RTSP stream. I tried two code options : with auto codec selection and with hardcoded codec.

  


  pCodec = avcodec_find_decoder (pFormatCtx->streams[p_InputVideoStreamIndex]->codecpar->codec_id);&#xA;//pCodec = avcodec_find_decoder_by_name ("h264_cuvid");&#xA;&#xA;LOG (info) &lt;&lt; "Video codec name" &lt;&lt; pCodec->name &lt;&lt; ". Full name:" &lt;&lt; (pCodec->long_name? PCodec->long_name: "<null>");&#xA;</null>

  


  The avcodec_find_decoder() function returns h264 codec. The problem is that the speed and load on the CPU when using h264 is no different from h264_cuvid. What could be the reason ? When I use h264_cuvid, the video card is loaded by 2-3% more.

  


  Video stream : 1920x1080 25 FPS (main and high profile).
Video card : NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] (rev a1).
Processor : Intel (R) Core (TM) i5-8400 CPU @ 2.80GHz.

  


  Compilation config ffmpeg :

  


  ffmpeg version 4.3 Copyright (c) 2000-2020 the FFmpeg developers
  built with gcc 8 (Debian 8.3.0-6)
  configuration: --enable-gpl --enable-ladspa --enable-libpulse --enable-libsoxr --enable-libspeex --enable-avfilter --enable-avresample --enable-postproc --enable-pthreads --enable -libass --enable-libfreetype --enable-libmp3lame --enable-nonfree --disable-ffplay --enable-libxvid --enable-cuda --enable-cuda-nvcc --enable-cuda-sdk --enable- cuvid --enable-nvenc --enable-nonfree --enable-libnpp --enable-shared --extra-cflags = -I/usr/local/cuda/include --extra-ldflags = -L/usr/local/cuda/lib64


  


• Nomenclature #4519 (Nouveau) : Renommage de terminologie (blacklist / whitelist)

  13 juillet 2020

  En lisant la compilation [PHP Annotated – June 2020](https://blog.jetbrains.com/phpstorm/2020/06/php-annotated-june-2020/) on tombe sur ce point :

  [[RFC] Change terminology to ExcludeList](https://wiki.php.net/rfc/change-terminology-to-excludelist) — The topic of renaming offensive terms has not been overlooked by the PHP world either. There have been [heated discussions](https://externals.io/message/110515) in the Internals.
  In the PHP core, the change affects only one thing : the configuration directive `opcache.blacklist_filename` should be renamed to `opcache.exclude_list_filename`.
  Many other PHP tools have already made changes in this regard : [PHPUnit](https://github.com/sebastianbergmann/phpunit/blob/master/ChangeLog-9.3.md#930---2020-08-07), [Drupal](https://www.drupal.org/project/drupal/issues/2993575), [Xdebug](https://github.com/xdebug/xdebug/commit/63b43b51e43b794cf8cd740e54089b2b7320fbe1), [Yii](https://github.com/yiisoft/yii2/pull/18104), [Composer](https://github.com/composer/composer/pull/8957) (+ [working with non-master Git branches](https://blog.packagist.com/composer-and-default-git-branches/)).

  C’est certainement intéressant aussi de songer à ces renommages chez nous également, utilisés à quelques endroits.

• Anomalie #4522 : erreur en php 8 dans mysql.log

  14 juillet 2020

  Ok, là on a un petit souci semble t’il (probablement pas du à PHP8 non plus, mais à la version de Mysql ou de sa remontée d’erreur)

  Dans ces pipelines, on récupère $mydate = $flux['args']['date'];, et on lui applique, sur les requêtes sql_quote($mydate).
  Sauf que $mydate vaut la chaine '2020-07-13 15:38:14', guillemets compris.
  Du coup, ça crée quelque chose de faux ensuite dans les requêtes (guillemet + guillement échappé).
  Je suppose que c’était vu comme une date invalide avant ? ou mysql s’en accomodait très bien ?
  (parce que je crois pas qu’on ait eu de retours comme quoi ces pipelines "optimiser_base_disparus" ne fonctionnent pas comme prévus)

  Cette date est calculée là https://git.spip.net/spip/spip/src/branch/master/ecrire/genie/optimiser.php#L157 est a déjà sql_quote d’appliqué, depuis 9 ans, par https://github.com/spip/SPIP/commit/472dc705e72557172ee3e53bd3a06465a9968ab9

  Mais par exemple dans les plugins, un commit ultérieur (il y a 6 ans) a rajouté les sql_quote doublons sur les dates…
  - https://github.com/spipremix/breves/commit/4f82b6481
  - https://github.com/spipremix/sites/commit/1dae8e8fe73340
  - https://github.com/spipremix/petitions/commit/21c15b08edc7
  - ...

  Je pense que ces sql_quote($mydate) ajoutés dans les pipelines sont erronés du coup, mais il y a peut être quelque chose qui m’échappe.

  (désolé, j’utilise Github pour remonter l’historique via blame + les boutons voir le fichier avant cette révision, tellement pratique... et Gitea n’a pas ça)