Recherche avancée

Médias (91)

Autres articles (77)

  • Use, discuss, criticize

    13 avril 2011, par

    Talk to people directly involved in MediaSPIP’s development, or to people around you who could use MediaSPIP to share, enhance or develop their creative projects.
    The bigger the community, the more MediaSPIP’s potential will be explored and the faster the software will evolve.
    A discussion list is available for all exchanges between users.

  • Récupération d’informations sur le site maître à l’installation d’une instance

    26 novembre 2010, par

    Utilité
    Sur le site principal, une instance de mutualisation est définie par plusieurs choses : Les données dans la table spip_mutus ; Son logo ; Son auteur principal (id_admin dans la table spip_mutus correspondant à un id_auteur de la table spip_auteurs)qui sera le seul à pouvoir créer définitivement l’instance de mutualisation ;
    Il peut donc être tout à fait judicieux de vouloir récupérer certaines de ces informations afin de compléter l’installation d’une instance pour, par exemple : récupérer le (...)

  • MediaSPIP Player : problèmes potentiels

    22 février 2011, par

    Le lecteur ne fonctionne pas sur Internet Explorer
    Sur Internet Explorer (8 et 7 au moins), le plugin utilise le lecteur Flash flowplayer pour lire vidéos et son. Si le lecteur ne semble pas fonctionner, cela peut venir de la configuration du mod_deflate d’Apache.
    Si dans la configuration de ce module Apache vous avez une ligne qui ressemble à la suivante, essayez de la supprimer ou de la commenter pour voir si le lecteur fonctionne correctement : /** * GeSHi (C) 2004 - 2007 Nigel McNie, (...)

Sur d’autres sites (4299)

  • avcodec/dstdec : Check that AC probabilities are within range

    15 octobre 2019, par Michael Niedermayer
    avcodec/dstdec : Check that AC probabilities are within range

    ISO/IEC 14496-3:2005(E) : "Each entry of P_one[ ][ ] is in the range of 1 to
    
128, corresponding to a probability of 1/256 to 128/256 of the next error bit (bit E, See Figure 10.5)..."
    

    Fixes : Timeout (42sec ->1sec)
    
Fixes : 18181/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DST_fuzzer-5736646250594304
    

    Found-by : continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
    
Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
    • [DH] libavcodec/dstdec.c

  • avcodec/pnm : explicitly tag color range

    25 octobre 2023, par Niklas Haas
    avcodec/pnm : explicitly tag color range

    PGMYUV seems to be always limited range. This was a format originally
    
invented by FFmpeg at a time when YUVJ distinguished limited from full
    
range YUV, and this codec never appeared to output YUVJ in any
    
circumstance, so hard-coding limited range preserves the status quo.
    

    The other formats are explicitly documented to be full range RGB/gray
    
formats. That said, don't tag them yet, due to outstanding bugs w.r.t
    
grayscale formats and color range handling.
    

    This change in behavior updates a bunch of FATE tests in trivial ways
    
(added tagging being the only difference).
    • [DH] libavcodec/pnm.c
    • [DH] tests/ref/lavf/mkv
    • [DH] tests/ref/lavf/mkv_attachment
    • [DH] tests/ref/lavf/mxf
    • [DH] tests/ref/lavf/y4m
    • [DH] tests/ref/seek/lavf-mkv
    • [DH] tests/ref/seek/lavf-y4m

  • avfilter/vf_tinterlace : support full-range YUV

    9 décembre 2022, par Niklas Haas
    avfilter/vf_tinterlace : support full-range YUV

    This filter, when used in the "pad" mode, currently makes the
    
distinction between limited and full range solely by testing for YUVJ
    
pixel formats at link setup time. This is deprecated and should be
    
improved to perform the detection based on the per-frame metadata.
    

    In order to make this distinction based on color range metadata, which
    
is only known at the time of filtering frames, for simplicity, we simply
    
allocate two copies of the "black" frame - one for limited range and the
    
other for full range metadata. This could be done more dynamically (e.g.
    
as-needed or simply by blitting the appropriate pixel value directly),
    
but this change is relatively simple and preserves the structure of the
    
existing code.
    

    This commit actually fixes a bug in FATE - the new output is correct for
    
the first time. The previous md5 ref was of a frame that incorrectly
    
combined full-range pixel data with limited-range black fields. The
    
corresponding result has been updated.
    

    Signed-off-by : Niklas Haas <git@haasn.dev>
    • [DH] libavfilter/tinterlace.h
    • [DH] libavfilter/vf_tinterlace.c
    • [DH] tests/ref/fate/filter-pixfmts-tinterlace_pad

Navigation