Recherche avancée

Médias (16)

Mot : - Tags -/mp3

Autres articles (68)

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

  • De l’upload à la vidéo finale [version standalone]

    31 janvier 2010, par

    Le chemin d’un document audio ou vidéo dans SPIPMotion est divisé en trois étapes distinctes.
    Upload et récupération d’informations de la vidéo source
    Dans un premier temps, il est nécessaire de créer un article SPIP et de lui joindre le document vidéo "source".
    Au moment où ce document est joint à l’article, deux actions supplémentaires au comportement normal sont exécutées : La récupération des informations techniques des flux audio et video du fichier ; La génération d’une vignette : extraction d’une (...)

  • Librairies et binaires spécifiques au traitement vidéo et sonore

    31 janvier 2010, par

    Les logiciels et librairies suivantes sont utilisées par SPIPmotion d’une manière ou d’une autre.
    Binaires obligatoires FFMpeg : encodeur principal, permet de transcoder presque tous les types de fichiers vidéo et sonores dans les formats lisibles sur Internet. CF ce tutoriel pour son installation ; Oggz-tools : outils d’inspection de fichiers ogg ; Mediainfo : récupération d’informations depuis la plupart des formats vidéos et sonores ;
    Binaires complémentaires et facultatifs flvtool2 : (...)

Sur d’autres sites (11658)

  • aacenc_ltp : adjust and speed up autocorrelation calculations

    17 octobre 2015, par Rostislav Pehlivanov
    aacenc_ltp : adjust and speed up autocorrelation calculations

    There were some errors in the calculation as well as an entire
    
unnecessary loop to find the gain coefficient. Merge the
    
two loops.
    
Thanks to @ubitux for the suggestions and testing.
    • [DH] libavcodec/aacenc_ltp.c
    • [DH] tests/fate/aac.mak

  • lavc/mjpegdec : speed up scan data copy

    26 janvier 2016, par Matthieu Bouron
    lavc/mjpegdec : speed up scan data copy
    • [DH] libavcodec/mjpegdec.c

  • avutil/mathematics : speed up av_gcd by using Stein’s binary GCD algorithm

    11 octobre 2015, par Ganesh Ajjanagadde
    avutil/mathematics : speed up av_gcd by using Stein’s binary GCD algorithm

    This uses Stein’s binary GCD algorithm :
    
https://en.wikipedia.org/wiki/Binary_GCD_algorithm
    
to get a roughly 4x speedup over Euclidean GCD on standard architectures
    
with a compiler intrinsic for ctzll, and a roughly 2x speedup otherwise.
    
At the moment, the compiler intrinsic is used on GCC and Clang due to
    
its easy availability.
    

    Quick note regarding overflow : yes, subtractions on int64_t can, but the
    
llabs takes care of that. The llabs is also guaranteed to be safe, with
    
no annoying INT64_MIN business since INT64_MIN being a power of 2, is
    
shifted down before being sent to llabs.
    

    The binary GCD needs ff_ctzll, an extension of ff_ctz for long long (int64_t). On
    
GCC, this is provided by a built-in. On Microsoft, there is a
    
BitScanForward64 analog of BitScanForward that should work ; but I can’t confirm.
    
Apparently it is not available on 32 bit builds ; so this may or may not
    
work correctly. On Intel, per the documentation there is only an
    
intrinsic for _bit_scan_forward and people have posted on forums
    
regarding _bit_scan_forward64, but often their documentation is
    
woeful. Again, I don’t have it, so I can’t test.
    

    As such, to be safe, for now only the GCC/Clang intrinsic is added, the rest
    
use a compiled version based on the De-Bruijn method of Leiserson et al :
    
http://supertech.csail.mit.edu/papers/debruijn.pdf.
    

    Tested with FATE, sample benchmark (x86-64, GCC 5.2.0, Haswell)
    
with a START_TIMER and STOP_TIMER in libavutil/rationsl.c, followed by a
    
make fate.
    

    aac-am00_88.err :
    
builtin :
    
714 decicycles in av_gcd,    4095 runs,      1 skips
    

    de-bruijn :
    
1440 decicycles in av_gcd,    4096 runs,      0 skips
    

    previous :
    
2889 decicycles in av_gcd,    4096 runs,      0 skips
    

    Signed-off-by : Ganesh Ajjanagadde <gajjanagadde@gmail.com>
    
Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
    • [DH] libavutil/intmath.h
    • [DH] libavutil/mathematics.c

Navigation