Recherche avancée

Médias (0)

Mot : - Tags -/xmlrpc

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

Autres articles (17)

  • ANNEXE : Les extensions, plugins SPIP des canaux

    11 février 2010, par

    Un plugin est un ajout fonctionnel au noyau principal de SPIP. MediaSPIP consiste en un choix délibéré de plugins existant ou pas auparavant dans la communauté SPIP, qui ont pour certains nécessité soit leur création de A à Z, soit des ajouts de fonctionnalités.
    Les extensions que MediaSPIP nécessite pour fonctionner
    Depuis la version 2.1.0, SPIP permet d’ajouter des plugins dans le répertoire extensions/.
    Les "extensions" ne sont ni plus ni moins que des plugins dont la particularité est qu’ils se (...)

  • MediaSPIP Core : La Configuration

    9 novembre 2010, par

    MediaSPIP Core fournit par défaut trois pages différentes de configuration (ces pages utilisent le plugin de configuration CFG pour fonctionner) : une page spécifique à la configuration générale du squelettes ; une page spécifique à la configuration de la page d’accueil du site ; une page spécifique à la configuration des secteurs ;
    Il fournit également une page supplémentaire qui n’apparait que lorsque certains plugins sont activés permettant de contrôler l’affichage et les fonctionnalités spécifiques (...)

  • Support de tous types de médias

    10 avril 2011

    Contrairement à beaucoup de logiciels et autres plate-formes modernes de partage de documents, MediaSPIP a l’ambition de gérer un maximum de formats de documents différents qu’ils soient de type : images (png, gif, jpg, bmp et autres...) ; audio (MP3, Ogg, Wav et autres...) ; vidéo (Avi, MP4, Ogv, mpg, mov, wmv et autres...) ; contenu textuel, code ou autres (open office, microsoft office (tableur, présentation), web (html, css), LaTeX, Google Earth) (...)

Sur d’autres sites (5818)

  • lavu : add an API function to return the Libav version string

    2 juillet 2015, par wm4
    lavu : add an API function to return the Libav version string
    

    This returns something like "v12_dev0-1332-g333a27c". This is much more
    useful than the individual library versions, of which there are too
    many, and which are very hard to map back to releases or git commits.

    Signed-off-by : Janne Grunau <janne-libav@jannau.net>

    • [DBH] .gitignore
    • [DBH] Makefile
    • [DBH] cmdutils.c
    • [DBH] doc/APIchanges
    • [DBH] libavutil/avutil.h
    • [DBH] libavutil/utils.c
  • lavf : Add an MPEG-DASH ISOFF segmenting muxer

    6 octobre 2014, par Martin Storsjö
    lavf : Add an MPEG-DASH ISOFF segmenting muxer
    

    This is mostly to serve as a reference example on how to segment
    the output from the mp4 muxer, capable of writing the segment
    list in four different ways :
    - SegmentTemplate with SegmentTimeline
    - SegmentTemplate with implicit segments
    - SegmentList with individual files
    - SegmentList with one single file per track, and byte ranges

    The muxer is able to serve live content (with optional windowing)
    or create a static segmented MPD.

    In advanced cases, users will probably want to do the segmenting
    in their own application code.

    Signed-off-by : Martin Storsjö <martin@martin.st>

    • [DH] Changelog
    • [DH] configure
    • [DH] libavformat/Makefile
    • [DH] libavformat/allformats.c
    • [DH] libavformat/dashenc.c
    • [DH] libavformat/version.h
  • aarch64 : vp9itxfm : Do separate functions for half/quarter idct16 and idct32

    22 novembre 2016, par Martin Storsjö
    aarch64 : vp9itxfm : Do separate functions for half/quarter idct16 and idct32
    

    This work is sponsored by, and copyright, Google.

    This avoids loading and calculating coefficients that we know will
    be zero, and avoids filling the temp buffer with zeros in places
    where we know the second pass won’t read.

    This gives a pretty substantial speedup for the smaller subpartitions.

    The code size increases from 14740 bytes to 24292 bytes.

    The idct16/32_end macros are moved above the individual functions ; the
    instructions themselves are unchanged, but since new functions are added
    at the same place where the code is moved from, the diff looks rather
    messy.

    Before :
    vp9_inv_dct_dct_16x16_sub1_add_neon : 236.7
    vp9_inv_dct_dct_16x16_sub2_add_neon : 1051.0
    vp9_inv_dct_dct_16x16_sub4_add_neon : 1051.0
    vp9_inv_dct_dct_16x16_sub8_add_neon : 1051.0
    vp9_inv_dct_dct_16x16_sub12_add_neon : 1387.4
    vp9_inv_dct_dct_16x16_sub16_add_neon : 1387.6
    vp9_inv_dct_dct_32x32_sub1_add_neon : 554.1
    vp9_inv_dct_dct_32x32_sub2_add_neon : 5198.5
    vp9_inv_dct_dct_32x32_sub4_add_neon : 5198.6
    vp9_inv_dct_dct_32x32_sub8_add_neon : 5196.3
    vp9_inv_dct_dct_32x32_sub12_add_neon : 6183.4
    vp9_inv_dct_dct_32x32_sub16_add_neon : 6174.3
    vp9_inv_dct_dct_32x32_sub20_add_neon : 7151.4
    vp9_inv_dct_dct_32x32_sub24_add_neon : 7145.3
    vp9_inv_dct_dct_32x32_sub28_add_neon : 8119.3
    vp9_inv_dct_dct_32x32_sub32_add_neon : 8118.7

    After :
    vp9_inv_dct_dct_16x16_sub1_add_neon : 236.7
    vp9_inv_dct_dct_16x16_sub2_add_neon : 640.8
    vp9_inv_dct_dct_16x16_sub4_add_neon : 639.0
    vp9_inv_dct_dct_16x16_sub8_add_neon : 842.0
    vp9_inv_dct_dct_16x16_sub12_add_neon : 1388.3
    vp9_inv_dct_dct_16x16_sub16_add_neon : 1389.3
    vp9_inv_dct_dct_32x32_sub1_add_neon : 554.1
    vp9_inv_dct_dct_32x32_sub2_add_neon : 3685.5
    vp9_inv_dct_dct_32x32_sub4_add_neon : 3685.1
    vp9_inv_dct_dct_32x32_sub8_add_neon : 3684.4
    vp9_inv_dct_dct_32x32_sub12_add_neon : 5312.2
    vp9_inv_dct_dct_32x32_sub16_add_neon : 5315.4
    vp9_inv_dct_dct_32x32_sub20_add_neon : 7154.9
    vp9_inv_dct_dct_32x32_sub24_add_neon : 7154.5
    vp9_inv_dct_dct_32x32_sub28_add_neon : 8126.6
    vp9_inv_dct_dct_32x32_sub32_add_neon : 8127.2

    Signed-off-by : Martin Storsjö <martin@martin.st>

    • [DBH] libavcodec/aarch64/vp9itxfm_neon.S