Recherche avancée

Médias (1)

Mot : - Tags -/bug

Autres articles (61)

  • Mise à jour de la version 0.1 vers 0.2

    24 juin 2013, par

    Explications des différents changements notables lors du passage de la version 0.1 de MediaSPIP à la version 0.3. Quelles sont les nouveautés
    Au niveau des dépendances logicielles Utilisation des dernières versions de FFMpeg (>= v1.2.1) ; Installation des dépendances pour Smush ; Installation de MediaInfo et FFprobe pour la récupération des métadonnées ; On n’utilise plus ffmpeg2theora ; On n’installe plus flvtool2 au profit de flvtool++ ; On n’installe plus ffmpeg-php qui n’est plus maintenu au (...)

  • Personnaliser en ajoutant son logo, sa bannière ou son image de fond

    5 septembre 2013, par

    Certains thèmes prennent en compte trois éléments de personnalisation : l’ajout d’un logo ; l’ajout d’une bannière l’ajout d’une image de fond ;

  • Ecrire une actualité

    21 juin 2013, par

    Présentez les changements dans votre MédiaSPIP ou les actualités de vos projets sur votre MédiaSPIP grâce à la rubrique actualités.
    Dans le thème par défaut spipeo de MédiaSPIP, les actualités sont affichées en bas de la page principale sous les éditoriaux.
    Vous pouvez personnaliser le formulaire de création d’une actualité.
    Formulaire de création d’une actualité Dans le cas d’un document de type actualité, les champs proposés par défaut sont : Date de publication ( personnaliser la date de publication ) (...)

Sur d’autres sites (10174)

  • lavc/aarch64/h264dsp_init_aarch64 : Fix weight function prototypes.

    21 janvier 2018, par Carl Eugen Hoyos
    lavc/aarch64/h264dsp_init_aarch64 : Fix weight function prototypes.
    

    Fixes the following warnings :
    libavcodec/aarch64/h264dsp_init_aarch64.c : In function ‘ff_h264dsp_init_aarch64’ :
    libavcodec/aarch64/h264dsp_init_aarch64.c:84:38 : warning : assignment from incompatible pointer type [enabled by default]
    c->weight_h264_pixels_tab[0] = ff_weight_h264_pixels_16_neon ;
    ^
    libavcodec/aarch64/h264dsp_init_aarch64.c:85:38 : warning : assignment from incompatible pointer type [enabled by default]
    c->weight_h264_pixels_tab[1] = ff_weight_h264_pixels_8_neon ;
    ^
    libavcodec/aarch64/h264dsp_init_aarch64.c:86:38 : warning : assignment from incompatible pointer type [enabled by default]
    c->weight_h264_pixels_tab[2] = ff_weight_h264_pixels_4_neon ;
    ^
    libavcodec/aarch64/h264dsp_init_aarch64.c:88:40 : warning : assignment from incompatible pointer type [enabled by default]
    c->biweight_h264_pixels_tab[0] = ff_biweight_h264_pixels_16_neon ;
    ^
    libavcodec/aarch64/h264dsp_init_aarch64.c:89:40 : warning : assignment from incompatible pointer type [enabled by default]
    c->biweight_h264_pixels_tab[1] = ff_biweight_h264_pixels_8_neon ;
    ^
    libavcodec/aarch64/h264dsp_init_aarch64.c:90:40 : warning : assignment from incompatible pointer type [enabled by default]
    c->biweight_h264_pixels_tab[2] = ff_biweight_h264_pixels_4_neon ;
    ^

    • [DH] libavcodec/aarch64/h264dsp_init_aarch64.c
  • avformat/movenc : allow hdlr name field to be empty

    21 juin 2018, par Gyan Doshi
    avformat/movenc : allow hdlr name field to be empty
    

    Both QTFF and the ISOBMFF standards allow it.

    Fixes #7262

    • [DH] libavformat/movenc.c
    • [DH] libavformat/movenc.h
    • [DH] libavformat/version.h
  • avcodec/allcodecs : Provide empty codec_list in allcodecs when ossfuzz is used

    28 mai 2018, par Michael Niedermayer
    avcodec/allcodecs : Provide empty codec_list in allcodecs when ossfuzz is used
    

    The last workaround is not sufficient to make oss fuzz work with the iterate API
    as it did not provide a FFmpeg that external libs can be linked to.

    This patch does not fully restore the pre iterate functionality. My attempts to
    do this have so far failed.

    The problem with this solution is that it renders the fuzzers virtual system
    ffmpeg (libs) non functional. Which differs from a real system compared to the
    virtual system tested by the fuzzer.
    It should theoretically not matter as the system ffmpeg wouldnt be used.
    But with more cases being fuzzed we likely will hit a case where a external
    lib is involved and it does matter ...

    Working around this may be possible with weak symbols but so far my attempts
    failed

    Alternatively multiple ffmpeg could be built, this becomes messy though
    quickly as they need to be all linked together. That is we need a FFmpeg
    that has the iterate API modified so it can work with the resources
    available to ossfuzz. And at the same time we need a ffmpeg that has
    its full functionality for any external libs which use ffmpeg and are
    used by ffmpeg.

    Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>

    • [DH] libavcodec/allcodecs.c
    • [DH] tools/target_dec_fuzzer.c