Recherche avancée

Médias (91)

Autres articles (78)

  • MediaSPIP 0.1 Beta version

    25 avril 2011, par

    MediaSPIP 0.1 beta is the first version of MediaSPIP proclaimed as "usable".
    The zip file provided here only contains the sources of MediaSPIP in its standalone version.
    To get a working installation, you must manually install all-software dependencies on the server.
    If you want to use this archive for an installation in "farm mode", you will also need to proceed to other manual (...)

  • MediaSPIP version 0.1 Beta

    16 avril 2011, par

    MediaSPIP 0.1 beta est la première version de MediaSPIP décrétée comme "utilisable".
    Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
    Pour avoir une installation fonctionnelle, il est nécessaire d’installer manuellement l’ensemble des dépendances logicielles sur le serveur.
    Si vous souhaitez utiliser cette archive pour une installation en mode ferme, il vous faudra également procéder à d’autres modifications (...)

  • Amélioration de la version de base

    13 septembre 2013

    Jolie sélection multiple
    Le plugin Chosen permet d’améliorer l’ergonomie des champs de sélection multiple. Voir les deux images suivantes pour comparer.
    Il suffit pour cela d’activer le plugin Chosen (Configuration générale du site > Gestion des plugins), puis de configurer le plugin (Les squelettes > Chosen) en activant l’utilisation de Chosen dans le site public et en spécifiant les éléments de formulaires à améliorer, par exemple select[multiple] pour les listes à sélection multiple (...)

Sur d’autres sites (13920)

  • Integrating CUDA-based video decoder into libavcodec/ffmpeg

    1er février 2019, par tmlen

    I have a CUDA-based decoder of a video format running on the GPU. I am trying to add a "codec" into libavcodec that uses it as external decoder

    Currenty, I have it working such that I can play a sequence of pictures using ffplay, which
    get decoded on the GPU with the external decoder.

    But with the current implementation, the codec module copies its output (in a RGB24 pixel format) from GPU memory to host memory after each frame, and gives this to libavcodec in its AVFrame. So with this when using ffplay, it will copy the output images back and forth between GPU and host two times (as ffplay has to copy the data to GPU for display).

    My goal is to leave the uncompressed data on GPU using on a CUDA device buffer, and have ffmpeg use it.

    ffmpeg seems to have support for this using AVHWAccel.

    • Is there any example implementation that uses this with a CUDA based decoder (not using the dedicated hardware decoders through NVDEC, CUVID, etc.) ?

    • Does ffmpeg need the output in a pixel format in a CUDA buffer, or can it also be in texture memory, in a CUDA array ?

    • Is it possible to have the hardware decoder as primary decoder of the AVCodec. It seems that hardware-acceleration is foreseen as an add-on, with the software decoder implemented by AVCodec available as fallback ?

    • It seems that ffmpeg will allocate a pool of CUDA buffers to receive its output. Is it also possible to allocate the output buffers oneself in the module’s implementation, and control how many buffers there will be.

    • Is it possible to control with how many CPU threads the decoder will be called ? With the external decoder’s interface, ideal would be one writer thread that pushes compressed codestreams, and one reader thread that pulls the uncompressed output to a CUDA buffer.

  • Revision 8350e7fe38 : Make intra prediction pointers RTCD-based. This probably has a mildly negative

    9 juillet 2013, par Ronald S. Bultje

    Changed Paths :
     Modify /vp9/common/vp9_reconintra.c


     Modify /vp9/common/vp9_rtcd_defs.sh


     Modify /vp9/common/x86/vp9_recon_sse2.asm


     Delete /vp9/common/x86/vp9_recon_wrapper_sse2.c


     Modify /vp9/encoder/vp9_mbgraph.c


     Modify /vp9/vp9_common.mk



    Make intra prediction pointers RTCD-based.

    This probably has a mildly negative impact on performance, but will
    (in future commits - or possibly merged with this one) allow SIMD
    implementations of individual intra prediction functions. We may
    perhaps want to consider having separate functions per txfm-size
    also (i.e. 4x4, 8x8, 16x16 and 32x32 intra prediction functions for
    each intra prediction mode), but I haven't played much with that
    yet.

    Change-Id : Ie739985eee0a3fcbb7aed29ee6910fdb653ea269

  • Revision 10bae82510 : Adds variance based fixed size partitioning Adds a method for determining a fix

    25 février 2014, par Deb Mukherjee

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


     Modify /vp9/encoder/vp9_onyx_if.c


     Modify /vp9/encoder/vp9_onyx_int.h


     Modify /vp9/encoder/vp9_ratectrl.c


     Modify /vp9/encoder/vp9_rdopt.c



    Adds variance based fixed size partitioning

    Adds a method for determining a fixed size partition based on
    variance of a 64x64 SB. This method is added to rtc speed 6.
    Also fixes a bug in rtc_use_partition() and includes some
    refactoring related to partitioning search, and some cosmetics.

    Currently compared to speed 5, the coding efficiency of speed 6
    is -19% and that of speed 7 is -55%, in cbr mode.

    Change-Id : I057e04125a8b765906bb7d4bf7a36d1e575de7c6

Navigation