
Recherche avancée
Médias (1)
-
The pirate bay depuis la Belgique
1er avril 2013, par
Mis à jour : Avril 2013
Langue : français
Type : Image
Autres articles (74)
-
Gestion des droits de création et d’édition des objets
8 février 2011, parPar défaut, beaucoup de fonctionnalités sont limitées aux administrateurs mais restent configurables indépendamment pour modifier leur statut minimal d’utilisation notamment : la rédaction de contenus sur le site modifiables dans la gestion des templates de formulaires ; l’ajout de notes aux articles ; l’ajout de légendes et d’annotations sur les images ;
-
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 (...)
-
Dépôt de média et thèmes par FTP
31 mai 2013, parL’outil MédiaSPIP traite aussi les média transférés par la voie FTP. Si vous préférez déposer par cette voie, récupérez les identifiants d’accès vers votre site MédiaSPIP et utilisez votre client FTP favori.
Vous trouverez dès le départ les dossiers suivants dans votre espace FTP : config/ : dossier de configuration du site IMG/ : dossier des média déjà traités et en ligne sur le site local/ : répertoire cache du site web themes/ : les thèmes ou les feuilles de style personnalisées tmp/ : dossier de travail (...)
Sur d’autres sites (6375)
-
Anomalie #4543 (Nouveau) : Accessibilité des chargements ajax (live regions)
2 septembre 2020, par nicod _Suite à un audit de site par Temesis, il remonte que les attributs aria qu’on utilise sont mal placés.
Je cite :
Il semble qu’il y a un problème plus global avec l’utilisation des live region :
Je rencontre à nouveau le div englobant div.ariaformprop qui possèdent les attributsaria-live
aria-atomic
aria-relevantCette utilisation de ces attributs est erronée :
elle ne donne pas le résultat probablement attendu
le support d’aria-relevant dans les assistances technologiques n’est pas assuréIl est donc nécessaire de ne pas utiliser de live region sur une div englobante comme là.
Il faut supprimer ces attributs et utiliser aria-live et aria-atomic avec parcimonie.J’ai regardé l’exemple que tu donnes sur spip.net également.
L’exemple était : https://www.spip.net/spip.php?page=recherche&recherche=plugin&debut_articles=0#pagination_articles
Cette prolifération d’aria-live + aria-atomic part probablement d’un bon sentiment, mais comme parfois avec l’accessibilité, le mieux est l’ennemi du bien.
En positionnant ces attributs, avec ces valeurs, sur des div englobantes, cela génère dans les lecteurs d’écran la lecture automatique des contenus qui ont été mis à jour.
Certes la lecture peut être interrompue par l’utilisateur, mais cela revient, à mon avis à imposer quelque chose qui n’a pas été forcément souhaité. De cette manière le propriétaire du site impose une expérience différente aux utilisateurs de lecteur d’écran.
Ensuite, il faut bien entendu prendre en compte le contexte. Il pourrait arriver que ce comportement soit pertinent. Ce n’est pas le cas ici.Dans le cas de rechargement ajax, il faut étudier chaque cas et son contexte, mais le plus souvent le principe est :
Ne pas utiliser ces attributs lorsqu’il n’y a pas d’interactions / rechargement ajax . Exemple sur un formulaire, cela n’a pas de sens : on rempli un form et puis on valide le form. A priori (si j’ai bien compris le fonctionnement) il n ’y a aucune raison d’utiliser de live region. En théorie, la présence de ces attributs s’il n’y a pas de rechargement ne devrait pas gêner. Mais certains lecteurs d’écran peuvent prendre des libertés par rapport aux spécifications et vocaliser des contenus tout de même. C’est pourquoi il faut être parcimonieux.
Lorsqu’ils sont utiles et nécessaires, utiliser ces attributs pour informer d’un changement. Exemple : donner le nouveau nombre de résultats après utilisation de filtre. Mais il faut bien penser que dans plusieurs cas ils ne sont pas nécessaires, en effet, un bouton d’action doit être explicite avant qu’on appuie dessus. Donc par exemple : lorsque je demande à afficher la page 2 dans une pagination de résultat, il n’y a pas d’info à vocaliser automatiquement, le fait que le bouton dise "afficher la page 2" est suffisant, il serait superflu, voire gênant d’aller plus loin dans ce qui est vocalisé.
Enfin, il faut gérer le focus clavier. Cet aspect est essentiel dès qu’il y a des interactions ajax, mais il dépend totalement du contexte. Et cet aspect est indépendant de la nécessité d’utiliser les live regions. Exemple : dans une série de filtre on va laisser le focus sur le filtre pour que l’utilisateur puisse parcourir la série de filtre. A contrario, dans une pagination (ou quand on a un bouton de type "afficher plus d’articles", dans des news ou dans une page de produits pour un site de e-commerce) on va déplacer le focus sur le 1er nouveau élément qui vient de s’afficher (la zone qui a été mise à jour).
-
advanced ffmpeg compression controll
27 décembre 2015, par Daniel MahlerI am using very aggressive video compression, eg
-crf 51
. I am using this for ’artistic’ effect, so what I am doing may not make sense from a normal video compression point of view.So far I have only been using very basic compression control using only the
-crf
or-b:v
flags. The results look like ffmpeg divides images into square patches and the makes smooth approximations within the patches. This gives 2 control dimensions to the process : the patch size and the aggressiveness of the smoothing within the patches.It have found that ffmpeg uses both parameters to some extent, but there appears to be an absolute maximum patch size in pixels beyond which it will not go regardless of the frame size.
After that it will only increase compression by reducing the detail within the patches.This is suboptimal for high resolution video, where this becomes equivalent to reducing the resolution. The problem is particularly noticeable on fractal like images which have large featureless region as well as regions of high detail.
How can I tell ffmpeg to increase the maximum patch size and retain more detail within the patches ?
-
advanced ffmpeg compression control
18 juillet 2017, par Daniel MahlerI am using very aggressive video compression, eg
-crf 51
. I am using this for ’artistic’ effect, so what I am doing may not make sense from a normal video compression point of view.So far I have only been using very basic compression control using only the
-crf
or-b:v
flags. The results look like ffmpeg divides images into square patches and the makes smooth approximations within the patches. This gives 2 control dimensions to the process : the patch size and the aggressiveness of the smoothing within the patches.It have found that ffmpeg uses both parameters to some extent, but there appears to be an absolute maximum patch size in pixels beyond which it will not go regardless of the frame size.
After that it will only increase compression by reducing the detail within the patches.This is suboptimal for high resolution video, where this becomes equivalent to reducing the resolution. The problem is particularly noticeable on fractal like images which have large featureless region as well as regions of high detail.
How can I tell ffmpeg to increase the maximum patch size and retain more detail within the patches ?