2014-06-09 08:56:55 +0000 2014-06-09 08:56:55 +0000
18
18

Capturar o fluxo RTSP da Câmara IP e armazenar

Tenho algumas câmaras IP que emitem um fluxo RTSP (h264 mpeg4).

Batendo no URL localmente via VLC: rtsp://192.168.0.21:554/mpeg4

Posso fazer streaming da câmara e descarregar para o disco (no meu ambiente de trabalho). No entanto, gostaria de armazenar estes ficheiros no meu NAS (FreeNAS). Estava a procurar formas de capturar o fluxo RTSP e descarregá-los em disco, mas não consigo encontrar nada.

É possível capturar o fluxo em FreeBSD ou Linux (RaspberryPi) e despejar o conteúdo do fluxo num disco local para Linux ou FreeBSD - de preferência a cada 30minutos?

EDIT: O NAS não tem cabeça (HP N55L ou algo assim) e os RaspberryPi’s também não têm cabeça.

Já investiguei o ZoneMinder mas preciso de algo pequeno. Esperava talvez usar Motion para detectar movimento no fluxo, mas isso virá mais tarde.

Respostas (4)

30
30
30
2015-05-29 22:33:16 +0000

As câmaras IP são de qualidade variável, algumas comportando-se de forma errática na minha experiência. Lidar com os seus fluxos RTSP requer uma dose de tolerância a falhas.

O projecto Live555 fornece uma implementação relativamente tolerante a falhas de clientes RTSP, openRTSP, para puxar fluxos de áudio/vídeo RTSP via CLI: http://www.live555.com/openRTSP/

Por exemplo, para guardar o áudio/vídeo RTSP de uma câmara para ficheiros em formato QuickTime (AVI e MP4 também disponíveis), um ficheiro a cada 15 minutos:

$ 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

Estas opções significam:

-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

A remoção da opção -t faz com que o OpenRTSP seja, em vez disso, o padrão do UDP, o que pode reduzir um pouco o tráfego de rede. Terá de jogar com as opções a fim de encontrar a combinação que mais lhe convém.

Francamente, as próprias câmaras são por vezes pouco fiáveis, ou apenas implementadas diferentemente -como fechar a tomada inesperadamente não é assim tão invulgar.

Por vezes, o cliente doRTSP aberto não apanha estas falhas. Assim, optei por codificar um controlador em Python utilizando o módulo ‘subprocessos’ para invocar e monitorizar o stdout de cada instância do cliente openRTSP, e também verificar se os ficheiros continuam a crescer em tamanho.

Isto parece ser um subproduto da indústria de CCTV de gama baixa jogando rápido e solto com padrões, sendo RTSP e ONVIF os dois mais frequentemente abusados.

Felizmente, é normalmente possível contornar estes problemas. A menos que as suas câmaras IP e o seu controlador sejam todos concebidos para jogarem bem em conjunto, utilize apenas ONVIF para uma única descoberta e gestão de configurações.

Utilizo o openRTSP em algumas Raspberry Pi B+ rodando Raspbian. Cada fluxo 1280x1024 ocupa cerca de 8-10% do tempo da CPU, e já executei com sucesso até oito câmaras por RPi, escrevendo os ficheiros para o armazenamento NAS. Outro RPi processa ficheiros completados com ffmpeg, procurando movimento e produzindo índices PNG desses frames, para ajudar na detecção de arrombamentos.

Existe um esforço de código aberto chamado ZoneMinder que faz esta última parte, mas não consegui pô-lo a funcionar com as minhas câmaras. O suporte ONVIF é novo e nascente em ZM, e não parece estar a lidar bem com os fluxos de RTSP mal vistos produzidos pelo meu gestor de câmaras IP com menos de 100 dólares.

7
7
7
2017-06-26 12:49:23 +0000

Se eu seguir a sua pergunta correctamente, porque não tenta o seguinte comando num sistema 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"

Isto deverá salvar o vídeo em pedaços de 300 segundos. (Note que o comprimento do clip dependerá das suas taxas de frame de entrada e saída)

7
7
7
2015-04-01 22:52:30 +0000

Pensei apenas em adicionar os meus dois cêntimos e complementar a resposta de BjornR.

Em vez de executar um cron job para matar periodicamente o processo VLC, podia-se dizer à VLC para correr durante um determinado período de tempo e fechar depois.

Este é o comando que eu corro na minha caixa:

/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

Isto executa a VLC durante o período de tempo especificado e mais tarde fecha. O parâmetro vlc://quit é necessário, uma vez que a VLC deixaria de gravar e ficaria aberta. Este comando precisa de ser colocado dentro de um laço.

O único problema que encontrei até agora é que pode falhar alguns segundos de cada vez que uma nova gravação começa.

5
5
5
2014-06-09 12:06:59 +0000

VLC parece ser um candidato ideal para processar o seu fluxo Métodos básicos para capturar um fluxo são descritos no sítio web da Videolan. Gravei com sucesso a saída da minha câmara de rede D-Link DCS-5222 usando o seguinte comando:

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

No seu caso, isto pode funcionar para guardar a saída localmente:

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

Sugiro que execute um script que termine este processo vlc e lance uma nova instância a cada 30 minutos, pois não tenho a certeza de que a VLC seja capaz de o fazer.

Quanto ao armazenamento num NAS, basta montá-lo no seu sistema de ficheiros local.