Recherche avancée

Médias (1)

Mot : - Tags -/ogg

Autres articles (65)

  • La file d’attente de SPIPmotion

    28 novembre 2010, par

    Une file d’attente stockée dans la base de donnée
    Lors de son installation, SPIPmotion crée une nouvelle table dans la base de donnée intitulée spip_spipmotion_attentes.
    Cette nouvelle table est constituée des champs suivants : id_spipmotion_attente, l’identifiant numérique unique de la tâche à traiter ; id_document, l’identifiant numérique du document original à encoder ; id_objet l’identifiant unique de l’objet auquel le document encodé devra être attaché automatiquement ; objet, le type d’objet auquel (...)

  • Amélioration de la version de base

    13 septembre 2013

    Jolie sélection multiple
    Le plugin Chosen permet d’améliorer l’ergonomie des champs de sélection multiple. Voir les deux images suivantes pour comparer.
    Il suffit pour cela d’activer le plugin Chosen (Configuration générale du site > Gestion des plugins), puis de configurer le plugin (Les squelettes > Chosen) en activant l’utilisation de Chosen dans le site public et en spécifiant les éléments de formulaires à améliorer, par exemple select[multiple] pour les listes à sélection multiple (...)

  • Menus personnalisés

    14 novembre 2010, par

    MediaSPIP utilise le plugin Menus pour gérer plusieurs menus configurables pour la navigation.
    Cela permet de laisser aux administrateurs de canaux la possibilité de configurer finement ces menus.
    Menus créés à l’initialisation du site
    Par défaut trois menus sont créés automatiquement à l’initialisation du site : Le menu principal ; Identifiant : barrenav ; Ce menu s’insère en général en haut de la page après le bloc d’entête, son identifiant le rend compatible avec les squelettes basés sur Zpip ; (...)

Sur d’autres sites (10151)

  • aarch64 : vp9 : Implement NEON loop filters

    14 novembre 2016, par Martin Storsjö
    aarch64 : vp9 : Implement NEON loop filters

    This work is sponsored by, and copyright, Google.
    

    These are ported from the ARM version ; thanks to the larger
    
amount of registers available, we can do the loop filters with
    
16 pixels at a time. The implementation is fully templated, with
    
a single macro which can generate versions for both 8 and
    
16 pixels wide, for both 4, 8 and 16 pixels loop filters
    
(and the 4/8 mixed versions as well).
    

    For the 8 pixel wide versions, it is pretty close in speed (the
    
v_4_8 and v_8_8 filters are the best examples of this ; the h_4_8
    
and h_8_8 filters seem to get some gain in the load/transpose/store
    
part). For the 16 pixels wide ones, we get a speedup of around
    
1.2-1.4x compared to the 32 bit version.
    

    Examples of runtimes vs the 32 bit version, on a Cortex A53 :
    
                                       ARM AArch64
    
vp9_loop_filter_h_4_8_neon :          144.0   127.2
    
vp9_loop_filter_h_8_8_neon :          207.0   182.5
    
vp9_loop_filter_h_16_8_neon :         415.0   328.7
    
vp9_loop_filter_h_16_16_neon :        672.0   558.6
    
vp9_loop_filter_mix2_h_44_16_neon :   302.0   203.5
    
vp9_loop_filter_mix2_h_48_16_neon :   365.0   305.2
    
vp9_loop_filter_mix2_h_84_16_neon :   365.0   305.2
    
vp9_loop_filter_mix2_h_88_16_neon :   376.0   305.2
    
vp9_loop_filter_mix2_v_44_16_neon :   193.2   128.2
    
vp9_loop_filter_mix2_v_48_16_neon :   246.7   218.4
    
vp9_loop_filter_mix2_v_84_16_neon :   248.0   218.5
    
vp9_loop_filter_mix2_v_88_16_neon :   302.0   218.2
    
vp9_loop_filter_v_4_8_neon :           89.0    88.7
    
vp9_loop_filter_v_8_8_neon :          141.0   137.7
    
vp9_loop_filter_v_16_8_neon :         295.0   272.7
    
vp9_loop_filter_v_16_16_neon :        546.0   453.7
    

    The speedup vs C code in checkasm tests is around 2-7x, which is
    
pretty much the same as for the 32 bit version. Even if these functions
    
are faster than their 32 bit equivalent, the C version that we compare
    
to also became around 1.3-1.7x faster than the C version in 32 bit.
    

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

    Examples of runtimes vs C on a Cortex A57 (for a slightly older version
    
of the patch) :
    
                         A57 gcc-5.3  neon
    
loop_filter_h_4_8_neon :        256.6  93.4
    
loop_filter_h_8_8_neon :        307.3 139.1
    
loop_filter_h_16_8_neon :       340.1 254.1
    
loop_filter_h_16_16_neon :      827.0 407.9
    
loop_filter_mix2_h_44_16_neon : 524.5 155.4
    
loop_filter_mix2_h_48_16_neon : 644.5 173.3
    
loop_filter_mix2_h_84_16_neon : 630.5 222.0
    
loop_filter_mix2_h_88_16_neon : 697.3 222.0
    
loop_filter_mix2_v_44_16_neon : 598.5 100.6
    
loop_filter_mix2_v_48_16_neon : 651.5 127.0
    
loop_filter_mix2_v_84_16_neon : 591.5 167.1
    
loop_filter_mix2_v_88_16_neon : 855.1 166.7
    
loop_filter_v_4_8_neon :        271.7  65.3
    
loop_filter_v_8_8_neon :        312.5 106.9
    
loop_filter_v_16_8_neon :       473.3 206.5
    
loop_filter_v_16_16_neon :      976.1 327.8
    

    The speed-up compared to the C functions is 2.5 to 6 and the cortex-a57
    
is again 30-50% faster than the cortex-a53.
    

    This is an adapted cherry-pick from libav commits
    
9d2afd1eb8c5cc0633062430e66326dbf98c99e0 and
    
31756abe29eb039a11c59a42cb12e0cc2aef3b97.
    

    Signed-off-by : Ronald S. Bultje <rsbultje@gmail.com>
    • [DH] libavcodec/aarch64/Makefile
    • [DH] libavcodec/aarch64/vp9dsp_init_aarch64.c
    • [DH] libavcodec/aarch64/vp9lpf_neon.S

  • fate : Avoid unnecessary pixel format conversions

    30 juin 2015, par Martin Storsjö
    fate : Avoid unnecessary pixel format conversions

    Most of the fate-dds-* and fate-txd-* tests already
    
output into the same pixel format regardless of
    
platform endianness, so there’s no need to force
    
conversion to another format.
    

    This fixes the tests fate-txd-16bpp, fate-txd-odd,
    
fate-dds-rgb16, fate-dds-rgb24 and fate-dds-xrgb on
    
big endian, where the tests seem to fail due to issues
    
with certain conversion codepaths in swscale.
    

    Those conversion codepaths should of course be fixed, but
    
the individual decoder tests should use as little extra
    
conversion steps as possible.
    

    Signed-off-by : Martin Storsjö <martin@martin.st>
    • [DH] tests/fate/image.mak
    • [DH] tests/fate/video.mak
    • [DH] tests/ref/fate/dds-rgb16
    • [DH] tests/ref/fate/dds-rgb24
    • [DH] tests/ref/fate/dds-uyvy
    • [DH] tests/ref/fate/dds-xbgr
    • [DH] tests/ref/fate/dds-y
    • [DH] tests/ref/fate/dds-ya
    • [DH] tests/ref/fate/dds-yuyv
    • [DH] tests/ref/fate/txd-16bpp
    • [DH] tests/ref/fate/txd-odd

  • fftools/ffmpeg : add thread-aware transcode scheduling infrastructure

    18 mai 2023, par Anton Khirnov
    fftools/ffmpeg : add thread-aware transcode scheduling infrastructure

    See the comment block at the top of fftools/ffmpeg_sched.h for more
    
details on what this scheduler is for.
    

    This commit adds the scheduling code itself, along with minimal
    
integration with the rest of the program :
    
* allocating and freeing the scheduler
    
* passing it throughout the call stack in order to register the
    
  individual components (demuxers/decoders/filtergraphs/encoders/muxers)
    
  with the scheduler
    

    The scheduler is not actually used as of this commit, so it should not
    
result in any change in behavior. That will change in future commits.
    • [DH] fftools/Makefile
    • [DH] fftools/ffmpeg.c
    • [DH] fftools/ffmpeg.h
    • [DH] fftools/ffmpeg_dec.c
    • [DH] fftools/ffmpeg_demux.c
    • [DH] fftools/ffmpeg_enc.c
    • [DH] fftools/ffmpeg_filter.c
    • [DH] fftools/ffmpeg_mux.c
    • [DH] fftools/ffmpeg_mux.h
    • [DH] fftools/ffmpeg_mux_init.c
    • [DH] fftools/ffmpeg_opt.c
    • [DH] fftools/ffmpeg_sched.c
    • [DH] fftools/ffmpeg_sched.h

Navigation