Recherche avancée

Médias (1)

Mot : - Tags -/livre électronique

Autres articles (57)

  • 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 (...)

  • Soumettre améliorations et plugins supplémentaires

    10 avril 2011

    Si vous avez développé une nouvelle extension permettant d’ajouter une ou plusieurs fonctionnalités utiles à MediaSPIP, faites le nous savoir et son intégration dans la distribution officielle sera envisagée.
    Vous pouvez utiliser la liste de discussion de développement afin de le faire savoir ou demander de l’aide quant à la réalisation de ce plugin. MediaSPIP étant basé sur SPIP, il est également possible d’utiliser le liste de discussion SPIP-zone de SPIP pour (...)

  • Encodage et transformation en formats lisibles sur Internet

    10 avril 2011

    MediaSPIP transforme et ré-encode les documents mis en ligne afin de les rendre lisibles sur Internet et automatiquement utilisables sans intervention du créateur de contenu.
    Les vidéos sont automatiquement encodées dans les formats supportés par HTML5 : MP4, Ogv et WebM. La version "MP4" est également utilisée pour le lecteur flash de secours nécessaire aux anciens navigateurs.
    Les documents audios sont également ré-encodés dans les deux formats utilisables par HTML5 :MP3 et Ogg. La version "MP3" (...)

Sur d’autres sites (10144)

  • Typesetting

    9 juin 2010, par Mikko Koppanen — Imagick, PHP stuff

    Ever had the situation where you have a piece of string which you need to overlay on an image ? Maybe a situation where the area reserved for the string is known in pixels but you need to know the font size to fill most of the area ? Think no more !

    Here is a small example of how to fit a certain piece of a string on to an area of which you know the width and the height or only the width. The magic happens through the ImageMagick CAPTION : format. You can see from the example images how the parameters actually affect the image.

    1. < ?php
    2.  
    3. /* How wide is our image */
    4. $image_width = 200 ;
    5.  
    6. /* Give zero for autocalculating the height */
    7. $image_height = 200 ;
    8.  
    9. /* Specify the text */
    10. $text = "Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
    11.     Mauris lectus mi, mattis non, euismod vel, sagittis nec, ipsum." ;
    12.  
    13. /* Instanciate imagick */
    14. $im = new Imagick() ;
    15.  
    16. /* Create new image using caption : pseudo format */
    17. $im->newPseudoImage( $image_width, $image_height, "caption :" . $text ) ;
    18.  
    19. /* Put 1px border around the image */
    20. $im->borderImage( ’black’, 1, 1 ) ;
    21.  
    22. /* PNG format */
    23. $im->setImageFormat( "png")  ;
    24.  
    25. /* Output */
    26. header( "Content-Type : image/png" ) ;
    27. echo $im ;
    28.  
    29.  ?>

    Here is image with width 100 and height 0 :

    width_100_height_0.png

    Width 100 Height 50 :

    width_100_height_50.png

    Width 200 Height 200 (as you can see the font size is now larger) :

    width_200_height_200.png

  • Padding thumbnail with color

    9 juin 2010, par Mikko Koppanen — Imagick, PHP stuff

    I know, it’s been a while since I last blogged. This is because a lot of things are happening in my personal life. I recently relocated to London from Finland and started a new job. Things are quite busy but I will try to post an example now and then. In the meanwhile I would like to hear about sites using Imagick, so if your project is not super secret please post an url and maybe a small explanation what you’re doing with Imagick on the site. This is purely for my personal interest.

    Anyway, to the point. Today’s example originates from a question asked by a user. How do I thumbnail the image inside given dimensions proportionally and fill the “blank” areas with a color ? Well, the answer is here :)

    The code is for Imagick 2.1.0 but adapting to older versions should not be hard.

    1. < ?php
    2. /* Define width and height of the thumbnail */
    3. $width = 100 ;
    4. $height = 100 ;
    5.  
    6. /* Instanciate and read the image in */
    7. $im = new Imagick( "test.png" ) ;
    8.  
    9. /* Fit the image into $width x $height box
    10.  The third parameter fits the image into a "bounding box" */
    11. $im->thumbnailImage( $width, $height, true ) ;
    12.  
    13. /* Create a canvas with the desired color */
    14. $canvas = new Imagick() ;
    15. $canvas->newImage( $width, $height, ’pink’, ’png’ ) ;
    16.  
    17. /* Get the image geometry */
    18. $geometry = $im->getImageGeometry() ;
    19.  
    20. /* The overlay x and y coordinates */
    21. $x = ( $width - $geometry[’width’] ) / 2 ;
    22. $y = ( $height - $geometry[’height’] ) / 2 ;
    23.  
    24. /* Composite on the canvas */
    25. $canvas->compositeImage( $im, imagick: :COMPOSITE_OVER, $x, $y ) ;
    26.  
    27. /* Output the image*/
    28. header( "Content-Type : image/png" ) ;
    29. echo $canvas ;
    30.  
    31.  ?>

    The source image :
    test.png

    The resulting image :
    testphp.png

  • Fighting with the VP8 Spec

    4 juin 2010, par Multimedia Mike — VP8

    As stated in a previous blog post on the matter, FFmpeg’s policy is to reimplement codecs rather than adopt other codebases wholesale. And so it is with Google’s recently open sourced VP8 codec, the video portion of their Webm initiative. I happen to know that the new FFmpeg implementation is in the capable hands of several of my co-developers so I’m not even worrying about that angle.

    Instead, I thought of another of my characteristically useless exercises : Create an independent VP8 decoder implementation entirely in pure Python. Silly ? Perhaps. But it has one very practical application : By attempting to write a new decoder based on the official bitstream documentation, this could serve as a mechanism for validating said spec, something near and dear to my heart.

    What is the current state of the spec ? Let me reiterate that I’m glad it exists. As I stated during the initial open sourcing event, everything that Google produced for the initial event went well beyond my wildest expectations. Having said that, the documentation does fall short in a number of places. Fortunately, I am on the Webm mailing lists and am sending in corrections and ideas for general improvement. For the most part, I have been able to understand the general ideas behind the decoding flow based on the spec and am even able to implement certain pieces correctly. Then I usually instrument the libvpx source code with output statements in order to validate that I’m doing everything right.

    Token Blocker
    Unfortunately, I’m quite blocked right now on the chapter regarding token/DCT coefficient decoding (chapter 13 in the current document iteration). In his seminal critique of the codec, Dark Shikari complained that large segments of the spec are just C code fragments copy and pasted from the official production decoder. As annoying as that is, the biggest insult comes at the end of section 13.3 :

    While we have in fact completely described the coefficient decoding procedure, the reader will probably find it helpful to consult the reference implementation, which can be found in the file detokenize.c.

    The reader most certainly will not find it helpful to consult the file detokenize.c. The file in question implements the coefficient residual decoding with an unholy sequence of C macros that contain goto statements. Honestly, I thought I did understand the coefficient decoding procedure based on the spec’s description. But my numbers don’t match up with the official decoder. Instrumenting or tracing macro’d code is obviously painful and studying the same code is making me think I don’t understand the procedure after all. To be fair, entropy decoding often occupies a lot of CPU time for many video decoders and I have little doubt that the macro/goto approach is much faster than clearer, more readable methods. It’s just highly inappropriate to refer to it for pedagogical purposes.

    Aside : For comparison, check out the reference implementation for the VC-1 codec. It was written so clearly and naively that the implementors used an O(n) Huffman decoder. That’s commitment to clarity.

    I wonder if my FFmpeg cohorts are having better luck with the DCT residue decoding in their new libavcodec implementation ? Maybe if I can get this Python decoder working, it can serve as a more appropriate reference decoder.

    Update : Almost immediately after I posted this entry, I figured out a big problem that was holding me back, and then several more small ones, and finally decoded by first correct DCT coefficient from the stream (I’ve never been so happy to see the number -448). I might be back on track now. Even better was realizing that my original understanding of the spec was correct.

    Unrelated
    I found this image on the Doom9 forums. I ROFL’d :



    It’s probably unfair and inaccurate but you have to admit it’s funny. Luckily, quality nitpickings aren’t my department. I’m just interested in getting codecs working, tested, and documented so that more people can use them reliably.