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://******&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.


  • 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?


1 Answer 1


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.

  • Your input stream config as set in the input video bitstream is different than actual frame throughput. Happens during night or low-power mode.
    – Gyan
    Jan 30, 2018 at 6:57
  • Is then the posted method the proper solution, or should I consider another approach? Setting variable fps on input with -re option does not work as it causes multiple packets to drop.
    – mjktfw
    Jan 30, 2018 at 7:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.