Android 播放器首屏时间问题

因看到卢_俊 ——直播疑难杂症排查（3）— 首开慢的博文。故描述一下我在工作中遇到这方面问题的解决方式。

首先声明一下，因为是基于ijkplayer而封装的播放器,所以我的方案是在此基础上实现的。

在这篇直播疑难杂症排查（3）— 首开慢博文中总结了很全面，我读了收益很大。

2.1 点击播放后才从服务器取播放地址
2.2 DNS 解析慢
2.3 播放策略原因
2.4 播放参数配置
2.5 服务端线路原因

想必大家都对上述问题都做过相关研究且在实际的项目中优化过，所以我这里就描述一下不一样的地方。
主要探讨的是

2.4 播放参数配置

其实一开始的方案和文章所描述的一样，设置这2个参数来减少 avformat_find_stream_info 函数的调用时间。但由于需要解决下述问题：
1、很容易出现参数设置过大无法有效的减少时间调用，设置过小出现无法解析全部码流信息

因为需要提供通用的播放器SDK以支持多种流格式多种码率以及点播直播。所以决定试一试其它方案解决这个问题。

替换掉 avformat_find_stream_info 函数

这个想法是看到一篇博文VLC优化（1） avformat_find_stream_info接口延迟降低 中描述所启发。但实际操作中发现，此方案局限性太大。

avformat_find_stream_info 处理

比如都熟悉的RTMP协议，正常情况下RTMP流的视频元数据就在最前面.理论上打开速度应该非常快才对。不应该那么慢。参考对比rtmp web 播放。
想必avformat_find_stream_info 函数内部实行有些冗余的操作，导致耗时较长。
函数位于 libavformat/utils.c 文件里。日志分析，函数的大部分时间耗费在以下代码域中(相关文件代码)
以下是简易代码块。

for (;;)
{
....
}

其实里面就是死循环读取码流信息，正常退出条件:
直到读取到相关需要的信息
read_size >= probesize
读取的音频视频流的时长 >= max_analyze_duration
为何已经读取到了相关解码信息还不退出呢？查看一下循环内有一段是检查是否读取到了必须的信息

for (i = 0; i < ic->nb_streams; i++) {
        int fps_analyze_framecount = 20;
        
        st = ic->streams[i];
        if (!has_codec_parameters(st, NULL))
            break;
        /* If the timebase is coarse (like the usual millisecond precision
         * of mkv), we need to analyze more frames to reliably arrive at
         * the correct fps. */
        if (av_q2d(st->time_base) > 0.0005)
            fps_analyze_framecount *= 2;
        if (!tb_unreliable(st->internal->avctx))
            fps_analyze_framecount = 0;
        if (ic->fps_probe_size >= 0)
            fps_analyze_framecount = ic->fps_probe_size;
        if (st->disposition & AV_DISPOSITION_ATTACHED_PIC)
            fps_analyze_framecount = 0;
        /* variable fps and no guess at the real fps */
        if (!(st->r_frame_rate.num && st->avg_frame_rate.num) &&
            st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) {
            int count = (ic->iformat->flags & AVFMT_NOTIMESTAMPS) ?
                st->info->codec_info_duration_fields/2 :
                st->info->duration_count;
            if (count < fps_analyze_framecount)
                break;
        }
        if (st->parser && st->parser->parser->split &&
            !st->internal->avctx->extradata)
            break;
        if (st->first_dts == AV_NOPTS_VALUE &&
            !(ic->iformat->flags & AVFMT_NOTIMESTAMPS) &&
            st->codec_info_nb_frames < ((st->disposition & AV_DISPOSITION_ATTACHED_PIC) ? 1 : ic->max_ts_probe) &&
            (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO ||
             st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO))
            break;
    }

我们看到为何已经有了必须要的解码信息if (!has_codec_parameters(st, NULL)) 还需要读取那些信息才能退出呢？其实主要还是为了 fps 的信息获取操作。其实这个信息对视频打开播放没有影响。所以我在死循环内添加了以下逻辑代码:

     for (int j = 0; j < ic->nb_streams; j++){
        st = ic->streams[j];
        if (has_codec_parameters(st, NULL)){
            if (st->parser && st->parser->parser->split && !st->codecpar->extradata){
                av_log(ic, AV_LOG_DEBUG, "%d has_codec_parameters but no extradata \n",j);
            }else {
                if(st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO){
                    prob_video_ok = 1;
                    av_log(ic, AV_LOG_DEBUG, "%d video  has_codec_parameters \n",j);
                }else if(st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO){
                    prob_audio_ok = 1;
                    av_log(ic, AV_LOG_DEBUG, "%d audio  has_codec_parameters \n",j);
                }
            }
        }
    }       

当获取到了相关解码信息后直接就退出这个死循环。
经过测试确实减少了avformat_find_stream_info 函数调用时间，然后打开流的速度快了很多。
测试中发现有时候显示画面快,有时候显示慢。这是因为服务器没有设置缓存GOP或者I帧的策略导致的,因为第一帧画面需要I帧。

try_decode_frame 处理

因为播放业务集中在机顶盒上且是高码率的流，而机顶盒硬件性能太差。分析发现 try_decode_frame 这个函数多次调用消耗很多时间。看一下下面对这个函数的描述:

 /* If still no information, we try to open the codec and to
     * decompress the frame. We try to avoid that in most cases as
     * it takes longer and uses more memory. For MPEG-4, we need to
     * decompress for QuickTime.
     *
     * If AV_CODEC_CAP_CHANNEL_CONF is set this will force decoding of at
     * least one frame of codec data, this makes sure the codec initializes
     * the channel configuration and does not only trust the values from
     * the container. */

函数调用的地方描述了，要避免调用这个函数。因为这会消耗更长以及更多的内存。从上面描述来看其实不调用这个函数也不会有问题。

   if(decodec_state[pkt->stream_index] == 0)
    {
        int result = try_decode_frame(ic, st, pkt,(options && i < orig_nb_streams) ? &options[i] : NULL);
        if(result > 0){
            decodec_state[pkt->stream_index] = 1;
        }
    }

如果流的当前Track 已经成功解码，则下次就不用重复调用这个函数了。这个是因为的流很可能会出现前几帧一直都是视频帧,然后才是音频帧。导致多次调用视频帧进行try_decode_frame软解浪费时间,尤其在低端设备上面以及H265编码。

简单总结

其实没有什么需要总结的。直接看直播疑难杂症排查（3）— 首开慢这篇文章就好,已经总结的很好。不过最后强调一下

2.3 播放策略原因

这个优化也非常重要,不亚于avformat_find_stream_info的优化。

最后，本来打算做一个测试对比。因为发现没有大家都能访问的合适的测试流作为对比。而公司内部的流外部无法访问,也就作罢了。声明一下:本人水平有限。如有错误，敬请指教。谢谢！