LINUX.ORG.RU

Запись потока RTSP с уличной камеры в файл

 , ,


1

2

Здравствуйте, коллеги!

Пытаюсь на коленках организовать запись с наружных камер видеонаблюдения на локальный HDD. Камеры простые, отдают поток RTSP по ссылке вида

rtsp://111.222.333.444:554/user=user&password=password&channel=1&stream=0?.sdp

В качестве граббера потока выбрал ffmpeg, который (теоретически) должен уметь выполнять конструкцию вида

/usr/bin/ffmpeg -i ‘rtsp://111.222.333.444:554/user=user&password=password&channel=1&stream=0?.sdp’ ~/Videos/cam01.mp4

Поток живой, VLC открывает и показывает с минимальной разумной задержкой (секунда-две). При этом ffmpeg пытается подключиться, пасует на UDP, переключается на TCP но и там отваливается по тайм-ауту со словами «Output file #0 does not contain any stream».

При этом, на этапе записи НЕ стоит задача перекодировки потока. Только захват и запись, остальное, при необходимости, можно будет выполнить позже. Для этого попробовал указать -vcodec copy -acodec copy, но ffmpeg version 3.4.7 Copyright (c) 2000-2019 the FFmpeg developers built with gcc 4.8.5 (GCC) 20150623 (Red Hat 4.8.5-39) отказался. Говорит: «Unknown decoder ‘copy’».

Планирую загнать под cron и запускать процесс, скажем, каждый час, убив его предшественника с задержкой в несколько секунд, чтобы обеспечить незначительный перехлёст в записи, исключив разрывы.

В общем, прошу помощи: как правильно должна выглядеть строка запуска ffmpeg под мою задачу?

Заранее признателен!

P.S. Сюда, по понятным причинам, выложить не могу, но, если кому-то будет нужно для исследования данной проблемы, в личку готов дать ссылку на реальный поток.


-vcodec copy -acodec copy
Unknown decoder copy

Наверное, ты ставишь перед -i Это указывает какой декодер использовать, вместо автоопределения. После -i указывает в каком формате сохранять.

запускать процесс, скажем, каждый час, убив его предшественника

Если убивать, то в mp4 лучше не сохранять, файл будет нечитаемым при некорректном завершении. Лучше всего для этих целей подойдет контейнер ts, или mkv хотя бы.

anonymous ()

У меня так работает

IP=10.11.12.13
CAMNUM=1

while :; do
    if check_ping -H "$IP" -w 10,25% -c 20,50% -t 10 >/dev/null 2>/dev/null; then
      DATE=$(date '+%F')
      START=$(date '+%H-%M-%S')

      mkdir -p /Cams/cam0$CAMNUM/$DATE

      timeout -k 5 305 ffmpeg -rtsp_transport tcp -i 'rtsp://'"$IP"'/user=admin&password=P@SSW0RD&channel=1&stream=0' -r 30 -vcodec copy -an -t 300 "/Cams/cam0$CAMNUM/$DATE/hms_${START}.mp4" </dev/null >/dev/null 2>/dev/null
   else
       echo "$DATE $START : No ping to camera N${CAMNUM}, \"${IP}\""
       sleep 60
   fi
done

futurama ★★★★ ()
Последнее исправление: futurama (всего исправлений: 1)
Ответ на: комментарий от futurama

Ваще огонь!

Спасибо, коллега!

Исчерпывающе подробно! Всегда бы такие ответы получать.

Тогда уж, если позволите, задам дополнительный вопрос: с чем может быть связан систематический обрыв в потоке (примерно через 45-50 сек. после подключения), приводящий к остановке записи, при условии, что сам канал от хоста до камеры - безупречен как по bandwidth, так и по latency ?

root66 ()
Ответ на: Re: Ваще огонь! от futurama

Сам склоняюсь к мысли, что что-то не так с камерой. VLC показывает с неё те же 47 сек., после чего схлопывается.

Вторая (с противоположной стороны дома) работает вполне устойчиво: 300 сек. дала записать без сбоев.

Есть ли какие-либо средства диагностики такого рода проблем, помимо простой смены камер?

root66 ()
Ответ на: комментарий от root66

если поток забирается по udp unicast то нужно раз в ~45-120 секунд «пинговать» rtsp сервер, vlc это должен делать, но возможно сервер rtsp игнорирует это или ожидает только какую-то определённую команду rtsp.

если забирать поток по tcp такого быть не должно.

в настройках vlc можно переключить на rtp over rtsp (tcp). то есть гонять всё в 1 tcp соединении. (Advanced Options -> Input/Codecs -> Demuxers-> Rtp/Rtsp->Use RTP over RTSP(TCP))

rtsp сервер вправе игнорировать желание клиента получить поток через tcp.

на камере это может настраиваться.

dhampire ★★★ ()
Последнее исправление: dhampire (всего исправлений: 1)
Ответ на: комментарий от root66

Можешь писать кусочками по секунд 20-30 в цикле, потом их склеивать по желанию в один большой файл. Если канал нормальный, то теряешь максимум длину кусочка + время на реконнект. Еще можно тоже кусочками писать, но использовать -f segment.

lu4nik ★★★ ()

Как вариант попробуй тянуть через GStreamer:

$ gst-launch-1.0 playbin uri=rtsp://111.222.333.444:554/user=user&password=password&channel=1&stream=0?.sdp

У него свой rtsp клиент, может быть с ним будет стабильно работать. Есть ещё live555. У него в демках есть какой-то rtsp клиент.

ox55ff ★★★ ()
Ответ на: комментарий от dhampire

Две камеры стоят за NAT’ом (Mikrotik, RouterOS v6.42.12), на котором соответственно проброшены два порта TCP: дефолтный 554 (для одной камеры) и 555 (для второй). UDP закрыт.

Попытка настроить RTP-over-RTSP в VLC результатов не дала. Сидя в том же доме, на том же провайдере (по сути - на одном коммуматоре на чердаке), получаю при записи через VLC ролик продолжительностью 02:03, после чего поток обрывается.

root66 ()
Последнее исправление: root66 (всего исправлений: 1)