Advanced search

Medias (91)

Other articles (70)

  • Websites made ​​with MediaSPIP

    2 May 2011, by

    This page lists some websites based on MediaSPIP.

  • MediaSPIP v0.2

    21 June 2013, by

    MediaSPIP 0.2 est la première version de MediaSPIP stable.
    Sa date de sortie officielle est le 21 juin 2013 et est annoncée ici.
    Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
    Comme pour la version précédente, il est nécessaire d’installer manuellement l’ensemble des dépendances logicielles sur le serveur.
    Si vous souhaitez utiliser cette archive pour une installation en mode ferme, il vous faudra également procéder à d’autres modifications (...)

  • Creating farms of unique websites

    13 April 2011, by

    MediaSPIP platforms can be installed as a farm, with a single "core" hosted on a dedicated server and used by multiple websites.
    This allows (among other things): implementation costs to be shared between several different projects / individuals rapid deployment of multiple unique sites creation of groups of like-minded sites, making it possible to browse media in a more controlled and selective environment than the major "open" (...)

On other websites (10611)

  • avutil/pixdesc: deprecate AV_PIX_FMT_FLAG_PSEUDOPAL

    29 March 2018, by wm4
    avutil/pixdesc: deprecate AV_PIX_FMT_FLAG_PSEUDOPAL
    

    PSEUDOPAL pixel formats are not paletted, but carried a palette with the
    intention of allowing code to treat unpaletted formats as paletted. The
    palette simply mapped the byte values to the resulting RGB values,
    making it some sort of LUT for RGB conversion.

    It was used for 1 byte formats only: RGB4_BYTE, BGR4_BYTE, RGB8, BGR8,
    GRAY8. The first 4 are awfully obscure, used only by some ancient bitmap
    formats. The last one, GRAY8, is more common, but its treatment is
    grossly incorrect. It considers full range GRAY8 only, so GRAY8 coming
    from typical Y video planes was not mapped to the correct RGB values.
    This cannot be fixed, because AVFrame.color_range can be freely changed
    at runtime, and there is nothing to ensure the pseudo palette is
    updated.

    Also, nothing actually used the PSEUDOPAL palette data, except xwdenc
    (trivially changed in the previous commit). All other code had to treat
    it as a special case, just to ignore or to propagate palette data.

    In conclusion, this was just a very strange old mechnaism that has no
    real justification to exist anymore (although it may have been nice and
    useful in the past). Now it's an artifact that makes the API harder to
    use: API users who allocate their own pixel data have to be aware that
    they need to allocate the palette, or FFmpeg will crash on them in
    _some_ situations. On top of this, there was no API to allocate the
    pseuo palette outside of av_frame_get_buffer().

    This patch not only deprecates AV_PIX_FMT_FLAG_PSEUDOPAL, but also makes
    the pseudo palette optional. Nothing accesses it anymore, though if it's
    set, it's propagated. It's still allocated and initialized for
    compatibility with API users that rely on this feature. But new API
    users do not need to allocate it. This was an explicit goal of this
    patch.

    Most changes replace AV_PIX_FMT_FLAG_PSEUDOPAL with FF_PSEUDOPAL. I
    first tried #ifdefing all code, but it was a mess. The FF_PSEUDOPAL
    macro reduces the mess, and still allows defining FF_API_PSEUDOPAL to 0.

    Passes FATE with FF_API_PSEUDOPAL enabled and disabled. In addition,
    FATE passes with FF_API_PSEUDOPAL set to 1, but with allocation
    functions manually changed to not allocating a palette.

    • [DH] doc/APIchanges
    • [DH] fftools/ffprobe.c
    • [DH] libavcodec/decode.c
    • [DH] libavcodec/ffv1dec.c
    • [DH] libavcodec/rawdec.c
    • [DH] libavcodec/smvjpegdec.c
    • [DH] libavfilter/drawutils.c
    • [DH] libavfilter/framepool.c
    • [DH] libavfilter/vf_crop.c
    • [DH] libavfilter/vf_pixdesctest.c
    • [DH] libavfilter/vf_scale.c
    • [DH] libavfilter/vf_shuffleplanes.c
    • [DH] libavutil/frame.c
    • [DH] libavutil/imgutils.c
    • [DH] libavutil/internal.h
    • [DH] libavutil/pixdesc.c
    • [DH] libavutil/pixdesc.h
    • [DH] libavutil/version.h
    • [DH] libswscale/swscale_internal.h
  • Evolution #2802: Échapper le caractère d’échappement

    26 December 2017, by cam.lafit -

    Salut

    vu que \ est un caractères spécial , il semble logique qu’il soit
    traité comme les autres.La possibilité de l’échapper semble cohérent.

  • lavu,lavfi,ffmpeg: Remove experimental OpenCL API

    14 November 2017, by Mark Thompson
    lavu,lavfi,ffmpeg: Remove experimental OpenCL API
    

    This was added in early 2013 and abandoned several months later; as far as
    I can tell, there are no external users. Future OpenCL use will be via
    hwcontext, which requires neither special OpenCL-only API nor global state
    in libavutil.

    All internal users are also deleted - this is just the unsharp filter
    (replaced by unsharp_opencl, which is more flexible) and the deshake filter
    (no replacement).

    • [DH] configure
    • [DH] doc/APIchanges
    • [DH] doc/filters.texi
    • [DH] doc/utils.texi
    • [DH] fftools/Makefile
    • [DH] fftools/cmdutils.h
    • [DH] fftools/cmdutils_opencl.c
    • [DH] libavfilter/Makefile
    • [DH] libavfilter/allfilters.c
    • [DH] libavfilter/deshake.h
    • [DH] libavfilter/deshake_opencl.c
    • [DH] libavfilter/deshake_opencl.h
    • [DH] libavfilter/deshake_opencl_kernel.h
    • [DH] libavfilter/opencl_allkernels.c
    • [DH] libavfilter/opencl_allkernels.h
    • [DH] libavfilter/unsharp.h
    • [DH] libavfilter/unsharp_opencl.c
    • [DH] libavfilter/unsharp_opencl.h
    • [DH] libavfilter/unsharp_opencl_kernel.h
    • [DH] libavfilter/vf_deshake.c
    • [DH] libavfilter/vf_unsharp.c
    • [DH] libavutil/Makefile
    • [DH] libavutil/opencl.c
    • [DH] libavutil/opencl.h
    • [DH] libavutil/opencl_internal.c
    • [DH] libavutil/opencl_internal.h