Recherche avancée

Médias (2)

Mot : - Tags -/doc2img

Autres articles (60)

  • Le profil des utilisateurs

    12 avril 2011, par

    Chaque utilisateur dispose d’une page de profil lui permettant de modifier ses informations personnelle. Dans le menu de haut de page par défaut, un élément de menu est automatiquement créé à l’initialisation de MediaSPIP, visible uniquement si le visiteur est identifié sur le site.
    L’utilisateur a accès à la modification de profil depuis sa page auteur, un lien dans la navigation "Modifier votre profil" est (...)

  • Configurer la prise en compte des langues

    15 novembre 2010, par

    Accéder à la configuration et ajouter des langues prises en compte
    Afin de configurer la prise en compte de nouvelles langues, il est nécessaire de se rendre dans la partie "Administrer" du site.
    De là, dans le menu de navigation, vous pouvez accéder à une partie "Gestion des langues" permettant d’activer la prise en compte de nouvelles langues.
    Chaque nouvelle langue ajoutée reste désactivable tant qu’aucun objet n’est créé dans cette langue. Dans ce cas, elle devient grisée dans la configuration et (...)

  • XMP PHP

    13 mai 2011, par

    Dixit Wikipedia, XMP signifie :
    Extensible Metadata Platform ou XMP est un format de métadonnées basé sur XML utilisé dans les applications PDF, de photographie et de graphisme. Il a été lancé par Adobe Systems en avril 2001 en étant intégré à la version 5.0 d’Adobe Acrobat.
    Étant basé sur XML, il gère un ensemble de tags dynamiques pour l’utilisation dans le cadre du Web sémantique.
    XMP permet d’enregistrer sous forme d’un document XML des informations relatives à un fichier : titre, auteur, historique (...)

Sur d’autres sites (5479)

  • avcodec/eatgv : Check remaining size after the keyframe header

    28 juillet 2019, par Michael Niedermayer
    avcodec/eatgv : Check remaining size after the keyframe header
    

    The minimal size which unpack() will not fail on is 5 bytes
    Fixes : Timeout (14sec -> 77ms) (testcase 15508)
    Fixes : 15508/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EATGV_fuzzer-5700053513011200
    Fixes : 15996/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EATGV_fuzzer-5751353223151616

    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/eatgv.c
  • Building ffmpeg on mac results in undefined symbols

    9 juin 2017, par Peter

    Environment : macOS 10.12.5, Xcode 8.3.3, pkg-config installed via brew

    I need to build a minimal version of ffmpeg that supports H.264 decoding. I have downloaded the source for ffmpeg version 3.3.1 and have successfully built it for Windows and Linux. Now, I am trying to build it for mac.

    The specific flags of the configuration that are relevant are :

    --disable-yasm
    --disable-everything
    --enable-decoder=h264
    --enable-decoder=h264_vda
    --enable-vda

    After running the configuration, when I run make, all the libraries such as libavcodec.a, libavfilter.a, libavformat.a, are built. However, ffmpeg itself does not get built. The error I get is :

    Undefined symbols for architecture x86_64:
     "_ff_vda_create_decoder", referenced from:
         _vdadec_init in libavcodec.a(vda_h264_dec.o)
     "_ff_vda_destroy_decoder", referenced from:
         _vdadec_init in libavcodec.a(vda_h264_dec.o)
         _vdadec_close in libavcodec.a(vda_h264_dec.o)
    ld: symbol(s) not found for architecture x86_64

    Looks like the functions are defined in ./libavcodec/vda_h264.c. However, it appears vda_h264.c is never compiled. Other vda related files such as vda.c and vda_h264_dec.c do get compiled (and added to libavcodec.a).

    I am thinking perhaps I am missing a configuration flag. Can someone please help ? Regards.

  • snow : remove an obsolete av_assert2

    9 juillet 2015, par Andreas Cadhalpun
    snow : remove an obsolete av_assert2
    

    It asserts that the frame linesize is larger than 37, but it can be
    smaller and decoding such frames works.

    Before commit cc884a35 src_stride > 7*MB_SIZE was necessary, because the
    blocks were interleaved in the tmp buffer and the last block was added
    with an offset of 6*MB_SIZE.
    It was changed for src_stride <= 7*MB_SIZE to write the blocks
    sequentially, hence the larger tmp_step.
    After that the assert was only necessary to make sure that the buffer
    remained large enough.
    Since commit bd2b6b33 s->scratchbuf is used as tmp buffer.
    As part of commit 86e107a7 the minimal scratchbuf size was increased to
    256*7*MB_SIZE, which is enough for any src_stride <= 7*MB_SIZE.

    Also add a comment explaining the tmp_step calculation.

    Signed-off-by : Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

    • [DH] libavcodec/snow.h