记录＜一次点播的无法seek的问题跟踪＞的bug的完整排查思路

一. 问题背景

长达26个小时的KPL直播.Seek到中间偏后的时候会卡死不动.但是前面1-2个小时可以Seek.

二. 问题跟踪

大家有兴趣可以先看看Mac上终端调试FFmpeg任意版本源码的最佳实践

这个问题刚开始跟踪的时候,首先想到的是是不是视频源的问题.是用vlc和flv去尝试.奇怪的是vlc也不支持.但是ffmpeg支持.
此时我们来跟踪问题,发现到了JitterBuffer层之后无法往解码层送数据

// 正在 seek
if (packet->pts - packet->start_pts < seek_to_timestamp_) {
   
LOG_DEBUG("OnAudioPacketDemuxed, drop audio packet : %lld, start : %lld, seek time : %lld", packet->pts, packet->start_pts, seek_to_timestamp_);
return true;
}

两者相减为负数,我们要去seek的pts不对.到底为什么不对呢?

1. 首先怀疑的是解析pts出错了?

因为此流地址是

http://xxx/playlist_eof.m3u8

我们下载后看里面ts文件可知

流的第一个ts分片:
http://xxx_1.ts?start=0&end=2475019&type=mpegts
pts=8171962796

中间的某一个:
http://xxx_525.ts?start=24645672&end=26180503&type=mpegts
pts=4399514004

最后一个:
http://xxx_1302.ts?start=24598860&end=25023363&type=mpegts
pts=6771267804

现在通过ffmpeg工具查看ts分片后得知:

ffplay http://xxx_1.ts\?start\=0\&end\=2475019\&type\=mpegts

可正常播放.
然后用命令行看一下pts.

ffprobe -show_packets http://xxx_1.ts\?start\=0\&end\=247501