Recherche avancée

Médias (0)

Mot : - Tags -/content

Aucun média correspondant à vos critères n’est disponible sur le site.

Autres articles (39)

  • Personnaliser les catégories

    21 juin 2013, par

    Formulaire de création d’une catégorie
    Pour ceux qui connaissent bien SPIP, une catégorie peut être assimilée à une rubrique.
    Dans le cas d’un document de type catégorie, les champs proposés par défaut sont : Texte
    On peut modifier ce formulaire dans la partie :
    Administration > Configuration des masques de formulaire.
    Dans le cas d’un document de type média, les champs non affichés par défaut sont : Descriptif rapide
    Par ailleurs, c’est dans cette partie configuration qu’on peut indiquer le (...)

  • Publier sur MédiaSpip

    13 juin 2013

    Puis-je poster des contenus à partir d’une tablette Ipad ?
    Oui, si votre Médiaspip installé est à la version 0.2 ou supérieure. Contacter au besoin l’administrateur de votre MédiaSpip pour le savoir

  • Ajouter notes et légendes aux images

    7 février 2011, par

    Pour pouvoir ajouter notes et légendes aux images, la première étape est d’installer le plugin "Légendes".
    Une fois le plugin activé, vous pouvez le configurer dans l’espace de configuration afin de modifier les droits de création / modification et de suppression des notes. Par défaut seuls les administrateurs du site peuvent ajouter des notes aux images.
    Modification lors de l’ajout d’un média
    Lors de l’ajout d’un média de type "image" un nouveau bouton apparait au dessus de la prévisualisation (...)

Sur d’autres sites (8096)

  • Evolution #3958 : Mise à jour de la liste des types mines

    12 juin 2017, par nico d_

    Hop, pour information ce sont les type MIME, pas mines :)
    Type mine c’est pour les voitures ^^
    https://fr.wikipedia.org/wiki/Type_MIME

    Et sinon, ils sont indiqués ici dans le tableau apparemment :
    https://en.wikipedia.org/wiki/High_Efficiency_Image_File_Format#Brands_and_MIME_types

  • avcodec/png : use libavutil/csp.h for cHRM chunks

    17 janvier 2023, par Leo Izen
    avcodec/png : use libavutil/csp.h for cHRM chunks
    

    The cHRM chunk is descriptive. That is, it describes the primaries that should
    be used to interpret the pixel data in the PNG file. This is notably different
    from Mastering Display Metadata, which describes which subset of the presented
    gamut is relevant. MDM describes a gamut and says colors outside the gamut are
    not required to be preserved, but it does not actually describe the gamut that
    the pixel data from the frame resides in. Thus, to decode a cHRM chunk present
    in a PNG file to Mastering Display Metadata is incorrect.

    This commit changes this behavior so the cHRM chunk, if present, is decoded to
    color metadata. For example, if the cHRM chunk describes BT.709 primaries, the
    resulting AVFrame will be tagged with AVCOL_PRI_BT709, as a description of its
    pixel data. To do this, it utilizes libavutil/csp.h, which exposes a funcction
    av_csp_primaries_id_from_desc, to detect which enum value accurately describes
    the white point and primaries represented by the cHRM chunk.

    This commit also changes pngenc.c to utilize the libavuitl/csp.h API, since it
    previously duplicated code contained in that API. Instead, taking advantage of
    the API that exists makes more sense. pngenc.c does properly utilize the color
    tags rather than incorrectly using MDM, so that required no change.

    Signed-off-by : Leo Izen <leo.izen@gmail.com>

    • [DH] libavcodec/pngdec.c
    • [DH] libavcodec/pngenc.c
    • [DH] tests/ref/fate/png-icc
    • [DH] tests/ref/fate/png-side-data
  • ffmpeg - Different number of macroblocks per each frame

    18 juin 2018, par fabridigua

    i am studying the MPEG compression, in particular how are "labeled" the macroblocks with ffmpeg, using the command :

    ffmpeg -debug mb_type -i input.mp4 out.mp4

    From theory, i know that typically a macroblock is a 16x16 (pixels) block.

    So if a frame is e.g. 1920x1080 i suppose that the macroblocks are

    (1920*1080)/(16*16) = 8100

    Now, analysing the ffmpeg report, I’ve seen that for each frame there are many many less macroblocks (labelled with some "characters" indicating their type).

    Can you explain me why this happens ?
    Is a (mine) theory error ?

    I’ve seen that "visualizing" macroblocks with -debug vis_mb_type there some gray blocks.. corresponding to the (macro)blocks not satisfying any criteria ffmpeg is looking for.. maybe in my example for each frame there are

    8100 - #"gray" macroblocks

    Is this possible ? And why ?