工作小记 ffmpeg avcodec_receive_frame 缓存问题

Zip-List

已于 2023-12-11 13:46:04 修改

阅读量2.4k

点赞数 2

分类专栏：工作杂记文章标签： ffmpeg 缓存

于 2022-11-08 00:30:16 首次发布

本文链接：https://blog.csdn.net/qq_41565920/article/details/127721294

版权

工作杂记专栏收录该内容

13 篇文章 1 订阅

订阅专栏

最近的流媒体项目中，在拉车辆流的过程中，发现调用ffmpeg avcodec_send_packet 和avcodec_receive_frame 时总是不能做到送入1包，立刻吐出对应pts的一帧，总是有缓存2-3帧的问题。对于普通的播放器已经足够，但是平行驾驶要求的极低延时就无法做到了。因为传输的h264流完全是只有IP帧，并没有依赖后向的B帧。所以开始调查问题解决办法。
1 首先尝试一些低延时参数，无效

AVDictionary *avdic=NULL;
av_dict_set(&avdic, "rtsp_transport", "tcp", 1);
av_dict_set(&avdic, "muxdelay", "0", 0);
av_dict_set(&avdic, "fflags", "nobuffer", 0);
av_dict_set(&avdic, "tune", "zerolatency", 0);
av_dict_set(&avdic, "max_delay", "0", 0);
av_dict_set(&avdic, "preset", "superfast", 0);
av_dict_set(&avdic, "packet-buffering", "0", 0);

2 查看官网发现有送入flush包的说法，用于刷新解码器，但是只是用于seek操作
https://ffmpeg.org/doxygen/4.0/group__lavc__encdec.html
3 开始dump ffmepg和webrtc两端的流，终于发现端倪
dump类工具

#include <fstream>

class H264Dump
{
public:
    //static H264Dump &Instance();
    H264Dump();
    ~H264Dump();

    //void inputFrame(const H264Frame::Ptr &frame);
    void inputPkt(const char* data, int size);
    static int i;
    std::ofstream out;
    // std::mutex frame_list_mutex;
    // std::list<std::string> frame_list;
};

int H264Dump::i = 0;
H264Dump::H264Dump()
{
    std::string _ = "player_11_5_" + std::to_string(++H264Dump::i) + ".h264";
    out = std::ofstream( _ , std::ios_base::out | std::ios::trunc | std::ios::binary);
}
H264Dump::~H264Dump()
{
    out.close();
}

void H264Dump::inputPkt(const char* data, int size)
{
    out.write(data, size);
    out.flush();
}

_ffmpeg_dump_h264.inputPkt((char*)packet->data, packet->size);

相同的文件，webrtc在收端，接到的流和原文件有一些小小的差异。在每个I帧(5)pps帧(8)之前，即**sps帧(7)**有一些不同，影响到了解码器能否立刻输出的情况！
在这里插入图片描述
H264码流中SPS PPS详解
 vui参数的提问
 H264裸流分析中，能获取哪些信息？
BSAnalyzer工具分析dump下的流

可以看到主要的不同就是在于num_reorder_frames和max_dec_frame_buffering的设置，webrtc是01，而我们的是22对于IPPP这种时不要缓存或者重排的，修改编码器后，果然解决了。
能正常拉到的流不一定就没问题，要仔细分析sps，pps等参数!