
Recherche avancée
Médias (1)
-
GetID3 - Bloc informations de fichiers
9 avril 2013, par
Mis à jour : Mai 2013
Langue : français
Type : Image
Autres articles (76)
-
Configurer la prise en compte des langues
15 novembre 2010, parAccéder à la configuration et ajouter des langues prises en compte
Afin de configurer la prise en compte de nouvelles langues, il est nécessaire de se rendre dans la partie "Administrer" du site.
De là, dans le menu de navigation, vous pouvez accéder à une partie "Gestion des langues" permettant d’activer la prise en compte de nouvelles langues.
Chaque nouvelle langue ajoutée reste désactivable tant qu’aucun objet n’est créé dans cette langue. Dans ce cas, elle devient grisée dans la configuration et (...) -
L’utiliser, en parler, le critiquer
10 avril 2011La première attitude à adopter est d’en parler, soit directement avec les personnes impliquées dans son développement, soit autour de vous pour convaincre de nouvelles personnes à l’utiliser.
Plus la communauté sera nombreuse et plus les évolutions seront rapides ...
Une liste de discussion est disponible pour tout échange entre utilisateurs. -
Use, discuss, criticize
13 avril 2011, parTalk to people directly involved in MediaSPIP’s development, or to people around you who could use MediaSPIP to share, enhance or develop their creative projects.
The bigger the community, the more MediaSPIP’s potential will be explored and the faster the software will evolve.
A discussion list is available for all exchanges between users.
Sur d’autres sites (9907)
-
Anomalie #4522 : erreur en php 8 dans mysql.log
14 juillet 2020Ok, 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êtessql_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)
-
Nomenclature #4519 (Nouveau) : Renommage de terminologie (blacklist / whitelist)
13 juillet 2020En 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.
-
no difference between h264 and h264_cuvid
10 juillet 2020, par Ruslan AblyazovI 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);
//pCodec = avcodec_find_decoder_by_name ("h264_cuvid");

LOG (info) << "Video codec name" << pCodec->name << ". Full name:" << (pCodec->long_name? PCodec->long_name: "<null>");
</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