<p>I've solved the issue by rebuilding the timestamps from scratch with <code>-use_wallclock_as_timestamps 1</code> and <code>-fflags +genpts</code>.</p>

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

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

CC BY-SA 3.0
2018-01-30T06:57:34.103Z
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
CC BY-SA 3.0
2018-01-30T07:27:21.070Z
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
CC BY-SA 3.0
2018-01-29T19:14:06.537Z
2018-01-29T19:14:06.537Z
mjktfw
<p>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.</p>

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

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

<hr>

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

<pre><code>Delay between the first packet and last packet in the muxing queue is 10020000 &gt; 10000000: forcing output
</code></pre>

<hr>

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

<p>Night mode: reported framerate converges to 13 fps and inital frames are passed with 488 DTS</p>

<pre><code>...
[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
</code></pre>

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

<p>But each time the input stream is defined as:</p>

<pre><code>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
</code></pre>

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

<p>What could be the issue? Why this is specific to night-mode only?</p>

<hr>

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

<p>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):</p>

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

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

<ul>
<li>pkt_duration_time = 0.05s, pkt_duration = 4500</li>
<li>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</li>
</ul>

<p>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.</p>

<p><strong>Questions:</strong> </p>

<ul>
<li>Are RTP h264 DTS/PTS given by stream itself, or calculated by ffmpeg?</li>
<li>What's the proper way to modify these to match audio DTS/PTS?</li>
</ul>

<p><a href="https://i.sstatic.net/8h59J.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/8h59J.png" alt="RTSP"></a></p>

<ffmpeg><streaming><transcoding><linux><rtmp>
RTSP to RTMP converting fails after specific time only when IP camera enters night mode
mjktfw
# RTSP to RTMP converting fails after specific time only when IP camera enters night mode

(Asked by: username_0 on 2018-01-02)

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?

**Tags:** ffmpeg, streaming, transcoding, linux, rtmp


---

## 1 answers

### Answer by username_0 on 2018-01-29. Score: 5 | Accepted answer

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.

> **Comments:**
> **username_1**: Your input stream config as set in the input video bitstream is different than actual frame throughput. Happens during night or low-power mode.  
> **username_0**: 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.  

---

