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&password=******&channel=0&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 > 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?
