Recherche avancée

Médias (0)

Mot : - Tags -/objet éditorial

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

Autres articles (27)

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

  • Revision 51c60a891e : make default_interp_filter choice a speed feature This commit changed the hard-

    16 juillet 2014, par Yaowu Xu

    Changed Paths :
     Modify /vp9/encoder/vp9_encoder.c


     Modify /vp9/encoder/vp9_speed_features.c


     Modify /vp9/encoder/vp9_speed_features.h



    make default_interp_filter choice a speed feature

    This commit changed the hard-coded DEFAULT_INTERP_FILTER to a speed
    feature with the same default value : SWITCHABLE.

    Change-Id : I7f54f40f1bd3f5277841d04b85db7a84e47313f1

  • Revision 62c6411820 : Remove neon version of vp8 extend borders The code fails the unit test. Speed c

    24 juillet 2014, par Johann

    Changed Paths :
     Modify /test/scale_border_test.cc


     Delete /vpx_scale/arm/neon/vp8_vpxyv12_extendframeborders_neon.asm


     Modify /vpx_scale/arm/neon/yv12extend_arm.c


     Modify /vpx_scale/vpx_scale.mk


     Modify /vpx_scale/vpx_scale_rtcd.pl



    Remove neon version of vp8 extend borders

    The code fails the unit test. Speed comparisons to the C are invalid
    because the code frequently didn’t correctly extend the right and
    bottom portions of the frame.

    Reduce maximum frame size on ARM devices to avoid OOM

    Change-Id : Ia664c86406f0bb8120fd7ad401f32d0bd44994fb

  • Android built in Camera encoder VS FFMPEG --- Speed

    3 novembre 2015, par user3903275

    How does recording a 1080P, H264 encoded video in android camera application is realtime fast but encoding a video in android using FFMPEG is slow at the same video size ?

    I know FFMPEG is a software level encoder and it wont support any hardware features.

    I know camera applications directly get buffer data from camera driver.

    But actually where the difference happens ??

    Why camera application is Realtime fast ???

    Does it use GPU and OpenGL features of the phone to encode the video so that its so realtime fast ??

    Because both Camera Application and FFMPEG runs on same mobile but still camera encodes H264 realtime ???

Navigation