Recherche avancée

Médias (91)

Autres articles (63)

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

  • Support audio et vidéo HTML5

    10 avril 2011

    MediaSPIP utilise les balises HTML5 video et audio pour la lecture de documents multimedia en profitant des dernières innovations du W3C supportées par les navigateurs modernes.
    Pour les navigateurs plus anciens, le lecteur flash Flowplayer est utilisé.
    Le lecteur HTML5 utilisé a été spécifiquement créé pour MediaSPIP : il est complètement modifiable graphiquement pour correspondre à un thème choisi.
    Ces technologies permettent de distribuer vidéo et son à la fois sur des ordinateurs conventionnels (...)

  • MediaSPIP Init et Diogène : types de publications de MediaSPIP

    11 novembre 2010, par

    À l’installation d’un site MediaSPIP, le plugin MediaSPIP Init réalise certaines opérations dont la principale consiste à créer quatre rubriques principales dans le site et de créer cinq templates de formulaire pour Diogène.
    Ces quatre rubriques principales (aussi appelées secteurs) sont : Medias ; Sites ; Editos ; Actualités ;
    Pour chacune de ces rubriques est créé un template de formulaire spécifique éponyme. Pour la rubrique "Medias" un second template "catégorie" est créé permettant d’ajouter (...)

Sur d’autres sites (6058)

  • 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

Navigation