Recherche avancée

Médias (91)

Autres articles (69)

  • MediaSPIP v0.2

    21 juin 2013, par

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

  • Mise à disposition des fichiers

    14 avril 2011, par

    Par défaut, lors de son initialisation, MediaSPIP ne permet pas aux visiteurs de télécharger les fichiers qu’ils soient originaux ou le résultat de leur transformation ou encodage. Il permet uniquement de les visualiser.
    Cependant, il est possible et facile d’autoriser les visiteurs à avoir accès à ces documents et ce sous différentes formes.
    Tout cela se passe dans la page de configuration du squelette. Il vous faut aller dans l’espace d’administration du canal, et choisir dans la navigation (...)

  • Configuration spécifique pour PHP5

    4 février 2011, par

    PHP5 est obligatoire, vous pouvez l’installer en suivant ce tutoriel spécifique.
    Il est recommandé dans un premier temps de désactiver le safe_mode, cependant, s’il est correctement configuré et que les binaires nécessaires sont accessibles, MediaSPIP devrait fonctionner correctement avec le safe_mode activé.
    Modules spécifiques
    Il est nécessaire d’installer certains modules PHP spécifiques, via le gestionnaire de paquet de votre distribution ou manuellement : php5-mysql pour la connectivité avec la (...)

Sur d’autres sites (8684)

  • Anomalie #4128 : Bug de génération de boucle avec les modèles Spip

    11 avril 2018, par b b

    Un truc que je ne comprends pas, c’est que tu signales dans les points 7 & 8 que "Cela fonctionne sur la version minimal mais pas sur la version production." & "Le bug n’apparait plus..". Tu as donc trouvé l’origine du problème ou non ?

  • How to install ffmpeg on UBI docker images ?

    7 janvier 2024, par S. D.

    I'm looking for a simple way to install ffmpeg in a UBI8 (ubi-minimal) docker image.

    


    I tried running in the dockerfile the following :

    


    RUN microdnf upgrade
RUN microdnf install ffmpeg


    


    And I'm getting :

    


    ------
 > [7/8] RUN microdnf install ffmpeg:
#11 0.375
#11 0.375 (microdnf:1): librhsm-WARNING **: 07:58:19.229: Found 0 entitlement certificates
#11 0.375
#11 0.375 (microdnf:1): librhsm-WARNING **: 07:58:19.230: Found 0 entitlement certificates
#11 0.519 error: No package matches 'ffmpeg'
------
executor failed running [/bin/sh -c microdnf install ffmpeg]: exit code: 1



    


    How can ffmpeg be easily installed on UBI 8 ?

    


    Note : I tried referring to numerous references on the web that explain how that may be done, such as this one and this as well, but UBI seems to be working differently.

    


  • libavformat stuck in ff_network_wait_fd

    3 juin 2020, par Daniel

    I'm using libavformat for remuxing some live video feeds (rtsp).

    



    I can't really create a minimal reproducable example, because the issue is not reproducable, but I have an attached debugger and if I have any minimal chance to examine the root cause I'd not skip any chance.

    



    The stream is opened via avformat_open_input, and there is a custom IO for writing the output (avformat_alloc_output_context2).

    



    The problem is that avformat is stuck in ff_network_wait_fd, at least by gdb :

    



    #0  0xb673e120 in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x004a3ff4 in ff_network_wait_fd (fd=-1357954584, write=1) at libavformat/network.c:72
#2  0xaf0f428e in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)


    



    There was a network failure during the connection or the stream and I have not got any aggressive stream closing mechanism (everything is non blocking, there is no waits, sleeps, everything is event-based by libev).

    



    This just happened once during one month so it's very hard to reproduce but it is still running and gdb is attached.

    



    I'm curious if I have any chance to dig deeper. The stack seems corrupted and also the fd seems invalid for what ff_network_wait_fd waits for.

    



    Also, I never call ff_network_wait_fd directly, but there is an alternative : ff_network_wait_fd_timeout. Is it possible to ask libavformat to use this alternative so it won't block my thread if there is unreliable network ?

    


Navigation