Recherche avancée

Médias (0)

Mot : - Tags -/xmlrpc

Aucun média correspondant à vos critères n’est disponible sur le site.

Autres articles (68)

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

  • HTML5 audio and video support

    13 avril 2011, par

    MediaSPIP uses HTML5 video and audio tags to play multimedia files, taking advantage of the latest W3C innovations supported by modern browsers.
    The MediaSPIP player used has been created specifically for MediaSPIP and can be easily adapted to fit in with a specific theme.
    For older browsers the Flowplayer flash fallback is used.
    MediaSPIP allows for media playback on major mobile platforms with the above (...)

  • Encoding and processing into web-friendly formats

    13 avril 2011, par

    MediaSPIP automatically converts uploaded files to internet-compatible formats.
    Video files are encoded in MP4, Ogv and WebM (supported by HTML5) and MP4 (supported by Flash).
    Audio files are encoded in MP3 and Ogg (supported by HTML5) and MP3 (supported by Flash).
    Where possible, text is analyzed in order to retrieve the data needed for search engine detection, and then exported as a series of image files.
    All uploaded files are stored online in their original format, so you can (...)

Sur d’autres sites (4793)

  • Writing linear float range to openEXR turns out non linear

    3 avril 2022, par Chryfi

    I am writing the linearized depth buffer of a game to openEXR using FFmpeg. Unfortunately, FFmpeg does not adhere to the openEXR file specification fully (like allowing unsigned integer for one channel) so I am writing one float channel to openEXR, which is put into the green channel with this command -f rawvideo -pix_fmt grayf32be -s %WIDTH%x%HEIGHT% -r %FPS% -i - -vf %DEFVF% -preset ultrafast -tune zerolatency -qp 6 -compression zip1 -pix_fmt gbrpf32le %NAME%_depth_%d.exr.

    


    The float range is from 0F to 1F and it is linear. I can confirm that the calculation and linearization is correct by testing 16 bit integer (per pixel component) PNG in Blender compositor. The 16 bit integer data is written like this short s = (short) (linearzieDepth(depth) * (Math.pow(2,16) - 1)) whereas for float the linearized value is directly written to OpenEXR without multiplying with a value.

    


    However, when viewing the openEXR file it doesn't have the same "gradient" as the 16 bit png... when viewing them side by side, it appears as if the values near 0 are not linear, and they are not as dark as they should be like in the 16 bit png.
(And yes, I set the image node to linear), and comparing it with 3d tracking data from the game I cant reproduce the depth and cant mask things using the depth buffer where as with the png I can.

    


    How is it possible for a linear float range to turn out so different to a linear integer range in an image ?

    


  • Anomalie #3370 (Nouveau) : fichier local_xx.php sous SPIP 3.1 demande le prefix ?

    29 décembre 2014, par Debondt Didier

    Hello,

    Je suis en train de jouer avec SPIP 3.1 et je constate que le fichier local_xx demande un prefix pour être utilisé.

    Par exemple je dois faire <:local:modifier_compte :> alors qu’avant j’utilisais <:modifier_compte :>. Même constat pour la fonction _T.
    Cela risque de casser pas mal de chose non ?

    J’utilise SPIP 3.1.0-alpha [21890] et PHP Version 5.5.12-2ubuntu4.1.

  • Merge commit ’25a6666f6c07c6ac8449a63d7fbce0dfd29c54cd’

    15 juillet 2013, par Michael Niedermayer
    Merge commit ’25a6666f6c07c6ac8449a63d7fbce0dfd29c54cd’

    * commit ’25a6666f6c07c6ac8449a63d7fbce0dfd29c54cd’ :
    
  indeo : Bound-check before applying motion compensation
    

    The added checks and one previously added check are replaced by asserts,
    
the conditions can only be
    
true when vectors are invalid or there are worse inconsistencies.
    
We are checking the vectors validity and there should be no
    
inconsistencies, thus the checks should not be needed.
    
Also no files are known to cause any anomalies in ffmpeg
    

    Merged-by : Michael Niedermayer <michaelni@gmx.at>
    • [DH] libavcodec/ivi_common.c

Navigation