RTSP to RTMP converting fails after specific time only when IP camera enters night mode I have bought a cheap IP camera Escam QF002 producing output in RTSP.
I'd like to secure it with RTMP or HLS stream served by nginx with nginx-rtmp-module.

For this I'd copy the video stream (h264) and transcode audio(pcm_alaw -> aac), using:

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




After ~260 seconds (same value each time) of successfull stream, no valid output is produced any longer and the message is being spammed:

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




This seems to happen only when camera is in "night/infrared" mode. Some differences may be logged:

Night mode: reported framerate converges to 13 fps and inital frames are passed with 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


Day mode: reported fps converges to 20 fps, and and inital frames are passed with 300 DTS.

But each time the input stream is defined as:

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


So far only disabling the audio stream with -an allows for continuous streaming. Copying the stream without reencoding audio (-acodec copy) or writing to file results in same error. 

What could be the issue? Why this is specific to night-mode only?



EDIT:
I think I need to post it as another thread, since this turns out to be an XY problem.

I guess the issue is connected with improper PTS/DTS for the video frames returned by RTP. 
FFmpeg reports, that video input has 20fps, while actually it returns ~ 13fps (tbr):

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


Probing the input frames with ffprobe -show_frames -read_intervals %+100 'rtsp://host/stream' gives the following info for video frames:


pkt_duration_time = 0.05s, pkt_duration = 4500
increment of pkt_pts is 6923, increment of pkt_pts_time is ~ 0.077s, same apllies to pkt_dts, pkt_dts_time, as well as best_effort_timestamp, best_effort_timestamp_time


The PTS/DTS must be somehow recalculated from the default 0.05 (I'm not sure whether done by ffmpeg or source itself). However this interval is to small compared to audio stream - as seen on the graph below. This results in video being remuxed faster than audio.

Questions: 


Are RTP h264 DTS/PTS given by stream itself, or calculated by ffmpeg?
What's the proper way to modify these to match audio DTS/PTS?
I've solved the issue by rebuilding the timestamps from scratch with -use_wallclock_as_timestamps 1 and -fflags +genpts.

/usr/bin/ffmpeg -use_wallclock_as_timestamps 1 -i "rtsp://${source}" -fflags +genpts -vcodec copy -acodec aac -f flv "rtmp://${dest}"

This is only a partial solution, or rather workaround, as it's still unclear to me what causes this behavior.