Recherche avancée

Médias (0)

Mot : - Tags -/masques

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

Autres articles (51)

  • Personnaliser en ajoutant son logo, sa bannière ou son image de fond

    5 septembre 2013, par

    Certains thèmes prennent en compte trois éléments de personnalisation : l’ajout d’un logo ; l’ajout d’une bannière l’ajout d’une image de fond ;

  • Les autorisations surchargées par les plugins

    27 avril 2010, par

    Mediaspip core
    autoriser_auteur_modifier() afin que les visiteurs soient capables de modifier leurs informations sur la page d’auteurs

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

Sur d’autres sites (4802)

  • armv6 : Accelerate ff_fft_calc for general case (nbits != 4)

    16 juillet 2014, par Ben Avison
    armv6 : Accelerate ff_fft_calc for general case (nbits != 4)

    The previous implementation targeted DTS Coherent Acoustics, which only
    
requires nbits == 4 (fft16()). This case was (and still is) linked directly
    
rather than being indirected through ff_fft_calc_vfp(), but now the full
    
range from radix-4 up to radix-65536 is available. This benefits other codecs
    
such as AAC and AC3.
    

    The implementaion is based upon the C version, with each routine larger than
    
radix-16 calling a hierarchy of smaller FFT functions, then performing a
    
post-processing pass. This pass benefits a lot from loop unrolling to
    
counter the long pipelines in the VFP. A relaxed calling standard also
    
reduces the overhead of the call hierarchy, and avoiding the excessive
    
inlining performed by GCC probably helps with I-cache utilisation too.
    

    I benchmarked the result by measuring the number of gperftools samples that
    
hit anywhere in the AAC decoder (starting from aac_decode_frame()) or
    
specifically in the FFT routines (fft4() to fft512() and pass()) for the
    
same sample AAC stream :
    

                  Before          After
    
              Mean   StdDev   Mean   StdDev  Confidence  Change
    
Audio decode  2245.5 53.1     1599.6 43.8    100.0%      +40.4%
    
FFT routines  940.6  22.0     348.1  20.8    100.0%      +170.2%
    

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

  • fate/cover-art : fix multiple dependencies

    30 juin, par Nicolas Gaullier
    fate/cover-art : fix multiple dependencies

    Signed-off-by : Nicolas Gaullier <nicolas.gaullier@cji.paris>
    
Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
    • [DH] tests/fate/cover-art.mak

  • armv6 : Accelerate ff_fft_calc for general case (nbits != 4)

    16 juillet 2014, par Ben Avison
    armv6 : Accelerate ff_fft_calc for general case (nbits != 4)

    The previous implementation targeted DTS Coherent Acoustics, which only
    
requires nbits == 4 (fft16()). This case was (and still is) linked directly
    
rather than being indirected through ff_fft_calc_vfp(), but now the full
    
range from radix-4 up to radix-65536 is available. This benefits other codecs
    
such as AAC and AC3.
    

    The implementaion is based upon the C version, with each routine larger than
    
radix-16 calling a hierarchy of smaller FFT functions, then performing a
    
post-processing pass. This pass benefits a lot from loop unrolling to
    
counter the long pipelines in the VFP. A relaxed calling standard also
    
reduces the overhead of the call hierarchy, and avoiding the excessive
    
inlining performed by GCC probably helps with I-cache utilisation too.
    

    I benchmarked the result by measuring the number of gperftools samples that
    
hit anywhere in the AAC decoder (starting from aac_decode_frame()) or
    
specifically in the FFT routines (fft4() to fft512() and pass()) for the
    
same sample AAC stream :
    

                  Before          After
    
              Mean   StdDev   Mean   StdDev  Confidence  Change
    
Audio decode  2245.5 53.1     1599.6 43.8    100.0%      +40.4%
    
FFT routines  940.6  22.0     348.1  20.8    100.0%      +170.2%
    

    Signed-off-by : Martin Storsjö <martin@martin.st>
    • [DBH] libavcodec/arm/fft_init_arm.c
    • [DBH] libavcodec/arm/fft_vfp.S

Navigation