La conversión de RTSP a RTMP falla después de un tiempo específico solo cuando la cámara IP ingresa al modo nocturno

He comprado una cámara IP barata Escam QF002 que produce salida en RTSP. Me gustaría asegurarlo con RTMP o flujo HLS servido por nginx con nginx-rtmp-module.

Para esto, copiaría la transmisión de video (h264) y transcodificaría el audio (pcm_alaw -> aac), usando:

/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"

Después de ~260 segundos (el mismo valor cada vez) de transmisión exitosa, ya no se produce una salida válida y el mensaje se envía como spam:

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

Esto parece suceder solo cuando la cámara está en modo "nocturno/infrarrojo". Se pueden registrar algunas diferencias:

Modo nocturno: la velocidad de fotogramas informada converge a 13 fps y los fotogramas iniciales se pasan con 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

Modo diurno: los fps informados convergen a 20 fps y los cuadros iniciales se pasan con 300 DTS.

Pero cada vez que el flujo de entrada se define como:

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

Hasta ahora, solo deshabilitar la transmisión de audio -anpermite la transmisión continua. Copiar la transmisión sin volver a codificar el audio ( -acodec copy) o escribir en el archivo da como resultado el mismo error.

¿Cual podría ser el problema? ¿Por qué esto es específico solo para el modo nocturno?

EDITAR: Creo que necesito publicarlo como otro hilo, ya que resulta ser un problema XY.

Supongo que el problema está relacionado con PTS/DTS incorrectos para los cuadros de video devueltos por RTP. FFmpeg informa que la entrada de video tiene 20 fps, mientras que en realidad devuelve ~ 13 fps (tbr):

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

Sondear los cuadros de entrada con ffprobe -show_frames -read_intervals %+100 'rtsp://host/stream'da la siguiente información para los cuadros de video:

• pkt_duration_time = 0,05 s, pkt_duration = 4500
• el incremento de pkt_pts es 6923, el incremento de pkt_pts_time es ~ 0,077 s, lo mismo se aplica a pkt_dts, pkt_dts_time, así como best_effort_timestamp, best_effort_timestamp_time

El PTS/DTS debe volver a calcularse de alguna manera a partir del valor predeterminado 0.05 (no estoy seguro de si lo hizo ffmpeg o la propia fuente). Sin embargo, este intervalo es demasiado pequeño en comparación con la transmisión de audio, como se ve en el gráfico a continuación. Esto da como resultado que el video se remueve más rápido que el audio.

Preguntas:

• ¿Los RTP h264 DTS/PTS son proporcionados por la transmisión en sí o calculados por ffmpeg?
• ¿Cuál es la forma correcta de modificarlos para que coincidan con el audio DTS/PTS?