Recherche avancée

Médias (91)

Autres articles (35)

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

  • Encodage et transformation en formats lisibles sur Internet

    10 avril 2011

    MediaSPIP transforme et ré-encode les documents mis en ligne afin de les rendre lisibles sur Internet et automatiquement utilisables sans intervention du créateur de contenu.
    Les vidéos sont automatiquement encodées dans les formats supportés par HTML5 : MP4, Ogv et WebM. La version "MP4" est également utilisée pour le lecteur flash de secours nécessaire aux anciens navigateurs.
    Les documents audios sont également ré-encodés dans les deux formats utilisables par HTML5 :MP3 et Ogg. La version "MP3" (...)

  • Les thèmes de MediaSpip

    4 juin 2013

    3 thèmes sont proposés à l’origine par MédiaSPIP. L’utilisateur MédiaSPIP peut rajouter des thèmes selon ses besoins.
    Thèmes MediaSPIP
    3 thèmes ont été développés au départ pour MediaSPIP : * SPIPeo : thème par défaut de MédiaSPIP. Il met en avant la présentation du site et les documents média les plus récents ( le type de tri peut être modifié - titre, popularité, date) . * Arscenic : il s’agit du thème utilisé sur le site officiel du projet, constitué notamment d’un bandeau rouge en début de page. La structure (...)

Sur d’autres sites (4027)

  • cbs : Don't set AVBuffer's opaque

    29 juillet 2019, par Andreas Rheinhardt
    cbs : Don't set AVBuffer's opaque

    cbs is currently inconsistent regarding the opaque field that can be
    
used as a special argument to av_buffer_create in order to be used
    
during freeing the buffer : ff_cbs_alloc_unit_content and all the free
    
functions used name this parameter as if it should contain a pointer to
    
the unit whose content is about to be created ; but both
    
ff_cbs_alloc_unit_content as well as ff_cbs_h264_add_sei_message
    
actually use a pointer to the CodedBitstreamContext as opaque. It should
    
actually be neither, because it is unneeded (as is evidenced by the fact
    
that none of the free functions use this pointer at all) and because it
    
ties the unit's content to the lifetime of other objects, although a
    
refcounted buffer is supposed to have its own lifetime that only ends
    
when its reference count reaches zero. This problem manifests itself in
    
the pointer becoming dangling.
    
The pointer to the unit can become dangling if another unit is added to
    
the fragment later as happens in the bitstream filters ; in this case,
    
the pointer can point to the wrong unit (if the fragment's unit array
    
needn't be relocated) or it can point to where the array was earlier.
    
It can also become dangling if the unit's content is meant to survive
    
the resetting of the fragment it was originally read with. This applies
    
to the extradata of H.264 and HEVC.
    
The pointer to the context can become dangling if the context is closed
    
before the content is freed. Although this doesn't seem to happen right
    
now, it could happen, in particular if one uses different
    
CodedBitstreamContexts for in- and output.
    

    Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
    • [DH] libavcodec/cbs.c
    • [DH] libavcodec/cbs.h
    • [DH] libavcodec/cbs_av1.c
    • [DH] libavcodec/cbs_h2645.c
    • [DH] libavcodec/cbs_jpeg.c
    • [DH] libavcodec/cbs_mpeg2.c
    • [DH] libavcodec/cbs_vp9.c

  • vc2enc : properly promote operations to 64 bits

    13 mars 2018, par Rostislav Pehlivanov
    vc2enc : properly promote operations to 64 bits

    On Windows machines, the UL suffix still means 32 bits.
    
The only parts that need 64 bits are (1ULL << (m + 32)) and
    
(t*qf + qf). Hence, use the proper ULL suffix for the former
    
and just increase the type of the qf constant for the latter.
    
No overflows can happen as long as these are done in 64 bits and
    
the quantization table doesn't change.
    

    Signed-off-by : Rostislav Pehlivanov <atomnuker@gmail.com>
    • [DH] libavcodec/vc2enc.c

  • lavf/ffmenc : do not fail on missing codec

    19 février 2015, par Lukasz Marek
    lavf/ffmenc : do not fail on missing codec

    ffm encoder fails when codec is not found.
    
It may happen when stream is being copied.
    
This commit allows to store such stream and provides
    
backward compatibility with version prior 2.5 release.
    

    fixes #4266
    

    Signed-off-by : Lukasz Marek <lukasz.m.luki2@gmail.com>
    • [DH] libavformat/ffmenc.c

Navigation