记录一次解决EXT-X-DISCONTINUITY PTS错误的历程

某天测试反馈，硬解某个hls流后面几秒钟无法播放，以为解码错误导致，但实际解码正常。经过排查（排查的过错有些曲折，就不细说了），发现是解码出来的PTS异常：某个包pts异常的大，导致渲染模块把后面收到的包都抛掉了。

为什么会突然来一个特别大的PTS？真实环境下各种乱七八糟的格式见得多了，搞不好是流本身的问题，这是我第一时间能想到的。只是软解可以正常播放，这促使我进一步去软解一探究竟，发现原来decoder修改了pts。ffmpeg 源代码简单分析 ： avcodec_decode_video2()
注意到这一行

av_frame_set_best_effort_timestamp(picture,  
                                               guess_correct_pts(avctx,  
                                                                 picture->pkt_pts,  
                                                                 picture->pkt_dts));  

guess_correct_pts返回了正确的pts。guess_correct_pts里面算法挺简单的，就是统计dts乱序的次数，然后确定最终是否用dts代替pts。
虽然从avformat得到的dts也是错的，decoder内部对dts也做了修正。修正就细节比较复杂，而iOS的硬解对DTS完全无视，除了自己移植这套算法，好像没有别的办法。

---

FFmpeg上来的dts也不能全信，也许它解析错了呢。所有要拿到原始数据，看他是不是真的有问题。
EasyICE可能是目前最强大的TS分析工具。用它分析了这条流，发现没有PTS相关错误（打脸了），所以这只能是avformat解析的bug。

FFmpeg本身不支持EXT-X-DISCONTINUITY，我们用的是IJK的分支https://github.com/Bilibili/FFmpeg（感谢IJK贡献了这么优秀的代码）。pts的相关计算代码如下

        if (c->playlists[minplaylist]->finished) {
            struct playlist *pls = c->playlists[minplaylist];
            int seq_no = pls->cur_seq_no - pls->start_seq_no;
            if (seq_no < pls->n_segments && s->streams[pkt->stream_index]) {
                struct segment *seg = pls->segments[seq_no];
                int64_t pred = av_rescale_q(seg->previous_duration,
                                            AV_TIME_BASE_Q,
                                            s->streams[pkt->stream_index]->time_base);
                int64_t max_ts = av_rescale_q(seg->start_time + seg->duration,
                                              AV_TIME_BASE_Q,
                                              s->streams[pkt->stream_index]->time_base);
                /* EXTINF duration is not precise enough */
                max_ts += 2 * AV_TIME_BASE;
                if (s->start_time > 0) {
                    max_ts += av_rescale_q(s->start_time,
                                           AV_TIME_BASE_Q,
                                           s->streams[pkt->stream_index]->time_base);
                }
                if (pkt->dts != AV_NOPTS_VALUE && pkt->dts + pred < max_ts) pkt->dts += pred;
                if (pkt->pts != AV_NOPTS_VALUE && pkt->pts + pred < max_ts) pkt->pts += pred;
            }
        }

pts和dts都加上了pred这么一个值，正是pred导致了那个包PTS偏大。要理解为什么加这个值，下面这幅图可以说明。

EXT-X-DISCONTINUITY

左右两边是两个不同的playlist（因为中间有EXT-X-DISCONTINUNITY标记），假设两个绿色部分是两个不同的包，p1和p2是PTS。根据HLS的规范，p1和p2不连续，p2的真实PTS应该是p2+duration1。

IJK的代码认为，pts + pred 的值比这个segment最大时间小（max_ts），那么就应该加上。而且当一次读取跨两个playlist的包时，文件指针移到了后一个playlist，max_ts就成了后一个的最大时间。所以p1被转换成一个很大的pts1，而p2 < p1，结果后面的pts变小反而被渲染丢掉了。

既然是因为buff跨两个文件导致，那能不能不让它跨过去？说起来简单，实施起来有很多事情要做

• avio读文件时，如果在读另一个文件，需要中断当前read
• 中断avio不是一个特别好的解决，因为作为一个抽象的io层，如果读不到所需要数据，会被认为遇到了EOF
• 不中断read，需要一个标记，指出某段buffer是某个文件
• avpkt也需要增加标记
• ...

重新思考了一下，其实没有必要这么复杂，只需要记录前一个pts，根据pts递增的特性就能判断

临时值引入

p0 < p1
p1 > p2

如果前一个pts比当前pts大，那么这个pts就是重新编码的pts，需要加上前一个的duration。

至此完美解决pts分段问题。