Recherche avancée

Médias (0)

Mot : - Tags -/metadatas

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

Autres articles (37)

  • Encoding and processing into web-friendly formats

    13 avril 2011, par

    MediaSPIP automatically converts uploaded files to internet-compatible formats.
    Video files are encoded in MP4, Ogv and WebM (supported by HTML5) and MP4 (supported by Flash).
    Audio files are encoded in MP3 and Ogg (supported by HTML5) and MP3 (supported by Flash).
    Where possible, text is analyzed in order to retrieve the data needed for search engine detection, and then exported as a series of image files.
    All uploaded files are stored online in their original format, so you can (...)

  • Supporting all media types

    13 avril 2011, par

    Unlike most software and media-sharing platforms, MediaSPIP aims to manage as many different media types as possible. The following are just a few examples from an ever-expanding list of supported formats : images : png, gif, jpg, bmp and more audio : MP3, Ogg, Wav and more video : AVI, MP4, OGV, mpg, mov, wmv and more text, code and other data : OpenOffice, Microsoft Office (Word, PowerPoint, Excel), web (html, CSS), LaTeX, Google Earth and (...)

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

Sur d’autres sites (3130)

  • avcodec/magicyuv : Fix edge case of building Huffman table

    23 septembre 2020, par Andreas Rheinhardt
    avcodec/magicyuv : Fix edge case of building Huffman table

    The MagicYUV format stores Huffman tables in its bitstream by coding
    
the length of a given symbol ; it does not code the actual code directly,
    
instead this is to be inferred by the rule that a symbol is to the left
    
of every shorter symbol in the Huffman tree and that for symbols of the
    
same length the symbol is ascending from left to right. With one
    
exception, this is also what our decoder did.
    

    The exception only matters when there are codes of length 32, because
    
in this case the first symbol of this length did not get the code 0,
    
but 1 ; e.g. if there were exactly two nodes of length 32, then they
    
would get assigned the codes 1 and 2 and a node of length 31 will get
    
the 31-bit code 1 which is a prefix of the 32 bit code 2, making the
    
Huffman table invalid. On the other hand, if there were only one symbol
    
with the length 32, the earlier code would accept this un-Huffman-tree.
    

    Reviewed-by : Paul B Mahol <onemda@gmail.com>
    
Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
    • [DH] libavcodec/magicyuv.c

  • tiffenc : factorize code for monow/monob case in encode_frame() switch

    13 mai 2011, par Stefano Sabatini

    tiffenc : factorize code for monow/monob case in encode_frame() switch

  • lavdev : improve feedback in case of invalid frame rate/size

    3 juin 2011, par Stefano Sabatini

    lavdev : improve feedback in case of invalid frame rate/size

Navigation