Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-30T06:57:34.103Z
Answers.Text: Your input stream config as set in the input video bitstream is different than actual frame throughput. Happens during night or low-power mode.
Answers.UserDisplayName: Gyan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-30T07:27:21.070Z
Answers.Text: 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.
Answers.UserDisplayName: mjktfw
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-29T19:14:06.537Z
Answers.LastActivityDate: 2018-01-29T19:14:06.537Z
Answers.UserDisplayName: mjktfw
Body: <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>
  
Tags: <ffmpeg><streaming><transcoding><linux><rtmp>
Title: RTSP to RTMP converting fails after specific time only when IP camera enters night mode
UserDisplayName: mjktfw
ThreadText: # 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?
  
  [![RTSP](https://i.sstatic.net/8h59J.png)](https://i.sstatic.net/8h59J.png)
  
  **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.  
  
  ---
  
  