Capturez le flux RTSP de la caméra IP et stockez

J'ai quelques caméras IP qui produisent 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 vider sur le disque (sur mon bureau). J'aimerais cependant stocker ces fichiers sur mon NAS (FreeNAS). Je cherchais des moyens de capturer le flux RTSP et de les vider sur le disque, mais je ne trouve rien.

Est-il possible de capturer le flux sur FreeBSD ou Linux (RaspberryPi) et de vider 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 quelque chose) et les RaspberryPi sont également sans tête.

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

Les caméras IP sont de qualité variable, certaines se comportant de manière erratique d'après mon expérience. La gestion de leurs flux RTSP nécessite une dose de tolérance aux pannes.

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

Par exemple, pour enregistrer l'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

La suppression de l'option -t fait que openRTSP utilise par défaut UDP, ce qui peut réduire un peu le trafic réseau. Vous devrez jouer avec les options afin de trouver la combinaison qui vous convient.

Franchement, les caméras elles-mêmes sont parfois peu fiables, ou simplement mises en œuvre différemment - comme fermer la prise de manière inattendue n'est pas si inhabituel.

Parfois, le client openRTSP n'attrape 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, et également vérifier que les fichiers continuent de croître en taille.

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

Heureusement, vous pouvez généralement contourner ces problèmes. À moins que vos caméras IP et votre contrôleur ne soient tous conçus pour fonctionner correctement ensemble, n'utilisez ONVIF que pour la découverte 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 du processeur, et j'ai réussi à exécuter jusqu'à huit caméras par RPi, en écrivant les fichiers sur le stockage NAS. Un autre RPi traite les fichiers terminés avec ffmpeg, recherchant le mouvement et produisant des PNG d'index de ces images, pour aider à repérer les effractions.

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 ne semble pas bien rivaliser avec les flux RTSP inégaux produits par ma ménagerie de caméras IP de moins de 100 $.

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

Au lieu d'exécuter un travail cron pour tuer périodiquement le processus VLC, on pourrait dire à VLC de s'exécuter pendant une durée spécifiée et de se fermer ensuite.

Voici la commande que j'exécute sur ma box:

/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 ferme plus tard. Le paramètre vlc: // quit est requis car VLC arrêterait l'enregistrement et resterait ouvert. Cette commande doit être placée dans une boucle.

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

Si je suis bien votre question, pourquoi n'essayez-vous pas 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 en morceaux de 300 secondes. (Notez que la longueur du clip dépendra de vos fréquences d'images d'entrée et de sortie)

VLC ressemble à un candidat idéal pour traiter votre flux. Les méthodes de base pour capturer un flux sont décrites sur le site Web de 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ère d'exécuter un script qui met fin à ce processus vlc et de lancer une nouvelle instance toutes les 30 minutes car je ne suis pas sûr que VLC soit capable de le faire.

Quant au stockage sur un NAS, montez-le simplement sur votre système de fichiers local.