Recherche avancée

Médias (2)

Mot : - Tags -/map

Autres articles (40)

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

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

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

Sur d’autres sites (6042)

  • swresample/resample : speed up build_filter by 50%

    4 novembre 2015, par Ganesh Ajjanagadde
    swresample/resample : speed up build_filter by 50%
    

    This speeds up build_filter by 50%. This gain should be pretty
    consistent across all architectures and platforms.

    Essentially, this relies on a observation that the filters have some
    even/odd symmetry that may be exploited during the construction of the
    polyphase filter bank. In particular, phases (scaled to [0, 1]) in [0.5, 1] are
    easily derived from [0, 0.5] and expensive reevaluation of function
    points are unnecessary. This requires some rather annoying even/odd
    bookkeeping as can be seen from the patch.

    I vaguely recall from signal processing theory more general symmetries allowing even greater
    optimization of the construction. At a high level, "even functions"
    correspond to 2, and one can imagine variations. Nevertheless, for the sake
    of some generality and because of existing filters, this is all that is
    being exploited.

    Currently, this patch relies on phase_count being even or (trivially) 1,
    though this is not an inherent limitation to the approach. This
    assumption is safe as phase_count is 1 << phase_bits, and is hence a
    power of two. There is no way for user API to set it to a nontrivial odd
    number. This assumption has been placed as an assert in the code.

    To repeat, this assumes even symmetry of the filters, which is the most common
    way to get generalized linear phase anyway and is true of all currently
    supported filters.

    As a side note, accuracy should be identical or perhaps slightly better
    due to this "forcing" filter symmetries leading to a better phase
    characteristic. As before, I can’t test this claim easily, though it may
    be of interest.

    Patch tested with FATE.

    Sample benchmark (x86-64, Haswell, GNU/Linux) :

    test : swr-resample-dblp-44100-2626

    new :
    527376779 decicycles in build_filter(loop 1000), 256 runs, 0 skips
    524361765 decicycles in build_filter(loop 1000), 512 runs, 0 skips
    516552574 decicycles in build_filter(loop 1000), 1024 runs, 0 skips

    old :
    974178658 decicycles in build_filter(loop 1000), 256 runs, 0 skips
    972794408 decicycles in build_filter(loop 1000), 512 runs, 0 skips
    954350046 decicycles in build_filter(loop 1000), 1024 runs, 0 skips

    Note that lower level optimizations are entirely possible, I focussed on
    getting the high level semantics correct. In any case, this should
    provide a good foundation.

    Reviewed-by : Michael Niedermayer <michael@niedermayer.cc>
    Signed-off-by : Ganesh Ajjanagadde <gajjanagadde@gmail.com>

    • [DH] libswresample/resample.c
  • 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