-vcodec copy -acodec copy
Unknown decoder copy

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

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

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

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

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

Ваще огонь!

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

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

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

может софт в камере кривой? В плейере vlc/mpv видео идет без обрывов?

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

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

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

если поток забирается по 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.

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

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

Можно дурацкий вопрос: какая модель камеры (если не секрет, конечно)?

Как вариант попробуй тянуть через 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 клиент.

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

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

систематический обрыв в потоке

Были похожие проблемы с камерой 3s vision n8032w. Лечилось обновление прошивки камеры.