
Recherche avancée
Médias (1)
-
Rennes Emotion Map 2010-11
19 octobre 2011, par
Mis à jour : Juillet 2013
Langue : français
Type : Texte
Autres articles (49)
-
Publier sur MédiaSpip
13 juin 2013Puis-je poster des contenus à partir d’une tablette Ipad ?
Oui, si votre Médiaspip installé est à la version 0.2 ou supérieure. Contacter au besoin l’administrateur de votre MédiaSpip pour le savoir -
Support audio et vidéo HTML5
10 avril 2011MediaSPIP utilise les balises HTML5 video et audio pour la lecture de documents multimedia en profitant des dernières innovations du W3C supportées par les navigateurs modernes.
Pour les navigateurs plus anciens, le lecteur flash Flowplayer est utilisé.
Le lecteur HTML5 utilisé a été spécifiquement créé pour MediaSPIP : il est complètement modifiable graphiquement pour correspondre à un thème choisi.
Ces technologies permettent de distribuer vidéo et son à la fois sur des ordinateurs conventionnels (...) -
De l’upload à la vidéo finale [version standalone]
31 janvier 2010, parLe chemin d’un document audio ou vidéo dans SPIPMotion est divisé en trois étapes distinctes.
Upload et récupération d’informations de la vidéo source
Dans un premier temps, il est nécessaire de créer un article SPIP et de lui joindre le document vidéo "source".
Au moment où ce document est joint à l’article, deux actions supplémentaires au comportement normal sont exécutées : La récupération des informations techniques des flux audio et video du fichier ; La génération d’une vignette : extraction d’une (...)
Sur d’autres sites (9959)
-
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