web-dev-qa-db-fra.com

Capturer le flux RTSP de la caméra IP et le stocker

J'ai quelques caméras IP qui sortent un flux RTSP (h264 mpeg4).

Frapper l'URL localement via VLC: rtsp: //192.168.0.21: 554/mpeg4

Je peux diffuser la caméra et la sauvegarder sur le disque (sur mon bureau). Je voudrais cependant stocker ces fichiers sur mon NAS (FreeNAS). Je cherchais des moyens de capturer le flux RTSP et de le vider sur disque, mais je ne trouve rien.

Est-il possible de capturer le flux sur FreeBSD ou Linux (RaspberryPi) et de transférer le contenu diffusé sur un disque local vers Linux ou FreeBSD - de préférence toutes les 30 minutes?

EDIT: Le NAS est sans tête (HP N55L ou autre) et les RaspberryPi sont aussi sans tête.

J'ai déjà examiné ZoneMinder mais j'ai besoin de quelque chose de petit. J'espérais peut-être utiliser Motion pour détecter les mouvements sur le flux, mais cela viendra plus tard.

16
Keerthi

Les caméras IP sont de qualité variable, certaines se comportent de manière erratique selon mon expérience. Traiter leurs flux RTSP nécessite une dose de tolérance aux pannes.

Le projet Live555 fournit une implémentation du client RTSP relativement tolérante aux pannes, openRTSP, pour extraire des flux audio/vidéo RTSP via CLI: http://www.live555.com/openRTSP/

Par exemple, pour enregistrer le fichier audio/vidéo RTSP d'une caméra dans des fichiers au format QuickTime (AVI et MP4 également disponibles), un fichier toutes les 15 minutes:

$ openRTSP -D 1 -c -B 10000000 -b 10000000 -q -Q -F cam_eight -d 28800 -P 900 -t -u admin 123456 rtsp://192.168.1.108:554/11

Ces options signifient:

-D 1 # Quit if no packets for 1 second or more
-c   # Continuously record, after completion of -d timeframe
-B 10000000 # Input buffer of 10 MB
-b 10000000 # Output buffer 10MB (to file)
-q   # Produce files in QuickTime format
-Q   # Display QOS statistics 
-F cam_eight  # Prefix output filenames with this text
-d 28800      # Run openRTSP this many seconds
-P 900        # Start a new output file every -P seconds
-t            # Request camera end stream over TCP, not UDP
-u admin 123456  # Username and password expected by camera
rtsp://192.168.1.108:554/11  # Camera's RTSP URL

Si vous supprimez l'option -t, openRTSP utilisera UDP par défaut, ce qui réduira un peu le trafic réseau. Vous aurez besoin de jouer avec les options afin de trouver la combinaison qui vous convient.

Franchement, les caméras elles-mêmes ne sont parfois pas fiables, ou simplement mises en œuvre différemment - la fermeture inattendue du socket n’est pas si inhabituelle.

Parfois, le client openRTSP ne détecte pas ces problèmes. J'ai donc choisi de coder un contrôleur en Python en utilisant le module 'sous-processus' pour appeler et surveiller la sortie standard de chaque instance de client openRTSP, ainsi que pour vérifier que la taille des fichiers continue de croître.

Cela semble être un sous-produit du bas de gamme de l'industrie de la vidéosurveillance jouant rapidement avec les normes, RTSP et ONVIF étant les deux victimes les plus fréquemment maltraitées.

Heureusement, vous pouvez généralement contourner ces problèmes. Sauf si vos caméras IP et votre contrôleur sont tous conçus pour fonctionner correctement, utilisez uniquement ONVIF pour la découverte unique et la gestion des paramètres.

J'utilise openRTSP sur quelques Raspberry Pi B + exécutant Raspbian. Chaque flux 1280x1024 occupe environ 8 à 10% du temps de la CPU et j'ai réussi à gérer jusqu'à huit caméras par RPi, en écrivant les fichiers sur le stockage NAS. Un autre fichier RPi traite les fichiers terminés avec ffmpeg, recherche des mouvements et génère des PNG d'index de ces images, afin de faciliter la détection des intrusions.

Il y a un effort open-source appelé ZoneMinder qui fait cette dernière partie, mais je n'ai pas pu le faire fonctionner avec mes caméras. Le support ONVIF est nouveau et naissant dans ZM, et il semble ne pas supporter les flux RTSP irréguliers produits par ma ménagerie de caméras IP de moins de 100 dollars.

24
Kevin-Prichard

Je pensais juste ajouter mes deux sous et compléter la réponse de BjornR.

Au lieu d'exécuter un travail cron pour supprimer périodiquement le processus VLC, vous pouvez indiquer à VLC de s'exécuter pendant une durée déterminée et de se fermer par la suite.

Voici la commande que je lance sur ma boîte:

/usr/bin/vlc -vvv rtsp://192.168.1.128:1554/11 --sout=file/ts:/media/path/to/save/location/recording-$(date +"%Y%m%d%H%M%S").ts -I dummy --stop-time=480 vlc://quit

Cela exécute VLC pendant la durée spécifiée et se termine ultérieurement. Le paramètre vlc: // quit est requis car VLC arrêterait d’enregistrer et rester ouvert. Cette commande doit être placée dans une boucle.

Le seul problème que j'ai constaté jusqu'à présent est qu'il peut manquer quelques secondes à chaque démarrage d'un nouvel enregistrement.

7
Juanpi

VLC semble être le candidat idéal pour traiter votre flux. Les méthodes de base pour capturer un flux sont décrites sur le site Web Videolan. J'ai enregistré avec succès la sortie de ma caméra réseau D-Link DCS-5222 à l'aide de la commande suivante:

vlc rtsp://user:password@ip/play1.sdp --sout=file/ogg:mystream.ogv

Dans votre cas, cela pourrait fonctionner pour enregistrer la sortie localement:

vlc rtsp://192.168.0.21:554/mpeg4 --sout=file/ts:mystream.mpg

Je suggérerais d'exécuter un script qui termine ce processus vlc et de lancer une nouvelle instance toutes les 30 minutes, car je ne suis pas sûr que VLC puisse le faire.

Pour ce qui est du stockage sur un NAS, montez-le simplement sur votre système de fichiers local.

5
BjornR1989

Si je suis votre question correctement, pourquoi ne pas essayer la commande suivante sur un système Linux (RPi):

ffmpeg -i rtsp://192.168.0.21:554/mpeg4 -vcodec copy -acodec copy -map 0 -f segment -segment_time 300 -segment_format mp4 "ffmpeg_capture-%03d.mp4"

Cela devrait enregistrer la vidéo par tranches de 300 secondes. (Notez que la longueur du clip dépendra de votre fréquence d'images d'entrée et de sortie.)

4
Aldo