Recherche avancée

Médias (0)

Mot : - Tags -/upload

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

Autres articles (78)

  • Demande de création d’un canal

    12 mars 2010, par

    En fonction de la configuration de la plateforme, l’utilisateur peu avoir à sa disposition deux méthodes différentes de demande de création de canal. La première est au moment de son inscription, la seconde, après son inscription en remplissant un formulaire de demande.
    Les deux manières demandent les mêmes choses fonctionnent à peu près de la même manière, le futur utilisateur doit remplir une série de champ de formulaire permettant tout d’abord aux administrateurs d’avoir des informations quant à (...)

  • Gestion de la ferme

    2 mars 2010, par

    La ferme est gérée dans son ensemble par des "super admins".
    Certains réglages peuvent être fais afin de réguler les besoins des différents canaux.
    Dans un premier temps il utilise le plugin "Gestion de mutualisation"

  • MediaSPIP 0.1 Beta version

    25 avril 2011, par

    MediaSPIP 0.1 beta is the first version of MediaSPIP proclaimed as "usable".
    The zip file provided here only contains the sources of MediaSPIP in its standalone version.
    To get a working installation, you must manually install all-software dependencies on the server.
    If you want to use this archive for an installation in "farm mode", you will also need to proceed to other manual (...)

Sur d’autres sites (9848)

  • doc/example : Add http multi-client example code

    25 juillet 2015, par Stephan Holljes
    doc/example : Add http multi-client example code
    

    Signed-off-by : Stephan Holljes <klaxa1337@googlemail.com>

    • [DH] doc/examples/Makefile
    • [DH] doc/examples/http_multiclient.c
  • multithreaded client/server listener using ffmpeg to record video

    29 janvier 2014, par user1895639

    I've got a python project where I need to trigger start/stop of two Axis IP cameras using ffmpeg. I've gotten bits and pieces of this to work but can't put the whole thing together. A "listener" program runs on one machine that can accept messages from other machines to start and stop recordings.

    The listener responds to two commands only :

    START v :/video_dir/myvideo.mov
    STOP

    The START command is followed by the full path of a video file that it will record.
    When receiving a STOP command, the video recording should stop.

    I am using ffmpeg to attach to cameras, and manually doing this works :

    ffmpeg.exe -i rtsp ://cameraip/blah/blah -vcodec copy -acodec copy -y c :\temp\output.mov

    I can attach to the stream and upon hitting 'q' I can stop the recording.

    What I'd like to be able to do is relatively simple, I just can't wrap my head around it :

    Listener listens
    When it receives a START signal, it spawns two processes to start recording from each camera
    When it receives a STOP signal, it sends the 'q' keystroke to each process to tell ffmpeg to stop recording.

    I've got the listener part, but I'm just not sure how to get the multithreaded part down :

    while True:
       client,address = s.accept()
       data = client.recv( size )
       if data:
           if data.startswith(&#39;START&#39;):
               # start threads here
           elif data.startswith(&#39;STOP&#39;):
               # how to send a stop to the newly-created processes?

    In the thread code I'm doing this (which may be very incorrect) :

    subprocess.call(&#39;ffmpeg.exe -i "rtsp://cameraipstuff -vcodec copy -acodec copy -t 3600 -y &#39;+filename)  

    I can get this process to spawn off and I see it recording, but how can I send it a "q" message ? I can use a Queue to pass a stop message and then do something like

    win32com.client.Dispatch(&#39;WScript.Shell&#39;).SendKeys(&#39;q&#39;)

    but that seems awkward. Perhaps a pipe and sending q to stdin ? Regardless, I'm pretty sure using threads is the right approach (as opposed to calling subprocess.call('ffmpeg.exe ...') twice in a row), but I just don't know how to tie things together.

  • rtmpproto : Don’t include a client version in the unencrypted C1 handshake

    14 octobre 2016, par Martin Storsjö
    rtmpproto : Don’t include a client version in the unencrypted C1 handshake
    

    According to the public RTMP specification, these 4 bytes should
    be zero.

    librtmp in server mode assumes that the RTMPE (FP9) handshake is
    used if these bytes are nonzero.

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

    • [DBH] libavformat/rtmpproto.c