Recherche avancée

Médias (0)

Mot : - Tags -/serveur

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

Autres articles (37)

  • Les autorisations surchargées par les plugins

    27 avril 2010, par

    Mediaspip core
    autoriser_auteur_modifier() afin que les visiteurs soient capables de modifier leurs informations sur la page d’auteurs

  • MediaSPIP Player : problèmes potentiels

    22 février 2011, par

    Le lecteur ne fonctionne pas sur Internet Explorer
    Sur Internet Explorer (8 et 7 au moins), le plugin utilise le lecteur Flash flowplayer pour lire vidéos et son. Si le lecteur ne semble pas fonctionner, cela peut venir de la configuration du mod_deflate d’Apache.
    Si dans la configuration de ce module Apache vous avez une ligne qui ressemble à la suivante, essayez de la supprimer ou de la commenter pour voir si le lecteur fonctionne correctement : /** * GeSHi (C) 2004 - 2007 Nigel McNie, (...)

  • 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 (...)

Sur d’autres sites (7257)

  • FFMPEG : av_read_frame() return error AVERROR_EXIT ?

    19 mai 2015, par TTGroup

    I’m using FFMPEG to decode H264 stream from IP Camera. Sometimes the function av_read_frame() return error AVERROR_EXIT.

    I tested with two cameras. In here, the camera in LAN network worked fine with no error, but the camera in WAN network usually return AVERROR_EXIT.

    I have searched on the internet, but I didn’t find the solution yet.

    Someone can show me the problem ?

    Thanks,

    T&T

  • lavf : move TLS-related ifdeffery to library specific files

    26 mai 2015, par wm4
    lavf : move TLS-related ifdeffery to library specific files
    

    There is no need to have this mess in network.c.

    Signed-off-by : Martin Storsjö <martin@martin.st>

    • [DH] libavformat/network.c
    • [DH] libavformat/tls.h
    • [DH] libavformat/tls_gnutls.c
    • [DH] libavformat/tls_openssl.c
  • avformat : make avformat_network_init() explicitly optional

    16 janvier 2018, par wm4
    avformat : make avformat_network_init() explicitly optional
    

    It was sort of optional before - if you didn't call it, networking was
    initialized on demand, and an ugly warning was logged. Also, the doxygen
    comments threatened that it would be made strictly required one day.

    Make it explicitly optional. I would prefer to deprecate it fully, but
    there might still be legitimate reasons to use this. But the average
    user won't need it.

    This is needed only for two reasons : to initialize TLS libraries like
    OpenSSL and GnuTLS, and winsock.

    OpenSSL and GnuTLS were already silently initialized on demand if the
    global network init function was not called. They also have various
    thread-safety acrobatics, which make concurrent initialization within
    libavformat safe. In addition, the libraries are moving towards making
    their global init functions safe, which removes all need for central
    global init. In particular, GnuTLS 3.5.16 and OpenSSL 1.1.0g have been
    found to have safe init functions. In all cases, they use internal
    reference counters to avoid that the global uninit functions interfere
    with concurrent uses of the library by other API users who called global
    init.

    winsock should be thread-safe as well, and maintains an internal
    reference counter as well.

    Since we still support ancient TLS libraries, which do not have this
    fixed, and since it's unknown whether winsock and GnuTLS
    reinitialization is costly in any way, don't deprecate the libavformat
    functions yet.

    • [DH] doc/APIchanges
    • [DH] libavformat/avformat.h
    • [DH] libavformat/network.c
    • [DH] libavformat/network.h
    • [DH] libavformat/utils.c
    • [DH] libavformat/version.h