Recherche avancée

Médias (91)

Autres articles (65)

  • Publier sur MédiaSpip

    13 juin 2013

    Puis-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

  • Ajouter notes et légendes aux images

    7 février 2011, par

    Pour pouvoir ajouter notes et légendes aux images, la première étape est d’installer le plugin "Légendes".
    Une fois le plugin activé, vous pouvez le configurer dans l’espace de configuration afin de modifier les droits de création / modification et de suppression des notes. Par défaut seuls les administrateurs du site peuvent ajouter des notes aux images.
    Modification lors de l’ajout d’un média
    Lors de l’ajout d’un média de type "image" un nouveau bouton apparait au dessus de la prévisualisation (...)

  • Ecrire une actualité

    21 juin 2013, par

    Présentez les changements dans votre MédiaSPIP ou les actualités de vos projets sur votre MédiaSPIP grâce à la rubrique actualités.
    Dans le thème par défaut spipeo de MédiaSPIP, les actualités sont affichées en bas de la page principale sous les éditoriaux.
    Vous pouvez personnaliser le formulaire de création d’une actualité.
    Formulaire de création d’une actualité Dans le cas d’un document de type actualité, les champs proposés par défaut sont : Date de publication ( personnaliser la date de publication ) (...)

Sur d’autres sites (8425)

  • Evolution #4768 (Nouveau) : Sus aux préfixes navigateurs

    5 mai 2021

    Dans les CSS du privé on commence à utiliser largement des propriétés qui peuvent requérir des préfixes navigateur : flex, grid, etc.
    Pour ma part je ne les ai pas encore préfixées, en général je fais ça sur la fin une fois que tout est stabilisé (mais j’ai vu que j’étais pas le seul à pas préfixer, ouf).
    Mais ces préfixes sont vraiment une plaie intégrale : c’est chronophage à ajouter et encore plus à modifier, ça alourdit le code et le rend moins lisible, ça fait du bruit de fond dans les commits quand il faut les mettre à jour lorsque le support évolue, et j’en passe.

    Mais s’occuper des préfixes navigateurs, c’est pas notre boulot :)
    On ne devrait plus avoir à faire ça manuellement.
    À défaut de préprocesseur ou d’outil qui permettrait de faire ça semi-automatiquement (en général ils buttent sur les balises Spip de nos squelettes css), il existe une autre solution : les autoprefixeurs JS.
    Ils ajoutent les préfixes à la volée, mais uniquement ceux nécessaires au navigateur, produisant une css plus légère qu’avec les autres solutions.

    Celui-ci est très léger, 2Kb gzippé, il suffit d’inclure le script dans la page et c’est tout : https://projects.verou.me/prefixfree/
    Je propose de l’intégrer et d’oublier les préfixes à tout jamais.

    Dans le privé il serait chargé tout le temps.
    Pour le public, je ne sais pas, 2 possibilités :

    • se contenter de dire qu’il est disponible dans la doc technique, charge aux gens de l’intégrer eux-mêmes dans leur squelettes s’ils en ont l’utilité.
    • ou bien faire un mini plugin-dist sur le même modèle que l’ancien iepatch, avec une option de config « charger le script bla bla ».

  • FFMPEG Multiple outputs from BlackMagic input

    24 septembre 2018, par leo_dragons

    I’m currently needing help to achieve multiple outputs from one input.
    Right now, the outputs are set like this :

    ffmpeg -re -f decklink -i "DeckLink Mini Recorder" -y -pix_fmt yuv420p -c:v h264 -preset fast -tune zerolatency -c:a aac -ac 2 -b:a 128k -ar 44100 -async 1 -b:v 2300k -g 5 -probesize 32 -framerate 30 -movflags +faststart -s 1280x720 -bufsize 1000k -maxrate 3072k -shortest -f flv "rtmp://10.0.0.172:1935/Testing/live_720p"
    
ffmpeg -re -i "rtmp://10.0.0.172:1935/Testing/live_720p" -c:v h264 -preset fast -tune zerolatency -c:a aac -ac 2 -b:a 114k -ar 44100 -async 1 -b:v 900k -g 5 -probesize 32 -framerate 30 -movflags +faststart -s 854x480 -bufsize 400k -maxrate 1000k -shortest -f flv "rtmp://10.0.0.172:1935/Testing/live_480p_hq"
    
ffmpeg -re -i "rtmp://10.0.0.172:1935/Testing/live_720p" -c:v h264 -preset fast -tune zerolatency -c:a aac -ac 2 -b:a 114k -ar 44100 -async 1 -b:v 550k -g 5 -probesize 32 -framerate 30 -movflags +faststart -s 854x480 -bufsize 400k -maxrate 500k -shortest -f flv "rtmp://10.0.0.172:1935/Testing/live_480p_lq"
    
ffmpeg -re -i "rtmp://10.0.0.172:1935/Testing/live_720p" -c:v h264 -preset fast -tune zerolatency -c:a aac -ac 2 -b:a 114k -ar 44100 -async 1 -b:v 450k -g 5 -probesize 32 -framerate 30 -movflags +faststart -s 640x360 -bufsize 400k -maxrate 500k -shortest -f flv "rtmp://10.0.0.172:1935/Testing/live_360p"

    This uses quite a lot of processing power, and also generates unnecessary latency (since I have to stream to WOWZA first, then back to FFMPEG and then back to WOWZA).

    And I want to optimize this.

    I’ve been trying several methods, but I only managed to overflow the decklink buffer. How could I solve this ?

  • Evolution #4753 (Nouveau) : Styles du privé : listes d’objets (suite des boîtes et des formulaires)

    30 avril 2021

    Les boîtes et les formulaires ont été visuellement « raccordés » ensembles.
    Je pense que logiquement les listes d’objets devraient suivre.
    En fait ce sont 3 variations d’un même composant : une boîte avec entête, corps et pied.

    Pour les listes on peut séparer la question en 2 aspects :

    1) L’emballage extérieur

    Là il s’agirait de reprendre les choix graphiques propres à « l’emballage extérieur » des boîtes et formulaires : bordure, arrondi, espacements.
    Exemple sur l’image suivant où les 3 sont visibles (nb : ceux en colonne sont automatiquement « ressérés », d’où la différence de padding etc.)

    Après en fonction de l’un ou de l’autre, il y aura peut-être lieu d’ajuster le padding ou la taille du titre. Mais pour l’instant ce sont ceux en place.

    2) L’intérieur

    Ensuite je propose de procéder à quelques ajustements à l’intérieur de ces listes.
    Je pense que certains choix ont été faits pour s’accommoder du manque de place en largeur à l’époque, et ne sont plus nécessaires maintenant.

    Pour me faire un idée de ce qui fonctionnerait le mieux, et comprendre les détails visuels qui me gênaient un peu, j’ai parcouru quelques articles de recommandations sur l’ergonomie des data tables.
    Alors ils traitent plutot des fonctionnalités de ces tables dans leur ensemble, mais il y a aussi quelques guidelines visuelles intéressantes.

    Je retiens quelques règles simples :

    • Des espacements suffisants et consistants (le padding quoi)
    • Une taille de police identique partout (au moins dans le tbody). C’est fatiguant pour l’oeil et moins lisible quand on passe sans arrêt d’un taille de police à l’autre sur une même ligne. Et je ne suis pas sûr qu’il y ait forcément besoin de gras pour certains éléments comme les titres ou autres.
    • À quelques exceptions près (id, picto), pas de largeur fixes sur les colonnes, laisser faire le navigateur.

    Donc voilà, c’est pas grand chose à ajuster non plus.
    Les colonnes des tables ont des classes .importante et .secondaire.
    À mon avis elle ne devraient plus avoir d’incidence en vue « normale », mais juste décider quelles colonnes afficher et masquer en vue réduite, dans les colonnes ou ailleurs.

    Donc dans les grandes lignes ça donnerait quelques chose comme ça (juste une maquette) :

    3) Détails

    Enfin pour ces 3 composants, je propose qu’il y ait une classe modificatrice commune pour produire un affichage compact, c’est à dire ressérer tout le contenu.
    Cette classe serait automatiquement appliquée dans les colonnes.

    Ça pourrait être « compact », mais sur d’autres composants pour varier les tailles je suis parti sur mini / large. Donc mini aussi ?

Navigation