Hexo

ijkplayer丢帧的处理方案

群里的基友大牙,前几天写了一个延迟的总结:相关链接

基于项目本身的实际情况考虑,我还是保留了缓冲区。

最后实现:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
ff_ffplay.c
read_thread()
for (;;) {
if (is->abort_request)
break;
......
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);
}
}
+ #endif
packet_queue_put(&is->audioq, pkt);
}
Note: 代码越精简,bug越少。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
static void control_queue_duration(FFPlayer *ffp, VideoState *is) {
if (is->max_cached_duration <= 0) {
return;
}
if (is->audio_st) {
return control_audio_queue_duration(ffp, is);
}
/* 可选: 一般情况都丢不到视频帧
if (is->video_st) {
return control_video_queue_duration(ffp, is);
}
*/
}

在有缓冲区的前提下,我的想法是:

  1. 暂停的时候不要丢帧(否则1:你的点播会出问题 2:如果你的缓冲区比丢帧的阀值大也会出问题)
  2. 只丢音频帧。(有些流不适合同时丢音视频帧:会出现视频的帧率变低,视频的延迟会累积。)
  3. 每次丢帧完,下一个循环是一个GOP周期(直播GOP, 也就是视频的关键帧间隔时间,建议是1-2秒),用GOP值而不用精准定时器,减少开销。
  4. 我期望的是渲染视频后再开始丢帧,所以我增加了ffp->first_video_frame_rendered == 1的判断,虽然在播放出画面前的is->paused值都是1,其实这句代码不加也没问题,不过这样更能表达意图,以及防止没考虑到的意外情况。

问题1: 丢帧的阀值和缓冲区的大小都是3秒,会不会造成刚缓冲完就丢了呢?
:不会!
代码分析:暂停的触发条件是没有数据了,会把paused置成1.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
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);
continue;
}
else
break;
}
return 1;
}

ffp_check_buffering_l这个的函数的作用是: 查看下可否把paused置成0.

也就是说,不管你缓冲区多大,只有消耗掉所有数据才会暂停,然后开始攒数据,达到缓冲区的时候恢复播放。
只能说缓冲区设置的越小,在流不稳定的情况下,卡顿次数会更多一些。

问题2: 直播是否可以不要缓冲区?如果要,是不是越小越好?

:平稳的流可以不要缓冲区,如果推流端不稳定,建议还是保持1-3秒缓冲。

看下ffp_check_buffering_l()

1
2
3
if (buf_time_percent >= 0 || buf_size_percent >= 0) {
buf_percent = FFMAX(buf_time_percent, buf_size_percent);
}

原生的是

1
2
3
if (buf_time_percent >= 0 && buf_size_percent >= 0) {
buf_percent = FFMIN(buf_time_percent, buf_size_percent);
}

原生的不好之处在于,判断size和时间,取最大值,这种方式作为SDK没关系,但最直播而言,不太合适

1
2
3
4
#define DEFAULT_HIGH_WATER_MARK_IN_BYTES (256 * 1024)
#define DEFAULT_FIRST_HIGH_WATER_MARK_IN_MS (100)
#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可能更好。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
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_ms;
} else {
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_ms;
//gongjia add.
if(ffp->blive){
if (hwm_in_ms > 3000){
hwm_in_ms = 3000;
}
}

再看下,time的缓冲池是用的音频的呢,还是视频的呢?

1
2
3
4
5
6
7
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_duration;
} else if (audio_cached_duration > 0) {
cached_duration_in_ms = (int)audio_cached_duration;
}

原来又是用的最小值
换算成百分比就是

1
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是否可以实现渲染的时候,丢掉待渲染的视频数据,达到跳帧的效果?

我参考别的平台,比如映客和咸蛋家,他们这块做的不错,画面不是加速的,而是切画面。

我思前想后,觉得只能采取两种方式做:

  1. 重连
  2. 跳帧渲染

重连其实可以不用考虑,因为重连的触发最好是抛ERROR,也可以在COMPELETED的时候重连,但要看具体情况。

你正常的时候重连,这是闹哪样?

我看映客的做法是这样,因为他们是双路流,音视频不同步大概3秒左右,就会重连一下,双路流要处理的逻辑很复杂,估计映客已经切回单路了。

如果你的主播糟糕的网络持续了很长一段时间(限速上行50KB/S 1-2分钟),播放端肯定就音画不同步,而且短时间很难恢复,这时候如果丢音频帧,追视频帧(画面加速),可能半天才恢复到当前,其实这时候最好是重连一下,免得用户等的久(但这种情况在实际场景中少见,等久一点问题也不大)


言归正传,想想怎么跳帧渲染吧

先分析这个函数: 用于显示每帧画面的

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
static void video_image_display2(FFPlayer *ffp)
{
VideoState *is = ffp->is;
Frame *vp;
//取出解码后的图像帧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,

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
// #define VIDEO_PICTURE_QUEUE_SIZE 3
#define VIDEO_PICTURE_QUEUE_SIZE_MIN (3)
#define VIDEO_PICTURE_QUEUE_SIZE_MAX (16)
#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)
goto fail;
..................
ffp->pictq_size = VIDEO_PICTURE_QUEUE_SIZE_DEFAULT; // 3
..................
static int frame_queue_init(FrameQueue *f, PacketQueue *pktq, int max_size, int keep_last)
{
int i;
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->pktq = pktq;
f->max_size = FFMIN(max_size, FRAME_QUEUE_SIZE); //视频帧队列是3
f->keep_last = !!keep_last;
for (i = 0; i < f->max_size; i++)
if (!(f->queue[i].frame = av_frame_alloc()))
return AVERROR(ENOMEM);
return 0;
}

如果你用默认值,你一次只能丢两个frame,即使你改成VIDEO_PICTURE_QUEUE_SIZE_MAX,也不过丢16个帧,1s左右
其实也不能满足我跳帧的需求

我增加一个清除frame接口

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
static void frame_queue_flush(FrameQueue *f)
{
SDL_LockMutex(f->mutex);
int i;
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_size; 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会有问题。

跳帧渲染貌似暂时行不通,那还是先丢解码前的视频包吧;