这个问题是由 FFmepg 的缺陷导致的，至今(2019年)仍未解决。

引发问题的根源在于 HLS/m3u8 流文件列表中，存在两个相邻切片之间的 TS 包计数不连续。（TS 包计数不连续的情况，可在 直播过程中存在推流中断后重推 的 直播流/回放流列表 中出现）

对于这种情况，HLS/m3u8 流文件列表会在与前者计数不连续的文件前加上 EXT-X-DISCONTINUITY 标签来显式地告诉播放器留意。

但遗憾的是，FFmpeg 的 HLS 处理模块不支持该标签，进而导致遇到计数不连续的 TS 时，无意识地强制合并两个计数不连续的 TS，导致 Non-monotonous DTS in output stream 警告，再加上其他一些缺陷，最终导致合并后时间码不正确。

说明

本文结论由我本人在参阅了大量相关问题汇报、社区提问后得出；部分参阅的文章链接见文末。

其中，最有价值的是

• FFmpeg 的 bugtrack ticket #5419：https://trac.ffmpeg.org/ticket/5419
• 名为 user2286522 的用户在...

阅读全文>>

参考文章:

https://stackoverflow.com/questions/30829364/open-utf8-encoded-filename-in-c-windows

https://stackoverflow.com/questions/821873/how-to-open-an-stdfstream-ofstream-or-ifstream-with-a-unicode-filename

https://stackoverflow.com/questions/6975267/c-saving-file-with-unicode-name-problem-how-to-save-utf-8-filenames-correctl

阅读全文>>