本文通过一些实验来验证i.MX6DQ在不同VPU时钟下的视频播放能力。
1.准备
Board: i.MX6DQ SD
比特流：1080p 向日葵，40Mbps，被认为是最艰难的 H264 剪辑。将原始片段复制20次，生成新的原始视频（重复20次向日葵片段），然后封装到mp4容器中。这是为了消除并尽量减少 gstreamer 启动工作负载相对于 vpu 单元测试的影响。
内核：使用不同的 VPU 时钟设置生成不同的内核：270MHz、298MHz、329MHz、352MHz、382MHz。
测试设置：1080p内容解码，使用1080p设备显示。（不调整大小）
2. VPU单元测试和Gstreamer的测试命令
平铺格式的视频播放速度比NV12格式的视频播放速度要快，所以在下面的实验中，我们选择平铺格式进行视频播放。
单元测试命令：（我们设置帧率-a 70，高于1080p 60fps的HDMI刷新率）
/unit_tests/mxc_vpu_test.out-D“-i/media/65a78bbd-1608-4d49-bca8-4e009cafac5e/sunflower_2B_2ref_WP_40Mbps.264-f 2-y 1-a 70”
Gstreamer命令：（自由运行以获得最高播放速度）
gst-启动文件 rc 位置=/media/65a78bbd-1608-4d49-bca8-4e009cafac5e/sunflower_2B_2ref_WP_40Mbps.mp4 typefind=true！艾尔德穆克斯！vpudec 帧丢失=false！队列最大大小缓冲区=3！mfw_v4lsink 同步=false
3. 视频播放帧率测量
测试时我们输入命令“echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor”来保证CPU始终工作在最高频率，这样才能快速响应任何中断。
对于每个具有不同 VPU 时钟的测试点，我们进行 5 轮测试。去掉最大值和最小值，对剩余的3个数据取平均值，得到最终的播放帧率。
| #1 | #2 | #3 | #4 | #5 | Min | 最大值 | 平均值 | |||||||
| 12月 | 播放 | 12月 | 播放 | 12月 | 播放 | 12月 | 播放 | 12月 | 播放 | 播放 | 播放 | 播放 | ||
| 2.7亿 | 单元测试 | 57.8 | 57.3 | 57.81 | 57.04 | 57.78 | 57.3 | 57.87 | 56.15 | 57.91 | 55.4 | 55.4 | 57.3 | 56.83 |
| 商品及服务税 | 53.76 | 54.163 | 54.136 | 54.273 | 53.659 | 53.659 | 54.273 | 54.01967 | ||||||
| 2.98亿 | 单元测试 | 60.97 | 58.37 | 60.98 | 58.55 | 60.97 | 57.8 | 60.94 | 58.07 | 60.98 | 58.65 | 57.8 | 58.65 | 58.33 |
| 商品及服务税 | 56.755 | 49.144 | 53.271 | 56.159 | 56.665 | 49.144 | 56.755 | 55.365 | ||||||
| 3.29亿 | 单元测试 | 63.8 | 59.52 | 63.92 | 52.63 | 63.8 | 58.1 | 63.82 | 58.26 | 63.78 | 59.34 | 52.63 | 59.52 | 58.56667 |
| 商品及服务税 | 57.815 | 55.857 | 56.862 | 58.637 | 56.703 | 55.857 | 58.637 | 57.12667 | ||||||
| 3.52亿 | 单元测试 | 65.79 | 59.63 | 65.78 | 59.68 | 65.78 | 59.65 | 66.16 | 49.21 | 65.93 | 57.67 | 49.21 | 59.68 | 58.98333 |
| 商品及服务税 | 58.668 | 59.103 | 56.419 | 58.08 | 58.312 | 56.419 | 59.103 | 58.35333 | ||||||
| 3.82亿 | 单元测试 | 64.34 | 56.58 | 67.8 | 58.73 | 67.75 | 59.68 | 67.81 | 59.36 | 67.77 | 59.76 | 56.58 | 59.76 | 59.25667 |
| 商品及服务税 | 59.753 | 58.893 | 58.972 | 58.273 | 59.238 | 58.273 | 59.753 | 59.03433 |
注：Dec列表示vpu解码fps，Playback列表示整体播放fps。
一些解释：
为什么单元测试比较平缓，但Gstreamer性能数据还是有提升的？在Gstreamer上，有一个vpu包装器，用于使vpu api更直观地被调用。因此首先，整体 GST 播放性能受到 vpu（vpu dec 57.8 fps）的限制。最后，随着 VPU 时钟增加，VPU 解码性能高于 60fps，限制变为显示刷新率 60fps。
Gstreamer的视频显示开销只有1fps左右，与单元测试差不多。
根据测试结果，我们可以看到，对于 352MHz，在 1080p 显示器上整体 1080p 视频播放可以达到 ~60fps。
或者，如果通过两个管道与两个显示器进行时间共享，我们可以进行 2 x 1080p @ 30fps 的视频播放。
但是，此实验对于在 1080p 显示器上播放 1080p 视频有效。如果隔行剪辑和显示的尺寸与 1080p 不同，则整体播放性能会受到一些后期处理（如去隔行和调整大小）的限制。
君平您好，
在 mfw_isink 之前我还需要使用队列吗？
vpu 使用 6 个 buffer 来解码，vl4sink 使用其中两个，queue 使用 3 个 buffer，不能设置太大，否则没有足够的 buffer 来运行
它们在缩小尺寸方面应该没有太大区别，因为它们都使用IPU
我懂了。我不知道。jackmao ，您能对此发表评论吗？
Leo
Hi Leo,
我确实需要缩小规模，但我的问题是：
使用 mfw_ipucsc 和 mfw_isink 缩小规模有什么区别？性能有提升吗？
Hi Tarek,
mfw_ipucsc是一个颜色空间转换和分辨率缩放器，因此如果您不需要这些功能，可以将其从管道中删除。另一方面，如果您添加它但没有在前面添加任何 capsfilter，（我相信）它不会执行任何操作。
Leo
Hi Leo,
我正在使用 mfw_isink，我认为它使用与 mfw_ipucsc 相同的 IPU。您认为使用它还有其他好处吗？
无论如何我都会尝试，所以我的管道将是这样的：
appsrc -> vpudec -> mfw_ipucsc -> mfw_isink。对吗？
jackmao应该更好地理解为什么我们需要减少队列的缓冲区。据我所知，vpudec 至少需要 6 个缓冲区运行，并且我们无法通过 vpudec 属性进行更改，因此唯一剩下的参数是队列的缓冲区。事实上，我检查了队列元素，似乎默认值是 200！！
最大缓冲区大小：最大。队列中的缓冲区数量（0=禁用）
标志：可读、可写
无符号整数。范围：0 - 4294967295 默认值：200 当前：200
顺便说一句，您是否尝试过使用 mfw_ipucsc 元素进行缩小比例？
Leo
Hi Leo,
1.我没有看到任何内存泄漏。我已经使用过 Top valgrind 和 mtrace，所以我毫不怀疑。
2. 我不太确定我是否理解了这一点！默认值是 20 个缓冲区，我们需要将此数字减少到 3 个缓冲区，以便 VPU不会耗尽缓冲区！我认为我们需要增加这个数量，对吗？
Hi Tarek,
1. 冻结问题：在管道运行时，您能监控 RAM 内存使用情况/空闲情况（top -b | grep Mem）吗？
2. 队列：我认为减少“最大缓冲区”的原因是 vpudec 需要一直在管道上运行一定数量的缓冲区，如果给出默认值，则 vpudec 在某个时候会用完缓冲区。
Hello,
感谢您提供此信息。这是非常有益的。
我正在调试一个相关问题并且有几个疑问。
问题：
我正在使用 gstreamer 将多个网络流（4 - 8 - 16）播放到 1080p 屏幕。屏幕仅支持 DVI，因此我使用 HDMI 转 DVI 电缆。当然，我正在使用 mfw_isink 元素缩小流以适应屏幕。所有流都正常启动，没有任何明显的错误，但几个小时后视频冻结，没有给出任何错误消息。
我使用的管道是
vpudec ->
appsr c->输出选择器->输入选择器->mfw_isink
jpegdec->
我的问题：
1.该系统将全天候播放视频，我不在乎功耗。总是使用命令“echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor”更好吗？
2.为什么在解码器和接收器之间使用“ queue max-size-buffers=3” ？您如何确定缓冲区大小=3？
3. 你们有监控VPU和IPU性能的工具吗？
4. 哪个更可能是瓶颈，显示器还是解码器？
谢谢！