Recherche avancée

Médias (91)

Autres articles (83)

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

  • ANNEXE : Les plugins utilisés spécifiquement pour la ferme

    5 mars 2010, par

    Le site central/maître de la ferme a besoin d’utiliser plusieurs plugins supplémentaires vis à vis des canaux pour son bon fonctionnement. le plugin Gestion de la mutualisation ; le plugin inscription3 pour gérer les inscriptions et les demandes de création d’instance de mutualisation dès l’inscription des utilisateurs ; le plugin verifier qui fournit une API de vérification des champs (utilisé par inscription3) ; le plugin champs extras v2 nécessité par inscription3 (...)

  • Multilang : améliorer l’interface pour les blocs multilingues

    18 février 2011, par

    Multilang est un plugin supplémentaire qui n’est pas activé par défaut lors de l’initialisation de MediaSPIP.
    Après son activation, une préconfiguration est mise en place automatiquement par MediaSPIP init permettant à la nouvelle fonctionnalité d’être automatiquement opérationnelle. Il n’est donc pas obligatoire de passer par une étape de configuration pour cela.

Sur d’autres sites (5154)

  • arm : Fix SIGBUS on ARM when compiled with binutils 2.29

    31 août 2017, par Martin Storsjö
    arm : Fix SIGBUS on ARM when compiled with binutils 2.29
    

    In binutils 2.29, the behavior of the ADR instruction changed so that 1 is
    added to the address of a Thumb function (previously nothing was added). This
    allows the loaded address to be passed to a BLX instruction and the correct
    mode change will occur.

    See : https://sourceware.org/bugzilla/show_bug.cgi?id=21458

    By using adr with a label that isn’t annotated as a thumb function,
    we avoid the new behaviour in binutils 2.29 and get the same behaviour
    as in prior releases, and as in other assemblers (ms armasm.exe,
    clang’s built in assembler) - an idea that Janne Grunau came up with.

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

    • [DBH] libavcodec/arm/h264idct_neon.S
  • Using FFmpeg within a python application : ffmpeg tool or libav* libraries ?

    5 septembre 2017, par user2457666

    I am working on a python project that uses ffmpeg as part of its core functionality. Essentially the functionality from ffmpeg that I use boils down to these two commands :

    ffmpeg -i udp:// -qscale:v 2 -vf "fps=30" sttest%04d.jpg
    ffmpeg -i udp:// -map data-re -codec copy -f data out.bin

    Pretty simple stuff.

    I am trying to create a self-contained program (which uses the above ffmpeg functionality) that can easily be installed on any particular system without relying on that system having the necessary dependencies, as hopefully I would package those dependencies with the program itself.

    With that in mind, would it be best to use the libav* libraries to perform this functionality from within the program ? Or would a wrapper (ffmpy) for the ffmpeg command line tool be a better option ? My current thinking on the drawbacks of each is that using the libraries may be the best practice, but it seems overly complex to have to learn how to use them (and potentially learn C, which I’ve never learned, in the process) just to do those two basic things I mentioned above. The libraries overall are a bit of a bit of a black box to me and don’t have very much documentation. But the problem with using a wrapper for ffmpeg would be that it essentially relies on calling a subprocess, which seems somewhat sloppy. Although I’m not sure why I feel so viscerally opposed to subprocesses.

  • Two USB cams to two rtsp-simple-servers simultaneously

    20 juin 2022, par Imm

    Like in title, I have 2 USB cams and I need to create two RTSP streams. I'm using FFmpeg and rtsp-simple-server and it's working with one cam with this configuration (rtsp-simple-server.yml) :

    &#xA;

    paths:&#xA;  cam:&#xA;    runOnInit: ffmpeg -f dshow -video_device_number 0 -i video="UVC Camera" -c:v libx264 -preset ultrafast -tune zerolatency -b:v 600k -f rtsp rtsp://192.168.5.203:8554/cam&#xA;    runOnInitRestart: yes&#xA;

    &#xA;

    but I can't figure it out with second cam. I tried to make second instance of rtsp-simple-server in separete console and it doesn't work. I set it up like this (and few other ways with different port etc.) :

    &#xA;

    paths:&#xA;  cam:&#xA;    runOnInit: ffmpeg -f dshow -video_device_number 1 -i video="UVC Camera" -c:v libx264 -preset ultrafast -tune zerolatency -b:v 600k -f rtsp rtsp://192.168.5.203:8555/cam2&#xA;    runOnInitRestart: yes&#xA;

    &#xA;

    I get this error as result : Only one use of each socket address (protocol / network address / port) is allowed. and I still think there is better way to solve this with proper configuration.

    &#xA;

    I hoping for your help !

    &#xA;