对比 libswscale 和 libyuv
内容提要
本文对比了FFmpeg libswscale和libyuv两个开源库在图像缩放和格式转换方面的性能，发现libyuv在某些场景下比libswscale快几倍，但在RGB下采样方面稍慢。同时，libswscale经过优化后的速度也有所提升。文章还提到了多线程加速和libswscale的汇编优化等方法。最后，作者总结了libyuv在缩放算法和计算精度上的劣势，并给出了选择libswscale和libyuv的建议。
延伸解读
测试环境与适用场景
本文测试基于 MacBook Pro M1（ARM 架构），作者指出 ARM 平台存在 libyuv 与 libswscale 的选型问题，而 x86 服务端通常沿用 FFmpeg 全家桶。因此，文中数据更适用于移动端或 ARM 服务器场景，x86 平台结果可能不同。读者在参考性能对比时，需注意硬件架构差异。
性能差异的关键原因
libyuv 在 ARM 上拥有全面的汇编优化，而 libswscale 长期缺少 ARM 汇编优化，导致简单操作（如 RGB 转 YUV）性能差距巨大。此外，libswscale 设计复杂，在简单场景中引入额外开销，例如无下采样时仍执行滤波计算。作者为 libswscale 补充 aarch64 优化后，速度提升一倍以上，但仍远落后于 libyuv。
多线程与架构优化的权衡
libswscale 支持多线程加速，在 4 线程时耗时 14ms，8 线程可达 9ms，能接近甚至超过 libyuv 单线程性能。但线程过多收益递减。libyuv 不支持多线程，依赖单线程优化。因此，在算力充足且 libswscale 单线程成为瓶颈时，多线程是有效的提速手段，但需考虑线程开销与收益平衡。
libyuv 的局限与选型建议
libyuv 支持的缩放模式较少，计算精度较差，例如 8bit 格式中间结果仅用 15bit 保存，而 libswscale 精度更高。PSNR 对比显示两者差距不大，但 libswscale 略优。作者建议：算力充足且重视图像质量时选择 libswscale；算力敏感时选择 libyuv。复杂操作两者性能差异较小，越简单的操作差异越大。
Q&A
libyuv和libswscale在图像缩放性能上有什么区别？
libyuv在某些场景下比libswscale快几倍，但在RGB下采样方面稍慢。
在什么情况下选择libswscale而不是libyuv？
在算力充足且重视图像质量时，选择libswscale。
libswscale的速度如何提升？
libswscale经过优化后速度有所提升，支持多线程加速，4线程和8线程的耗时分别为14ms和9ms。
libyuv在使用时有哪些劣势？
libyuv支持的缩放模式较少，计算精度差。
在RGB转YUV的性能测试中，libyuv和libswscale的耗时分别是多少？
libyuv耗时5ms，libswscale耗时65ms，libyuv速度是libswscale的11倍。
libswscale在ARM架构上的表现如何？
libswscale缺少ARM架构的汇编优化，导致在简单场景性能不如libyuv。
