
Recherche avancée
Médias (2)
-
Granite de l’Aber Ildut
9 septembre 2011, par
Mis à jour : Septembre 2011
Langue : français
Type : Texte
-
Géodiversité
9 septembre 2011, par ,
Mis à jour : Août 2018
Langue : français
Type : Texte
Autres articles (57)
-
Websites made with MediaSPIP
2 mai 2011, parThis page lists some websites based on MediaSPIP.
-
Supporting all media types
13 avril 2011, parUnlike most software and media-sharing platforms, MediaSPIP aims to manage as many different media types as possible. The following are just a few examples from an ever-expanding list of supported formats : images : png, gif, jpg, bmp and more audio : MP3, Ogg, Wav and more video : AVI, MP4, OGV, mpg, mov, wmv and more text, code and other data : OpenOffice, Microsoft Office (Word, PowerPoint, Excel), web (html, CSS), LaTeX, Google Earth and (...)
-
Creating farms of unique websites
13 avril 2011, parMediaSPIP platforms can be installed as a farm, with a single "core" hosted on a dedicated server and used by multiple websites.
This allows (among other things) : implementation costs to be shared between several different projects / individuals rapid deployment of multiple unique sites creation of groups of like-minded sites, making it possible to browse media in a more controlled and selective environment than the major "open" (...)
Sur d’autres sites (9227)
-
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