ffmpeg - "Non-monotonous DTS in output stream"每 13 小时 14 分钟

Question

我对 zeranoe 的最新 ffmpeg 有疑问。每 13h14m ffmpeg 停止录制。

ffmpeg started on 2017-09-28 at 10:36:49
Report written to "ffmpeg-20170928-103649.log"
Command line:
"D:\\ffmpeg\\ffmpeg.exe" -report
ffmpeg version N-87353-g183fd30 Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 7.2.0 (GCC)
  configuration: --disable-static --enable-shared --enable-gpl --enable-version3 --enable-cuda --enable-cuvid --enable-d3d11va --enable-dxva2 --enable-libmfx --enable-nvenc --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib
  libavutil      55. 76.100 / 55. 76.100
  libavcodec     57.106.101 / 57.106.101
  libavformat    57. 82.101 / 57. 82.101
  libavdevice    57.  8.101 / 57.  8.101
  libavfilter     6.105.100 /  6.105.100
  libswscale      4.  7.103 /  4.  7.103
  libswresample   2.  8.100 /  2.  8.100
  libpostproc    54.  6.100 / 54.  6.100
Splitting the commandline.
Reading option '-report' ... matched as option 'report' (generate a report) with argument '1'.
Finished splitting the commandline.
Parsing a group of options: global .
Applying option report (generate a report) with argument 1.
Successfully parsed a group of options.
Hyper fast Audio and Video encoder

我从 3 个摄像头录制视频流。

流 1:

Input #0, rtp, from 'rtp://225.1.1.1:1024':
  Duration: N/A, start: 60424.501000, bitrate: N/A
  Program 1
    Stream #0:0: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(progressiv
e), 1920x1080 [SAR 1:1 DAR 16:9], 50 fps, 50 tbr, 90k tbn, 100 tbc
    Stream #0:1(eng): Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, mono,
fltp, 164 kb/s

流 2,3:

Input #0, rtsp, from 'rtsp://192.168.3.36:554/stream1':
  Metadata:
    title           : Session streamed by "Pelco Streaming Server"
    comment         : stream1
  Duration: N/A, start: 0.219167, bitrate: N/A
    Stream #0:0: Video: h264 (Baseline), yuv420p(progressive), 640x480, 25 fps,
25 tbr, 90k tbn, 50 tbc

我使用单独的 ffmpeg 实例每 1 分钟记录一次分段，例如:

ffmpeg -i "rtsp://192.168.3.36:554/stream1" -vcodec copy -an -f segment -strftime 1 -segment_time 60 "novus-%Y-%m-%d_%H-%M-%S.ts"

每 13 小时 14 分钟(从录制开始)，每个 ffmpeg 都会停止录制，并显示诸如“输出流 0:0 中的非单调 DTS”之类的消息。当我启动每个 ffmpeg 实例时并不重要:如果我在实例 №1 之后 1 分钟启动实例 №2，它将相应地在 №1 之后的 1 分钟内停止录制。我在两台 PC 上试过:Windows Server 2012 x64 和 Windows 10 x64。

...
[NULL @ 000000000034a900] SEI type 5 size 408 truncated at 160
[segment @ 000000000034e780] stream:0 start_pts_time:47640.5 pts:4289549528 pts_time:47661.7 dts:4289549528 dts_time:47661.7 -> pts:4289549528 pts_time:47661.7 dts:4289549528 dts_time:47661.7
[NULL @ 000000000034a900] SEI type 5 size 408 truncated at 160
[segment @ 000000000034e780] stream:0 start_pts_time:47640.5 pts:4289553131 pts_time:47661.7 dts:4289553131 dts_time:47661.7 -> pts:4289553131 pts_time:47661.7 dts:4289553131 dts_time:47661.7
[NULL @ 000000000034a900] SEI type 5 size 408 truncated at 160
[segment @ 000000000034e780] stream:0 start_pts_time:47640.5 pts:4289556734 pts_time:47661.7 dts:4289556734 dts_time:47661.7 -> pts:4289556734 pts_time:47661.7 dts:4289556734 dts_time:47661.7
[NULL @ 000000000034a900] SEI type 5 size 336 truncated at 160
[segment @ 000000000034e780] Non-monotonous DTS in output stream 0:0; previous: 4289535114, current: -5428580; changing to 4289535115. This may result in incorrect timestamps in the output file.
[segment @ 000000000034e780] stream:0 start_pts_time:47640.5 pts:4289556735 pts_time:47661.7 dts:4289556735 dts_time:47661.7 -> pts:4289556735 pts_time:47661.7 dts:4289556735 dts_time:47661.7
[NULL @ 000000000034a900] SEI type 5 size 408 truncated at 160
[segment @ 000000000034e780] Non-monotonous DTS in output stream 0:0; previous: 4289535115, current: -5424977; changing to 4289535116. This may result in incorrect timestamps in the output file.
[segment @ 000000000034e780] stream:0 start_pts_time:47640.5 pts:4289556736 pts_time:47661.7 dts:4289556736 dts_time:47661.7 -> pts:4289556736 pts_time:47661.7 dts:4289556736 dts_time:47661.7
[NULL @ 000000000034a900] SEI type 5 size 408 truncated at 160
[segment @ 000000000034e780] Non-monotonous DTS in output stream 0:0; previous: 4289535116, current: -5421374; changing to 4289535117. This may result in incorrect timestamps in the output file.
[segment @ 000000000034e780] stream:0 start_pts_time:47640.5 pts:4289556737 pts_time:47661.7 dts:4289556737 dts_time:47661.7 -> pts:4289556737 pts_time:47661.7 dts:4289556737 dts_time:47661.7
frame=1190370 fps= 25 q=-1.0 size=N/A time=13:14:21.50 bitrate=N/A speed=   1x    
[NULL @ 000000000034a900] SEI type 5 size 408 truncated at 160
[segment @ 000000000034e780] Non-monotonous DTS in output stream 0:0; previous: 4289535117, current: -5417772; changing to 4289535118. This may result in incorrect timestamps in the output file.
...

此问题的完整调试日志在这里(25 Mb，压缩):https://drive.google.com/file/d/0B1LIS8G55R7-OGY4QkdkQ0J1cVE/view?usp=sharing我无法无限录制视频。每 13 个小时我就会中断录音。我试着用“copytb 1”、“genpts”来记录，但没有用。我不认为这是网络问题，因为我试图通过两个 ffmpeg 实例记录相同的 rtsp 流，并且开始时移:它们分别卡在不同的时间。有谁知道如何解决它？我可以为您提供您需要的其他信息。

更新:如果我在错误出现后等待 13 小时，记录会再次开始。

Answer 1

对于某些 IP 摄像机，我们也意识到了这个问题，并找到了解决方法:

-correct_ts_overflow 0

说明:它源于 FFMPEG 中的几个问题。首先，时间戳由 RTP 分路器生成。当摄像头有多个流时，将使用 RTCP ntp 时间和 RTP 时间戳一起生成时间戳，以实现正确的流计时。但是，对于只有一个流，累积时间戳是从 RTP 时间戳生成的。问题在于某些摄像机在 SDP 中报告的起始时间戳大于用作基本时间戳的第一个 RTP 数据包时间戳。这反过来会创建一个传递给 ff_read_frame 的负时间戳。另一个问题是 RTSP/RTP 将其时间戳包装位设置为 32 位。问题是在单个流的情况下，时间戳实际上是一个 int 64 位时间戳，因为时间戳不是绝对时间戳，而是累积时间戳。此时间戳在正时间戳的第 63 位之前不会换行。

但是我们发现，在对 ff_read_frame 的调用中，有一些逻辑可以处理在翻转情况下用于查找的 PTS/DTS 包装。因为在这种情况下第一个时间戳是负数并且 wrap 位设置为 32 位，所以 wrap 代码设置不正确。因此，对于以负时间戳开头的相机，当时间戳的值大于某个索引值时，换行代码会从时间戳中减去 UINT32MAX(我相信 UINT32MAX 之前大约有 60 秒的视频)。然后从 ff_read_frame 中生成一个新的负时间戳。由于 ffmpeg.c 然后将其检测为非单调时间戳，因此新的输出时间戳仅比旧的打乱整个输出流的时间戳大一个刻度。然后，它需要另一个 UINT32MAX 时间戳才能从 RTP 多路分解器中恢复过来，或者大约需要 13 个小时。