Recherche avancée

Médias (0)

Mot : - Tags -/upload

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

Autres articles (59)

  • Support de tous types de médias

    10 avril 2011

    Contrairement à beaucoup de logiciels et autres plate-formes modernes de partage de documents, MediaSPIP a l’ambition de gérer un maximum de formats de documents différents qu’ils soient de type : images (png, gif, jpg, bmp et autres...) ; audio (MP3, Ogg, Wav et autres...) ; vidéo (Avi, MP4, Ogv, mpg, mov, wmv et autres...) ; contenu textuel, code ou autres (open office, microsoft office (tableur, présentation), web (html, css), LaTeX, Google Earth) (...)

  • (Dés)Activation de fonctionnalités (plugins)

    18 février 2011, par

    Pour gérer l’ajout et la suppression de fonctionnalités supplémentaires (ou plugins), MediaSPIP utilise à partir de la version 0.2 SVP.
    SVP permet l’activation facile de plugins depuis l’espace de configuration de MediaSPIP.
    Pour y accéder, il suffit de se rendre dans l’espace de configuration puis de se rendre sur la page "Gestion des plugins".
    MediaSPIP est fourni par défaut avec l’ensemble des plugins dits "compatibles", ils ont été testés et intégrés afin de fonctionner parfaitement avec chaque (...)

  • Le plugin : Podcasts.

    14 juillet 2010, par

    Le problème du podcasting est à nouveau un problème révélateur de la normalisation des transports de données sur Internet.
    Deux formats intéressants existent : Celui développé par Apple, très axé sur l’utilisation d’iTunes dont la SPEC est ici ; Le format "Media RSS Module" qui est plus "libre" notamment soutenu par Yahoo et le logiciel Miro ;
    Types de fichiers supportés dans les flux
    Le format d’Apple n’autorise que les formats suivants dans ses flux : .mp3 audio/mpeg .m4a audio/x-m4a .mp4 (...)

Sur d’autres sites (6296)

  • 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