ffmpeg命令分析-r

Loken2020

已于 2024-01-02 19:13:04 修改

阅读量4.9k

点赞数 4

CC 4.0 BY-SA版权

分类专栏： FFmpeg源码分析文章标签： r语言开发语言

于 2022-03-11 17:51:05 首次发布

本文链接：https://blog.csdn.net/u012117034/article/details/123430682

FFmpeg源码分析专栏收录该内容

63 篇文章

订阅专栏

《FFmpeg原理》的社群来了，想加入社群的朋友请购买 VIP 版，VIP 版有更高级的内容与答疑服务。

本系列以 ffmpeg4.2 源码为准，下载地址：链接：百度网盘提取码：g3k8

之前的文章分析 FFMpeg 工程的 do_video_out() 函数的时候，建议不关注 delta0，delta，nb0_frames，nb_frames 等变量。

因为在之前的命令没有用帧率变换参数，-r 。所以上面这些变量赋值，有跟没有是一样的。

现在来补一下之前缺失的内容。命令行指定 -r 之后，delta0，delta，nb0_frames，nb_frames 的变化。

本文章主要讲解 FFMpeg 里面是如何实现帧率变换的，例如 24fps 是如何转成 8fps的，缩小了3倍的帧率。

./ffmpeg -i a.mp4 -r 8 output.flv 本文以此命令讲解，原始视频是24fps，转成 8fps。

a.mp4 下载链接：百度网盘，提取码：nl0s

如果没指定 -r ，就会从 buffersink 获取输出的帧率，帧率跟输入文件帧率一样，代码如下：

如果命令行指定了 -r ，就会用命令行参数赋值给 ost->frame_rate。，代码如下：

上面是命令行参数 -r 赋值给 ost->frame_rate。然后 ost->frame_rate 会作为时间基赋值给编码器的time_base，见下图代码：

所以，综上所述，-r 最后主要影响的是编码器的time_base，那编码器的time_base是怎么影响帧率变换的呢？请看下面。

在讲之前，需要普及一个知识点，请看下面代码

int a = av_rescale_q(1,  (AVRational){1, 24}, (AVRational){1, 12});
int b = av_rescale_q(2,  (AVRational){1, 24}, (AVRational){1, 12});

这里 a 跟 b 都是1，a不会是0.5。av_rescale_q() 返回的整数，所以精度丢失了。这也是为什么 reap_filtes() 内部会搞一个 float_pts 出来，这个float_pts 是有精度的。请看下图，编码器的time_base 的影响就在这里。

可以看到，上图代码把原始视频帧的pts 的时间基转成编码器的time_base了。这里是一个什么概念呢。

假如原始视频帧率是每秒24帧，他AVFrame的pts的时间基也是 {1,24}。那这时候这个 filtered_frame->pts 肯定是1,2,3,4 这样递增下去的。

把 filtered_frame->pts 转成编码器时间基 {1,8} 会怎样？

播放时间pts不变，1/24 = 0.041s ，第一帧在 0.041s 播放。然后 x/8 = 0.041，这个x等于多少呢？x = 0.333。

也就是说，第二帧的 filtered_frame->pts 原本是 1，时间基从 {1,24} 转成 {1,8} 之后，pts 从1 变成了 0.333。

类推，第三帧pts变成了 0.666，第四种变成0.999。

然后，这些跟帧率变换有什么关系？请继续看下面分析。

因为帧率变换涉及到好几个场景，这里只介绍 format_video_sync = VSYNC_VFR 的场景

接着分析，虽然上面说到，原始pts转换之后变成了 0.33,0.66 之类的小数。但是对于输入文件，对于编码器来说，编码器的帧率是 8fps，{1,8}，传递给编码器的frame的pts，肯定也必须是 1,2,3,4 这样的整数递增的。这里实现这个功能的是 ost->sync_opts 变量。

要好好分析一下 ost->sync_opts 这个变量，这个变量的初始值是 0，每输入一个frame给编码器，ost->sync_opts 就会+1。

如上图所示，do_video_out() 的 in_picture 帧的pts会被 ost->sync_opts 替换，达到输入给编码器的frame pts 都是 1,2,3,递增的目的。

接下来继续讲，上面那些0.33，0.66小数是用来干嘛的？其实这些小数就是用来丢帧，实现帧率缩小的功能，或者重复上一帧，实现帧率变大功能。

如下图所示，nb0_frames 这个变量不用管，在format_video_sync = VSYNC_VFR 的场景下，nb0_frames 总是0。

第一帧全是0，看不出上面的逻辑，直接从第二帧开始分析。第二帧 do_video_out() 传递的 sync_ipts 是0.333。但是此时 sync_opts 是 1。

大家可以仔细琢磨一下那句英文注释，老外写注释都比较简洁。

delta0 is the "drift" between the input frame (next_picture) and where it would fall in the output.

delta0 = 0.333 - 1 = -0.666，delta0 代表当前输入帧与输出给编码器的时间差距，在第二帧的时候，时间差是 0.666。解析到这里，应该有点眉目，缩小帧率，肯定要根据时间差距来丢弃某些帧。

说实话，他这个算法有点复杂，我也不太明白他为什么不 sync_ipts < sync_opts 就直接丢弃，这样不是更简单？这个问题先不纠结，接着分析ffmpeg 是如何用delta0 ，delta 实现丢帧的。补充：直接 sync_ipts < sync_opts 不行，会出错。

这个算法涉及到不同刻度表的转换，用两个刻度表来解释这个算法会更明白。

delta0 = sync_ipts - ost->sync_opts; 
delta  = sync_ipts - ost->sync_opts + duration;

可以看到，因为 ost->sync_opts 每次都会 +1 地递增，而 sync_ipts 每次只能 +0.3 递增。所以delta会负得越来越大，duration是固定是 0.33。所以delta也会负得越来越大，然后 delta <= -0.6 就会把 nb_frames 置为 0 ，导致后面的for循环没执行，实现丢帧。至于为什么是0.6我也不知道。实在没想好怎么表达他这个算法逻辑，反正代码逻辑它就是这么跑的，delta越来越大，就丢帧。丢帧后，ost->sync_opts 不会+1，sync_ipts 就会慢慢赶上 sync_opts

case VSYNC_VFR:
    if (delta <= -0.6){
        //丢弃 frame
        nb_frames = 0;
    }
    else if (delta > 0.6)
        ost->sync_opts = lrint(sync_ipts);
    break;

实际丢帧情况如下。

0 0.33 0.66(x) 1(x) 1.33 1.66(x) 2(x) 2.33 2.66(x) 3(x)

只有 .33 后缀的帧才会保留，确实是缩小了3倍帧率。

实际上，他这个算法应该是一个数学公式，sync_ipts + duration + 60% 刻度 > sync_opts，如果大于 sync_opts就可以输出给解码器，小于就丢弃。这里的刻度是1，所以60%刻度是0.6。sync_ipts + duration 是因为只要这个frame的区间跨过 sync_opts 刻度，哪怕跨过一点点，都可以输出。

如果不改变帧率，sync_opts 跟 sync_ipts 是同步+1的，duration也是1，然后 delta0 一直是一个非常小的接近0的数字，delta 一直是接近1的数字。

所以不改变帧率，delta0 跟delta 这些变量是没有作用的。

接下来继续分析帧率放大算法是如何实现的。

把帧率 {1,24} 转成 {1,48}，实际上就是把 pts 乘以 2 。

注意，有些MP4 是 VSYNC_CFR，有些是 VSYNC_VFR。

CFR 的帧率翻倍，会插入新帧，文件大小也会翻倍。

VFR 的帧率翻倍，不会插入新帧，文件大小不变。

 case VSYNC_CFR:
            // FIXME set to 0.5 after we fix some dts/pts bugs like in avidec.c
            if (frame_drop_threshold && delta < frame_drop_threshold && ost->frame_number) {
                nb_frames = 0;
            } else if (delta < -1.1)
                nb_frames = 0;
            else if (delta > 1.1) {
                nb_frames = lrintf(delta);
                if (delta0 > 1.1)
                    nb0_frames = lrintf(delta0 - 0.6);
            }
            break;
case VSYNC_VFR:
            if (delta <= -0.6){
                //丢弃 frame
                nb_frames = 0;
            }
            else if (delta > 0.6)
                ost->sync_opts = lrint(sync_ipts);
            break;

实际上，我个人认为，命令行参数 -r 在 ffmpeg.c 里面的实现是一个历史遗留问题，这种实现在 ffmpeg.c 里面暴露了太多的复杂性，实际上新版本的ffmpeg，例如 4.4 版本，已经有 fps，framerate 两个新的滤镜来实现帧率转换。

所以，调 API 函数实现帧率转换，推荐使用 fps，framerate 滤镜，就没有这么多 delta 变量之类的。

由于笔者的水平有限，加之编写的同时还要参与开发工作，文中难免会出现一些错误或者不准确的地方，恳请读者批评指正。