最近在一个需求中，我需要批量从hls视频中截取出10s的视频，发现有很小概率会截取失败，
视频截取的完整命令如下：
ffmpeg -i https://file.xindoo.xyz/utopia-file/local/video/605d3af0a9cb469c91fbb309422e6672/playlist.m3u8 -r 15 -ss 19 -t 10.0 -b:v 4096k -vcodec libx264 12345.mp4
开始以为是hls中的视频片段有问题，后来和同事一起排查发现，所有失败的情况下，执行ffmpeg命令截取时都会报[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fd6fa008780] DTS 0 < 1986554 out of orderspeed=0x [hls @ 0x7fd6fa004a40] DTS 0 < 1986554 out of order ，顺着这个信息我们发现但凡失败的，都是我们在m3u8里拼接了另外一个视频的部分片段导致的。
要理解这个问题，我们首先需要解释下什么是DTS， DTS (Decoding TimeStamp)这是视频或音频帧应当被解码的时间。这个时间戳也是基于播放起始点的，告诉播放器什么时候应该开始解码这个帧。用大白话讲 DTS就是视频每一帧相对于这个视频开始事件点的位置。
我们在业务中为了能灵活且低成本获取任意时间段之间的视频，选择将原始视频切分一个个ts片段，按需选取后重新生成一个m3u8文件。 因为原始视频不是连续录制，所以就有一定的概率出现A视频的末尾和B视频的开始拼接在同一个m3u8中的可能。在这种情况下，A视频末尾一帧的DTS和B视频首帧的DTS肯定是不连续的，截取时就会报"DTS 0 < 1986554 out of order"，最终截取失败。
如何解决？我尝试了很多种参数，比如-vsync、-fflags +igndts，甚至切换了ffmpeg版本，均无法解决。最后还是用蠢办法，先将hls格式的视频保存成mp4然后从mp4中截取，绕开这个bug。具体的实现就是将上面的一条命令拆分成如下两条：
# 先转存成mp4文件
ffmpeg -i https://file.xindoo.xyz/utopia-file/local/video/605d3af0a9cb469c91fbb309422e6672/playlist.m3u8 -c:v copy temp.mp4
# 然后从mp4文件中截取视频
ffmpeg -i temp.mp4 -r 15 -ss 19 -t 10.0 -b:v 4096k -vcodec libx264 12345.mp4