Преобразование RTSP в RTMP завершается сбоем через определенное время, только когда IP-камера переходит в ночной режим.

Купил дешевую IP камеру Escam QF002 с выводом в RTSP. Я хотел бы защитить его с помощью потока RTMP или HLS, обслуживаемого nginx с модулем nginx-rtmp.

Для этого я бы скопировал видеопоток (h264) и перекодировал аудио (pcm_alaw -> aac), используя:

/usr/bin/ffmpeg -loglevel debug \
  -i 'rtsp://192.168.1.2:554/user=admin&password=******&channel=0&stream=0.sdp?real_stream--rtp-caching=100' \
  -vcodec copy -acodec aac -f flv "rtmp://localhost/escam/stream"

Через ~260 секунд (каждый раз одно и то же значение) успешного потока корректный вывод больше не производится, и сообщение рассылается спамом:

Delay between the first packet and last packet in the muxing queue is 10020000 > 10000000: forcing output

Кажется, это происходит только тогда, когда камера находится в «ночном/инфракрасном» режиме. Некоторые различия могут быть зарегистрированы:

Ночной режим: заявленная частота кадров достигает 13 кадров в секунду, а исходные кадры передаются с разрешением 488 DTS.

...
[flv @ 0x1d53710] Non-monotonous DTS in output stream 0:0; previous: 488, current: 385; changing to 488. This may result in incorrect timestamps in the output file.
....
frame= 1451 fps= 13 q=-1.0 size=    5357kB time=00:02:11.84 bitrate= 332.8kbits/s speed=1.16x

Дневной режим: заявленная частота кадров сходится к 20 кадрам в секунду, а начальные кадры передаются с 300 DTS.

Но каждый раз входной поток определяется как:

Stream #0:0, 0, 1/1000: Video: h264 (Main), 1 reference frame ([7][0][0][0] / 0x0007), yuvj420p(pc, bt709, progressive, left), 1280x720 (0x0), 0/1, q=2-31, 20 fps, 13 tbr, 1k tbn, 90k tbc
Stream #0:1, 0, 1/1000: Audio: pcm_alaw ([7][0][0][0] / 0x0007), 8000 Hz, mono, 64 kb/s

Пока что только отключение аудиопотока -anпозволяет осуществлять непрерывную потоковую передачу. Копирование потока без перекодирования аудио ( -acodec copy) или записи в файл приводит к той же ошибке.

В чем может быть проблема? Почему это относится только к ночному режиму?

РЕДАКТИРОВАТЬ: я думаю, мне нужно опубликовать это как другую тему, так как это оказывается проблемой XY.

Я предполагаю, что проблема связана с неправильным PTS/DTS для видеокадров, возвращаемых RTP. FFmpeg сообщает, что видеовход имеет 20 кадров в секунду, хотя на самом деле он возвращает ~ 13 кадров в секунду (tbr):

Stream #0:0: Video: h264 (Main), yuvj420p(pc, bt709, progressive), 1280x720, 20 fps, 13 tbr, 90k tbn, 40 tbc

Проверка входных кадров с помощью ffprobe -show_frames -read_intervals %+100 'rtsp://host/stream'дает следующую информацию для видеокадров:

• pkt_duration_time = 0,05 с, pkt_duration = 4500
• приращение pkt_pts равно 6923, приращение pkt_pts_time ~ 0,077 с, то же самое относится к pkt_dts, pkt_dts_time, а также к best_effort_timestamp, best_effort_timestamp_time

PTS/DTS нужно каким-то образом пересчитать из значения по умолчанию 0,05 (я не уверен, что это делается с помощью ffmpeg или самого источника). Однако этот интервал слишком мал по сравнению с аудиопотоком, как показано на графике ниже. Это приводит к тому, что видео ремультируется быстрее, чем аудио.

Вопросов:

• RTP h264 DTS/PTS задается самим потоком или рассчитывается ffmpeg?
• Каков правильный способ изменить их, чтобы они соответствовали аудио DTS/PTS?