Recherche avancée

Médias (1)

Mot : - Tags -/livre électronique

Autres articles (57)

  • Les tâches Cron régulières de la ferme

    1er décembre 2010, par

    La gestion de la ferme passe par l’exécution à intervalle régulier de plusieurs tâches répétitives dites Cron.
    Le super Cron (gestion_mutu_super_cron)
    Cette tâche, planifiée chaque minute, a pour simple effet d’appeler le Cron de l’ensemble des instances de la mutualisation régulièrement. Couplée avec un Cron système sur le site central de la mutualisation, cela permet de simplement générer des visites régulières sur les différents sites et éviter que les tâches des sites peu visités soient trop (...)

  • 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

  • Des sites réalisés avec MediaSPIP

    2 mai 2011, par

    Cette page présente quelques-uns des sites fonctionnant sous MediaSPIP.
    Vous pouvez bien entendu ajouter le votre grâce au formulaire en bas de page.

Sur d’autres sites (11269)

  • Merge commit ’d371c3c2e2830d9783465ecfe1ab7d93351083b7’

    17 mai 2013, par Michael Niedermayer
    Merge commit ’d371c3c2e2830d9783465ecfe1ab7d93351083b7’

    * commit ’d371c3c2e2830d9783465ecfe1ab7d93351083b7’ :
    
  vf_frei0r : make config_props work properly when called multiple times.
    
  vf_gradfun : make config_props work properly when called multiple times.
    
  vf_lut : make config_props work properly when called multiple times.
    

    Conflicts :
    
	libavfilter/vf_lut.c
    

    Merged-by : Michael Niedermayer <michaelni@gmx.at>
    • [DH] libavfilter/vf_frei0r.c
    • [DH] libavfilter/vf_gradfun.c
    • [DH] libavfilter/vf_lut.c

  • Further SMC Encoding Work

    25 août 2011, par Multimedia Mike — General

    Sometimes, when I don’t feel like doing anything else, I look at that Apple SMC video encoder again.

    8-bit Encoding
    When I last worked on the encoder, I couldn’t get the 8-color mode working correctly, even though the similar 2- and 4-color modes were working fine. I chalked the problem up to the extreme weirdness in the packing method unique to the 8-color mode. Remarkably, I had that logic correct the first time around. The real problem turned out to be with the 8-color cache and it was due to the vagaries of 64-bit math in C. Bit shifting an unsigned 8-bit quantity implicitly results in a signed 32-bit quantity, or so I discovered.

    Anyway, the 8-color encoding works correctly, thus shaving a few more bytes off the encoding size.

    Encoding Scheme Oddities
    The next step is to encode runs of data. This is where I noticed some algorithmic oddities in the scheme that I never really noticed before. There are 1-, 2-, 4-, 8-, and 16-color modes. Each mode allows encoding from 1-256 blocks of that same encoding. For example, the byte sequence :

      0x62 0x45

    Specifies that the next 3 4×4 blocks are encoded with single-color mode (of byte 0×62, high nibble is encoding mode and low nibble is count-1 blocks) and the palette color to be used is 0×45. Further, opcode 0×70 is the same except the following byte allows for specifying more than 16 (i.e., up to 256) blocks shall be encoded in the same matter. In light of this repeat functionality being built into the rendering opcodes, I’m puzzled by the existence of the repeat block opcodes. There are opcodes to repeat the prior block up to 256 times, and there are opcodes to repeat the prior pair of blocks up to 256 times.

    So my quandary is : What would the repeat opcodes be used for ? I hacked the FFmpeg / Libav SMC decoder to output a histogram of which opcodes are used. The repeat pair opcodes are never seen. However, the single-repeat opcodes are used a few times.

    Puzzle Solved ?
    I’m glad I wrote this post. Just as I was about to hit “Publish”, I think I figured it out. I haven’t mentioned the skip opcodes yet– there are opcodes that specify that 1-256 4×4 blocks are unchanged from the previous frame. Conceivably, a block could be unchanged from the previous frame and then repeated 1-256 times from there.

    That’s something I hadn’t thought of up to this point for my proposed algorithm and will require a little more work.

    Further reading

  • blending mp4s with opacity in ffmpeg

    29 mai 2021, par Cam

    I simply need to understand the command to blend a set of mp4s together with layered opacity (say 0.1 each mp4 ) and retain the color accuracy of each layered mp4. All videos are the same length and type.

    &#xA;

    I am creating the source mp4s from a list of pngs in this format :

    &#xA;

    -vcodec libx264 -crf 0 -pix_fmt yuv420p&#xA;

    &#xA;

    However, when I loop through and combine them into a single output mp4 using the following arguments, I get odd colors that seem to be hue shifted somehow ?

    &#xA;

    -vcodec libx264 -crf 0 -pix_fmt yuv420p  -filter_complex "blend=all_mode=&#x27;overlay&#x27;:all_opacity=0.1"&#xA;

    &#xA;

    I understand the 'brightness' will be somewhat lost using this process, which is fine. Its the underlying colors I need to retain though.

    &#xA;

    I feel like this should be simple but I am hitting a wall. Thanks

    &#xA;

Navigation