Recherche avancée

Médias (0)

Mot : - Tags -/masques

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

Autres articles (111)

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

  • Emballe médias : à quoi cela sert ?

    4 février 2011, par

    Ce plugin vise à gérer des sites de mise en ligne de documents de tous types.
    Il crée des "médias", à savoir : un "média" est un article au sens SPIP créé automatiquement lors du téléversement d’un document qu’il soit audio, vidéo, image ou textuel ; un seul document ne peut être lié à un article dit "média" ;

Sur d’autres sites (7749)

  • FFMPEG and JNI - pass AVFrame data to Java and Back

    17 octobre 2015, par tishu

    I have some C code that decodes a video frame by frame. I get to a point where i have an AVFrame in BGR32 and would like to send it back to Java for editing.

    I have a ByteBuffer object in my C code that was created in Java using AllocateDirect but i struggle to write the content of the AVFrame->data[0] (of uint8_t type) to it and read it back. I have tried memcpy with no luck. Does anyone have an idea how to achieve this ?

    UPDATE
    Followed Will’s comment below and wrote this in C

    char *buf = (*pEnv)->GetDirectBufferAddress(pEnv, byteBuffer);
    
memcpy(buf, rgb_frame->data[0], output_width*output_height*4);

    The buffer does contain some data in Java but doing the following returns a null bitmap

    BufferedImage frame = ImageIO.read(bitmapStream);

    Where bitmapStream is a ByteBufferInputStream defined here :
    https://code.google.com/p/kryo/source/browse/trunk/src/com/esotericsoftware/kryo/io/ByteBufferInputStream.java?r=205

    Not sure if I am not writing things correctly in this buffer

    UPDATE 2

    Got pretty close now thanks to the latest snippet. I am using BGR32 format in my C code ie 4 bytes per pixel. So I modified things a bit in Java :

    final byte[] dataArray = new byte[width*height*4];
    
imageData.get(dataArray);
    
final BufferedImage image = new BufferedImage(width, height, BufferedImage.TYPE_INT_BGR);
    
final DataBuffer buffer = new DataBufferByte(dataArray, dataArray.length);
    
Raster raster = Raster.createRaster(sampleModel, buffer, null);
    
image.setData(raster);

    I get the image correctly but there seems to be an issue with color channels
    Example

    Tried different formats with no luck

  • avcodec/rv30 : fix switching back to the original resolution

    17 août 2015, par Michael Niedermayer
    avcodec/rv30 : fix switching back to the original resolution

    Fixes part of Ticket1388
    

    Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
    • [DH] libavcodec/rv30.c
    • [DH] libavcodec/rv34.h

  • x86 : move XOP emulation code back to x86inc

    3 août 2015, par James Almer
    x86 : move XOP emulation code back to x86inc

    Only two functions that use xop multiply-accumulate instructions where the
    
first operand is the same as the fourth actually took advantage of the macros.
    

    This further reduces differences with x264’s x86inc.
    

    Reviewed-by : Ronald S. Bultje <rsbultje@gmail.com>
    
Signed-off-by : James Almer <jamrial@gmail.com>
    • [DH] libavcodec/x86/flacdsp.asm
    • [DH] libavutil/x86/x86inc.asm
    • [DH] libavutil/x86/x86util.asm
    • [DH] libswresample/x86/resample.asm

Navigation