Recherche avancée

Médias (3)

Mot : - Tags -/collection

Autres articles (81)

  • Ajouter des informations spécifiques aux utilisateurs et autres modifications de comportement liées aux auteurs

    12 avril 2011, par

    La manière la plus simple d’ajouter des informations aux auteurs est d’installer le plugin Inscription3. Il permet également de modifier certains comportements liés aux utilisateurs (référez-vous à sa documentation pour plus d’informations).
    Il est également possible d’ajouter des champs aux auteurs en installant les plugins champs extras 2 et Interface pour champs extras.

  • Problèmes fréquents

    10 mars 2010, par

    PHP et safe_mode activé
    Une des principales sources de problèmes relève de la configuration de PHP et notamment de l’activation du safe_mode
    La solution consiterait à soit désactiver le safe_mode soit placer le script dans un répertoire accessible par apache pour le site

  • MediaSPIP 0.1 Beta version

    25 avril 2011, par

    MediaSPIP 0.1 beta is the first version of MediaSPIP proclaimed as "usable".
    The zip file provided here only contains the sources of MediaSPIP in its standalone version.
    To get a working installation, you must manually install all-software dependencies on the server.
    If you want to use this archive for an installation in "farm mode", you will also need to proceed to other manual (...)

Sur d’autres sites (12984)

  • 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

  • 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

  • arm : Add NEON optimizations for 10 and 12 bit vp9 loop filter

    5 janvier 2017, par Martin Storsjö
    arm : Add NEON optimizations for 10 and 12 bit vp9 loop filter

    This work is sponsored by, and copyright, Google.
    

    This is pretty much similar to the 8 bpp version, but in some senses
    
simpler. All input pixels are 16 bits, and all intermediates also fit
    
in 16 bits, so there’s no lengthening/narrowing in the filter at all.
    

    For the full 16 pixel wide filter, we can only process 4 pixels at a time
    
(using an implementation very much similar to the one for 8 bpp),
    
but we can do 8 pixels at a time for the 4 and 8 pixel wide filters with
    
a different implementation of the core filter.
    

    Examples of relative speedup compared to the C version, from checkasm :
    
                                   Cortex    A7     A8     A9    A53
    
vp9_loop_filter_h_4_8_10bpp_neon :          1.83   2.16   1.40   2.09
    
vp9_loop_filter_h_8_8_10bpp_neon :          1.39   1.67   1.24   1.70
    
vp9_loop_filter_h_16_8_10bpp_neon :         1.56   1.47   1.10   1.81
    
vp9_loop_filter_h_16_16_10bpp_neon :        1.94   1.69   1.33   2.24
    
vp9_loop_filter_mix2_h_44_16_10bpp_neon :   2.01   2.27   1.67   2.39
    
vp9_loop_filter_mix2_h_48_16_10bpp_neon :   1.84   2.06   1.45   2.19
    
vp9_loop_filter_mix2_h_84_16_10bpp_neon :   1.89   2.20   1.47   2.29
    
vp9_loop_filter_mix2_h_88_16_10bpp_neon :   1.69   2.12   1.47   2.08
    
vp9_loop_filter_mix2_v_44_16_10bpp_neon :   3.16   3.98   2.50   4.05
    
vp9_loop_filter_mix2_v_48_16_10bpp_neon :   2.84   3.64   2.25   3.77
    
vp9_loop_filter_mix2_v_84_16_10bpp_neon :   2.65   3.45   2.16   3.54
    
vp9_loop_filter_mix2_v_88_16_10bpp_neon :   2.55   3.30   2.16   3.55
    
vp9_loop_filter_v_4_8_10bpp_neon :          2.85   3.97   2.24   3.68
    
vp9_loop_filter_v_8_8_10bpp_neon :          2.27   3.19   1.96   3.08
    
vp9_loop_filter_v_16_8_10bpp_neon :         3.42   2.74   2.26   4.40
    
vp9_loop_filter_v_16_16_10bpp_neon :        2.86   2.44   1.93   3.88
    

    The speedup vs C code measured in checkasm is around 1.1-4x.
    
These numbers are quite inconclusive though, since the checkasm test
    
runs multiple filterings on top of each other, so later rounds might
    
end up with different codepaths (different decisions on which filter
    
to apply, based on input pixel differences).
    

    Based on START_TIMER/STOP_TIMER wrapping around a few individual
    
functions, the speedup vs C code is around 2-4x.
    

    Signed-off-by : Martin Storsjö <martin@martin.st>
    • [DH] libavcodec/arm/Makefile
    • [DH] libavcodec/arm/vp9dsp_init_16bpp_arm_template.c
    • [DH] libavcodec/arm/vp9lpf_16bpp_neon.S

Navigation