Recherche avancée

Médias (91)

Autres articles (18)

  • Keeping control of your media in your hands

    13 avril 2011, par

    The vocabulary used on this site and around MediaSPIP in general, aims to avoid reference to Web 2.0 and the companies that profit from media-sharing.
    While using MediaSPIP, you are invited to avoid using words like "Brand", "Cloud" and "Market".
    MediaSPIP is designed to facilitate the sharing of creative media online, while allowing authors to retain complete control of their work.
    MediaSPIP aims to be accessible to as many people as possible and development is based on expanding the (...)

  • Submit bugs and patches

    13 avril 2011

    Unfortunately a software is never perfect.
    If you think you have found a bug, report it using our ticket system. Please to help us to fix it by providing the following information : the browser you are using, including the exact version as precise an explanation as possible of the problem if possible, the steps taken resulting in the problem a link to the site / page in question
    If you think you have solved the bug, fill in a ticket and attach to it a corrective patch.
    You may also (...)

  • Contribute to a better visual interface

    13 avril 2011

    MediaSPIP is based on a system of themes and templates. Templates define the placement of information on the page, and can be adapted to a wide range of uses. Themes define the overall graphic appearance of the site.
    Anyone can submit a new graphic theme or template and make it available to the MediaSPIP community.

Sur d’autres sites (2716)

  • 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