记录一次解决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分段问题。

推荐阅读更多精彩内容