Recherche avancée

Médias (1)

Mot : - Tags -/pirate bay

Autres articles (112)

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

  • HTML5 audio and video support

    13 avril 2011, par

    MediaSPIP uses HTML5 video and audio tags to play multimedia files, taking advantage of the latest W3C innovations supported by modern browsers.
    The MediaSPIP player used has been created specifically for MediaSPIP and can be easily adapted to fit in with a specific theme.
    For older browsers the Flowplayer flash fallback is used.
    MediaSPIP allows for media playback on major mobile platforms with the above (...)

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

  • lavf/mov : ensure only one tkhd per trak

    13 décembre 2018, par chcunningham
    lavf/mov : ensure only one tkhd per trak

    Chromium fuzzing produced a whacky file with extra tkhds. This caused
    
an AVStream that was already in use to be corrupted by assigning it a
    
new id, which blows up later in mov_read_trun because the
    
MOVFragmentStreamInfo.index_entry now points OOB.
    

    Reviewed-by : Baptiste Coudurier <baptiste.coudurier@gmail.com>
    
Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
    • [DH] libavformat/mov.c

  • cbs_vp9 : Ensure that reserved zero bits are actually zero

    27 octobre 2018, par Mark Thompson
    cbs_vp9 : Ensure that reserved zero bits are actually zero
    • [DH] libavcodec/cbs_vp9.c
    • [DH] libavcodec/cbs_vp9.h
    • [DH] libavcodec/cbs_vp9_syntax_template.c

  • avcodec/cbs : ensure user_data is padded for GBC parsing

    5 octobre 2018, par Aman Gupta
    avcodec/cbs : ensure user_data is padded for GBC parsing

    Fixes crash noticed in the cbs_userdata patchset.
    

    ====ERROR : AddressSanitizer : heap-buffer-overflow on address 0x609000026c89 at pc 0x00010725d37b bp 0x7ffeea04e750 sp 0x7ffeea04e748
    
READ of size 4 at 0x609000026c89 thread T0
    
    #0 0x10725d37a in ff_cbs_read_unsigned get_bits.h:274
    
    #1 0x1072d2767 in ff_cbs_read_a53_user_data cbs_misc_syntax_template.c:119
    
    #2 0x1078251a7 in h264_metadata_filter h264_metadata_bsf.c:595
    
    #3 0x105c1321d in output_packet ffmpeg.c:853
    

    0x609000026c89 is located 1 bytes to the right of 8-byte region [0x609000026c80,0x609000026c88)
    
allocated by thread T0 here :
    
    #0 0x10aef08d7 in wrap_posix_memalign (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x578d7)
    
    #1 0x10aca95e6 in av_malloc mem.c:87
    
    #2 0x10ac545fe in av_buffer_allocz buffer.c:72
    
    #3 0x107263b27 in cbs_h264_read_nal_unit cbs_h264_syntax_template.c:722
    
    #4 0x10725b688 in cbs_read_fragment_content cbs.c:155
    

    Signed-off-by : Aman Gupta <aman@tmm1.net>
    • [DH] libavcodec/cbs_h264_syntax_template.c
    • [DH] libavcodec/cbs_mpeg2_syntax_template.c

Navigation