Recherche avancée

Médias (1)

Mot : - Tags -/berlin

Autres articles (105)

  • Websites made ​​with MediaSPIP

    2 mai 2011, par

    This page lists some websites based on MediaSPIP.

  • Gestion des droits de création et d’édition des objets

    8 février 2011, par

    Par 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 ;

  • Dépôt de média et thèmes par FTP

    31 mai 2013, par

    L’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 (17723)

  • swr : split out DSP functions.

    14 juin 2014, par Ronald S. Bultje
    swr : split out DSP functions.

    DSP bits of swri_resample go into their own mini-DSP functions ; DSP
    
init goes from a per-call branch in multiple_resample to a proper
    
DSP init routine ; x86 bits go into x86/ ; swri_resample() moves out of
    
resample_template.c into resample.c because it’s independent of DSP
    
code or sample type ; multiple_resample() is simplified.
    

    Signed-off-by : Michael Niedermayer <michaelni@gmx.at>
    • [DH] libswresample/Makefile
    • [DH] libswresample/resample.c
    • [DH] libswresample/resample.h
    • [DH] libswresample/resample_dsp.c
    • [DH] libswresample/resample_template.c
    • [DH] libswresample/x86/Makefile
    • [DH] libswresample/x86/resample_x86_dsp.c

  • 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 ».

  • ARM compiler update

    15 janvier 2010, par Mans — ARM, Compilers

    Since my last shootout, all the tested vendors have updated their compilers. Here is a quick update on each of them.

    Both the 4.3 and 4.4 branches of FSF GCC have had bugfix releases, bringing them to 4.3.4 and 4.4.2, respectively. Neither update contains anything particularly noteworthy.

    The CodeSourcery 2009q3 release sees an update to a GCC 4.4 base, a significant change from the 4.3 base used in 2009q1. The update is a mixed blessing. In fact, it is mostly a curse and hardly a blessing at all. On the bright side, the floating-point speed regressions in 2009q1 are gone, 2009q3 being a few per cent faster even than 2007q3. Unfortunately, this improvement is completely overshadowed by a major speed regression on integer code, a whopping 24% in one case. This ties in with the slowdown previously observed with FSF GCC 4.4 compared to 4.3.

    ARM RVCT 4.0 is now at Build 697. This update fixes some bugs and introduces others. Notably, it no longer builds FFmpeg correctly. The issue has been reported to ARM.

    Texas Instruments, finally, have made a formal release, v4.6.1, of their TMS470 compiler incorporating various fixes allowing it to build a moderately patched FFmpeg. The performance remains somewhere between GCC and RVCT on average.

    In light of the above, my recommendations remain unchanged :

    • For a free compiler, choose CodeSourcery 2009q1. It beats GCC 4.3.4 by 5-10% in most cases.
    • GNU purists are best served by GCC 4.3.4, which is up to 20% faster than 4.4.2 and rarely slower.
    • When price is not a concern, ARM RCVT is a good option, outperforming GCC by up to a factor 2.
    • In all cases, disable any auto-vectorisation features.

    Regardless of which compiler is chosen, I cannot overstress the importance of testing. All compilers are crawling with bugs, and even the most innocent-looking code change can trigger one of them. When using a compiler other than GCC, extra caution is advised considering a lot of code is developed using only GCC and may thus fall prey to bugs unique to said other compiler.

Navigation