OBS直播软件的丢帧如何解决？ - 知乎5被浏览12843分享邀请回答1添加评论分享收藏感谢收起查看: 20419|回复: 1
【求助】obs丢帧严重，画面卡顿
阅读权限10
主题帖子积分
本人是联想y510p的笔记本，20m电信，以前都没有出现过丢帧的现象，最近直播老是丢帧，观众都反应有卡顿的现象，怎么解决？
威望1000424
阅读权限200
主题帖子积分
/thread-.html看了去
Powered byijkplayer丢帧的处理方案 - 简书
ijkplayer丢帧的处理方案
[如果觉得文章有用，可以支持一下放眼直播]
群里的基友大牙，写过一个延迟的总结：
看懂了代码你就知道，这个写法是不会因为丢帧引入花屏的，因为丢帧都是丢到I帧之前的P/B帧为止。我之前也写过一个类似的，思路都是一样，但这个代码更精简。
A：如果你想要实时性，可以去掉缓冲区，一句代码：
[options setPlayerOptionIntValue:0 forKey:@"packet-buffering"];
关闭播放器缓冲
如果你这样试过，发现你的项目中播放频繁卡顿，你想留1-2秒缓冲区，让数据更平缓一些，那你可以选择保留缓冲区，不设置上面那个就行。
我个人觉得：
网络卡的黑锅，不应该让直播播放器来背吧
做互动直播的话，还是不要缓冲区吧（我选A）~~~卡顿的原因比较多，具体问题要具体分析。只可惜实际上大多数直播网络都不太稳定，有CDN节点不足的问题，也有主播端自身和代码的各种问题（做直播一年多来，真的碰到了各种场景，各种坑）...
代码修改和分析：
1. 你可以加个变量，区分直播点播
ff_ffplay_debug.h
AVApplicationContext *app_
//gongjia add
------------------------
ff_ffplay.c
video_image_display2函数, 是在渲染线程video_refresh_thread里调用的
static void video_image_display2(FFPlayer *ffp)
VideoState *is = ffp-&
vp = frame_queue_peek_last(&is-&pictq);
int latest_seek_load_serial = __atomic_exchange_n(&(is-&latest_seek_load_serial), -1, memory_order_seq_cst);
if (latest_seek_load_serial == vp-&serial)
ffp-&stat.latest_seek_load_duration = (av_gettime() - is-&latest_seek_load_start_at) / 1000;
if (vp-&bmp) {
SDL_VoutDisplayYUVOverlay(ffp-&vout, vp-&bmp);
ffp-&stat.vfps = SDL_SpeedSamplerAdd(&ffp-&vfps_sampler, FFP_SHOW_VFPS_FFPLAY, "vfps[ffplay]");
if (!ffp-&first_video_frame_rendered) {
ffp-&first_video_frame_rendered = 1;
ffp_notify_msg1(ffp, FFP_MSG_VIDEO_RENDERING_START);
//gongjia add
这里可以判断是否是点播还是直播，如果你们平台只有直播，可以忽略
if(ffp-&blive == -1){
int duration_l = ffp_get_duration_l(ffp);
if(duration_l == 0) {
ffp-&blive = 1;
av_log(NULL, AV_LOG_INFO, "[gdebug %s: %d] blive = %d, %s\n", __FUNCTION__, __LINE__, ffp-&blive, ffp-&blive?"live":"vod");
}else if(duration_l & 0) {
ffp-&blive = 0;
av_log(NULL, AV_LOG_INFO, "[gdebug %s: %d] blive = %d, %s\n", __FUNCTION__, __LINE__, ffp-&blive, ffp-&blive?"live":"vod");
ffp-&blive = -1;
av_log(NULL, AV_LOG_ERROR, "[gdebug %s: %d]\n", __FUNCTION__, __LINE__);
---------------------------------------------
read_thread()
// 可以在最前面定义下初始化, 也可以在初始化函数里定义
+ ffp-&blive = -1;
//可以交给应用层设置，嫌麻烦就忽略这段代码
+ AVDictionaryEntry *is_live = av_dict_get(ffp-&player_opts, "islive", NULL, 0);
if (is_live) {
int islive = atoi(is_live-&value);
av_log(NULL, AV_LOG_ERROR, "[gdebug %s, %d]. get from java, islive = %d\n",__FUNCTION__, __LINE__, islive);
if (islive & 0) {
ffp-&blive = -1;
ffp-&blive =
ffp-&blive = -1;
err = avformat_find_stream_info(ic, opts);
这里就涉及到一个问题，读线程和显示线程的先后顺序问题
先看渲染线程video_refresh_thread&- stream_open&- ffp_prepare_async_l&-ijkmp_prepare_async_l&-ijkmp_prepare_async&-IjkMediaPlayer_prepareAsync
也就是在应用调用 _prepareAsync的时候同样，读数据线程read_thread也是在这时候创建的&- stream_open
看stream_open代码：
is-&video_refresh_tid = SDL_CreateThreadEx(&is-&_video_refresh_tid, video_refresh_thread, ffp, "ff_vout");
is-&read_tid = SDL_CreateThreadEx(&is-&_read_tid, read_thread, ffp, "ff_read");
两个线程是同时创建的，甚至从代码看，显示线程还建立的更早一步，但是只有先读到数据，才能喂给显示
因为每个图像是否能渲染，是有条件的： 非暂停状态
static int video_refresh_thread(void *arg)
FFPlayer *ffp =
VideoState *is = ffp-&
double remaining_time = 0.0;
while (!is-&abort_request) {
if (remaining_time & 0.0)
av_usleep((int)(int64_t)(remaining_time * ));
remaining_time = REFRESH_RATE;
if (is-&show_mode != SHOW_MODE_NONE && (!is-&paused || is-&force_refresh))
video_refresh(ffp, &remaining_time); //一定是非暂停状态才渲染（或者你设置强制渲染force_refresh）
所以说，video_image_display2会在读了一些数据后，才执行到， 我在这里再判断是否直播，判断一次就好，也没问题（也有个别例子，就是这个获取总时长不准，在一些rtsp的监控项目中也可见，这时候可以通过别的辅助手段）
继续往下走
read_thread()
for (;;) {
if (is-&abort_request)
if (pkt-&stream_index == is-&audio_stream && pkt_in_play_range) {
+ #ifdef MAX_CACHED_DURATION
if(!is-&paused && ffp-&blive && ffp-&first_video_frame_rendered == 1){
if (is-&max_cached_duration & 0 && (pkt-&flags & AV_PKT_FLAG_KEY)) {
control_queue_duration(ffp, is);
packet_queue_put(&is-&audioq, pkt);
Note： 代码越精简，bug越少。
static void control_queue_duration(FFPlayer *ffp, VideoState *is) {
if (is-&max_cached_duration &= 0) {
if (is-&audio_st) {
return control_audio_queue_duration(ffp, is);
可选： 一般情况都丢不到视频帧
if (is-&video_st) {
return control_video_queue_duration(ffp, is);
在有缓冲区的前提下，我的想法是：
暂停的时候不要丢帧（否则1：你的点播会出问题
2：如果你的缓冲区比丢帧的阀值大也会出问题）
只丢音频帧。（有些流不适合同时丢音视频帧：会出现视频的帧率变低，视频的延迟会累积。）
每次丢帧完，下一个循环是一个GOP周期（直播GOP, 也就是视频的关键帧间隔时间，建议是1-2秒），用GOP值而不用精准定时器，减少开销。
我期望的是渲染视频后再开始丢帧，所以我增加了ffp-&first_video_frame_rendered == 1的判断，虽然在播放出画面前的is-&paused值都是1，其实这句代码不加也没问题，不过这样更能表达意图，以及防止没考虑到的意外情况。
问题1： 丢帧的阀值和缓冲区的大小都是3秒，会不会造成刚缓冲完就丢了呢？
：不会！代码分析：暂停的触发条件是没有数据了，会把paused置成1.
static int packet_queue_get_or_buffering(FFPlayer *ffp, PacketQueue *q, AVPacket *pkt, int *serial, int *finished)
assert(finished);
if (!ffp-&packet_buffering)
return packet_queue_get(q, pkt, 1, serial);
while (1) {
int new_packet = packet_queue_get(q, pkt, 0, serial);
if (new_packet & 0)
return -1;
else if (new_packet == 0) { //没数据（解码前的收流数据）
if (q-&is_buffer_indicator && !*finished)
ffp_toggle_buffering(ffp, 1);
new_packet = packet_queue_get(q, pkt, 1, serial);
if (new_packet & 0)
return -1;
if (*finished == *serial) {
av_free_packet(pkt);
ffp_check_buffering_l这个的函数的作用是: 查看下可否把paused置成0.
也就是说，不管你缓冲区多大，只有消耗掉所有数据才会暂停，然后开始攒数据，达到缓冲区的时候恢复播放。只能说缓冲区设置的越小，在流不稳定的情况下，卡顿次数会更多一些。
问题2： 直播是否可以不要缓冲区？如果要，是不是越小越好？
：平稳的流可以不要缓冲区，如果推流端不稳定，建议还是保持1-3秒缓冲。
看下ffp_check_buffering_l()
if (buf_time_percent &= 0 || buf_size_percent &= 0) {
buf_percent = FFMAX(buf_time_percent, buf_size_percent);
if (buf_time_percent &= 0 && buf_size_percent &= 0) {
buf_percent = FFMIN(buf_time_percent, buf_size_percent);
原生的不好之处在于，判断size和时间，取最大值，这种方式作为SDK没关系，但最直播而言，不太合适
#define DEFAULT_HIGH_WATER_MARK_IN_BYTES
(256 * 1024)
#define DEFAULT_FIRST_HIGH_WATER_MARK_IN_MS
#define DEFAULT_NEXT_HIGH_WATER_MARK_IN_MS
(1 * 1000)
#define DEFAULT_LAST_HIGH_WATER_MARK_IN_MS
(5 * 1000)
看定义知道：缓冲区size是256K，time的话是阶梯式的：开始是100ms，然后1s，2s，3s，4s，5s，阶梯上升；我建议直播最大阀值改成3s可能更好。
if (need_start_buffering) {
if (hwm_in_ms & ffp-&dcc.next_high_water_mark_in_ms) {
hwm_in_ms = ffp-&dcc.next_high_water_mark_in_
hwm_in_ms *= 2;
if (hwm_in_ms & ffp-&dcc.last_high_water_mark_in_ms)
hwm_in_ms = ffp-&dcc.last_high_water_mark_in_
//gongjia add.
if(ffp-&blive == 1){
//直播， 如果你选A不要缓冲区的话，这个判断buffer的函数都不会调了，所以也不用改
if (hwm_in_ms & 3000){
hwm_in_ms = 3000;
再看下，time的缓冲池是用的音频的呢，还是视频的呢？
if (video_cached_duration & 0 && audio_cached_duration & 0) {
cached_duration_in_ms = (int)IJKMIN(video_cached_duration, audio_cached_duration);
} else if (video_cached_duration & 0) {
cached_duration_in_ms = (int)video_cached_
} else if (audio_cached_duration & 0) {
cached_duration_in_ms = (int)audio_cached_
原来又是用的最小值换算成百分比就是
buf_time_percent = (int)av_rescale(cached_duration_in_ms, 1005, hwm_in_ms * 10);
实际上，有些流的video_cached_duration是0，因为流各有差异。所以一般是用音频的时间作为缓冲buf，基本上size的buffer可以弃用，因为帧率和码率的缘故，size基本不准。
回到问题1，为什么暂停的时候不建议丢帧，因为会造成你刚攒够了数据，达到播放条件的时候，又达到了丢帧的max_cached_duration（我设置的是3s），你说是不是很杯具啊？
就是你刚领完工资就花没了，是不是感觉人生没有盼望啊？正所谓：患难生忍耐，忍耐生老练，老练生盼望......(罗马书5:8)
所以说如果你暂停也触发丢帧的话，你可能会卡住比较长的时间，影响体验。
这样改完，基本上就OK了，但还有个不好的体验，就是当主播网络抖动或者别的网络异常时，音频丢帧后，视频会加速播；
问题3： ijkplayer是否可以实现渲染的时候，丢掉待渲染的视频数据，达到跳帧的效果？
我参考别的平台，比如映客和咸蛋家，他们这块做的不错，画面不是加速的，而是切画面。
我思前想后，觉得只能采取两种方式做：
重连其实可以不用考虑，因为重连的触发最好是抛ERROR，也可以在COMPELETED的时候重连，但要看具体情况。
你正常的时候重连，这是闹哪样？
我看映客的做法是这样，因为他们是双路流，音视频不同步大概3秒左右，就会重连一下，双路流要处理的逻辑很复杂，双路流我也实现过并上线用了几个月，有好处有坏处，好处就是可以在低网络带宽下，流畅播放音频，坏处就是逻辑变复杂了，会引入bug，如果场景复杂了的话。 这个以后再说。
如果你的主播糟糕的网络持续了很长一段时间（限速上行50KB/S 1-2分钟），播放端肯定就音画不同步，而且短时间很难恢复，这时候如果丢音频帧，追视频帧（画面加速），可能半天才恢复到当前，其实这时候最好是重连一下，免得用户等的久（但这种情况在实际场景中少见，等久一点问题也不大）
言归正传，想想怎么跳帧渲染吧
先分析这个函数: 用于显示每帧画面的
static void video_image_display2(FFPlayer *ffp)
VideoState *is = ffp-&
//取出解码后的图像帧pictq
vp = frame_queue_peek(&is-&pictq);
if (vp-&bmp) {
//显示每帧图片
SDL_VoutDisplayYUVOverlay(ffp-&vout, vp-&bmp);
ffp-&stat.vfps = SDL_SpeedSamplerAdd(&ffp-&vfps_sampler, FFP_SHOW_VFPS_FFPLAY, "vfps[ffplay]");
if (!ffp-&first_video_frame_rendered) {
ffp-&first_video_frame_rendered = 1;
ffp_notify_msg1(ffp, FFP_MSG_VIDEO_RENDERING_START);
这样我就可以在显示的时候丢帧了，但是其实并不是这样，因为ijk定义的视频帧队列最大只有3个frame，
// #define VIDEO_PICTURE_QUEUE_SIZE 3
#define VIDEO_PICTURE_QUEUE_SIZE_MIN
#define VIDEO_PICTURE_QUEUE_SIZE_MAX
#define VIDEO_PICTURE_QUEUE_SIZE_DEFAULT
(VIDEO_PICTURE_QUEUE_SIZE_MIN)
#define SUBPICTURE_QUEUE_SIZE 16
#define SAMPLE_QUEUE_SIZE 9
#define FRAME_QUEUE_SIZE FFMAX(SAMPLE_QUEUE_SIZE, FFMAX(VIDEO_PICTURE_QUEUE_SIZE_MAX, SUBPICTURE_QUEUE_SIZE))
/* start video display */
if (frame_queue_init(&is-&pictq, &is-&videoq, ffp-&pictq_size, 1) & 0)
..................
ffp-&pictq_size
= VIDEO_PICTURE_QUEUE_SIZE_DEFAULT; // 3
..................
static int frame_queue_init(FrameQueue *f, PacketQueue *pktq, int max_size, int keep_last)
memset(f, 0, sizeof(FrameQueue));
if (!(f-&mutex = SDL_CreateMutex())) {
av_log(NULL, AV_LOG_FATAL, "SDL_CreateMutex(): %s\n", SDL_GetError());
return AVERROR(ENOMEM);
if (!(f-&cond = SDL_CreateCond())) {
av_log(NULL, AV_LOG_FATAL, "SDL_CreateCond(): %s\n", SDL_GetError());
return AVERROR(ENOMEM);
f-&max_size = FFMIN(max_size, FRAME_QUEUE_SIZE);
//视频帧队列是3
f-&keep_last = !!keep_
for (i = 0; i & f-&max_ i++)
if (!(f-&queue[i].frame = av_frame_alloc()))
return AVERROR(ENOMEM);
如果你用默认值，你一次只能丢两个frame，即使你改成VIDEO_PICTURE_QUEUE_SIZE_MAX，也不过丢16个帧，1s左右其实也不能满足我跳帧的需求
我增加一个清除frame接口
static void frame_queue_flush(FrameQueue *f)
SDL_LockMutex(f-&mutex);
av_log(NULL, AV_LOG_ERROR, "[gdebug %s: %d] f-&max_size = %d\n", __FUNCTION__, __LINE__, f-&max_size);
for (i = 0; i & f-&max_ i++) {
Frame *vp = &f-&queue[i];
frame_queue_unref_item(vp);
av_frame_free(&vp-&frame);
free_picture(vp);
SDL_UnlockMutex(f-&mutex);
如果我把f-&max_size
设置的无比大，比如30,60，那么读到的包会源源不断的来解码，然后显示，这样会不会有问题呢？
f-&max_size
超过16会有问题。
跳帧渲染貌似暂时行不通，那还是先丢解码前的视频包吧；
后记：关于抖动缓冲区 JitterBuffer
抖动缓冲区用于解决直播时网络抖动的问题，读者可以自行尝试。所谓网络抖动，就是网络延迟一会大一会小，在这种情况下，即使发送方是定时发送数据包的（比如每100ms发送一个包），而接收方的接收就无法同样定时了，有时一个周期内一个包都接收不到，有时一个周期内接收到好几个包。如此，导致接收方听到的声音就是一卡一卡的。
JitterBuffer工作于解码器之后，语音播放之前的环节。即语音解码完成后，将解码帧放入JitterBuffer，声卡的播放回调到来时，从JitterBuffer中取出最老的一帧进行播放。
JitterBuffer.png
JitterBuffer的缓冲深度取决于网络抖动的程度，网络抖动越大，缓冲深度越大，播放音频的延迟就越大。所以，JitterBuffer是利用了较高的延迟来换取声音的流畅播放的，因为相比声音一卡一卡来说，稍大一点的延迟但更流畅的效果，其主观体验要更好。
当然，JitterBuffer的缓冲深度不是一直不变的，而是根据网络抖动程度的变化而动态调整的。当网络恢复到非常平稳通畅时，缓冲深度会非常小，这样因为JitterBuffer而增加的播放延迟就可以忽略不计了。
音视频爱好者，人工智能的兴趣者。主修：计算机，历史，神学}