Lambda渲染现在更快了

通过Remotion v4.0.130，Remotion Lambda渲染现在完成得更快！
视频越长，加速效果越明显。

使用<OffthreadVideo>标签渲染1920x1080px视频， 加载一个15MB的全高清视频并循环播放。Lambda函数已分配3000MB内存。

感谢我们与Wistia的Max Schnur合作实施的创新音频串联策略，我们可以跳过最后的音频重新编码步骤。

音频是慢的部分

Remotion Lambda并行渲染视频的部分，并在最后将它们连接起来。
慢的部分实际上不是视频，而是音频渲染！

虽然其他编解码器也是可能的，但.mp4文件通常包含AAC音频。

通常在不创建任何伪影的情况下无法串联AAC块。

AAC的工作原理

AAC音频流包含许多数据包。每个数据包包含确切的1024个样本。

音频的持续时间必须是1024个样本的整数倍。如果您的音频不符合，您必须用静音填充最后一个数据包！

在串联AAC音频时，这种填充的静音是明显的，并且可以听到爆裂声：

为了避免这种问题，整个音频需要在最后重新编码。音频越长，问题就越严重！

一个包有依赖关系

让问题更加棘手的是，AAC 包并不是自包含的。波形还取决于前一个和后一个包！

这意味着我们不能创建大小为包的音频片段并将它们连接起来，因为我们还需要包括它们的填充。

谁能解决这个问题？

在线资源如 Stack Overflow 很快就被耗尽了。

我参加了 RTC.on 多媒体会议，并在我的演讲中谈到了这个问题。

几位听众在演讲结束后走到我面前，给了我一些想法。我和 Software Mansion 的 Michał Śledź 进行了一次会话，所有这些都帮助我更好地理解我们面临的问题。

虽然没有找到立即的解决方案，但当我们意识到 libfdk-aac 编码器比 FFmpeg 的原生编码器快两倍时，问题暂时得到缓解。

连接 AAC 的创新方法

突然间，Wistia 的 Max Schnur 提出了一个解决方案，并在 Remotion Discord 上发布了！

为了无缝连接 AAC：

• 每个音频片段的样本数必须是 1024 的倍数
• 每个片段的开头和结尾都应该有额外的包，以避免丢失关键帧。
• 在连接它们时将删除额外的填充。

要正确实现这一点有许多棘手的方面：

• 每个音频片段需要比以前长一点，它们需要稍微重叠。需要评估额外的帧，但不需要截图。
• 视频块不应包含填充，因此音频和视频需要分开。
• 根据四舍五入和音频中的位置，需要 1 到 3 个额外的包。
• inpoint 和 outpoint FFmpeg 滤镜需要纳秒精确以进行正确的修剪。
• 所有音频层应重新采样为相同的采样率（我们决定使用 48000 Hz）
• 我们的时间轴定位、音量曲线、音高校正、播放速率功能需要继续工作。
• 仅渲染时间轴的一部分将会改变起始时间戳，这会改变每个块的数学计算。
• 视频帧率（通常为 30fps）和音频采样率（通常为 48000Hz）很少对齐。通过捕获额外的帧，我们会得到太多的填充，需要再次修剪掉每个块。
• FFmpeg 的 atempo 滤镜不精确：例如，将 80,000 个音频样本加速 2 倍将导致 40,014 个音频样本。微小的不完美会导致无法无缝连接。为了解决这个问题，我们不得不颠倒修剪和加速音频的顺序。
• 上面没有显示，每个 AAC 文件在文件开头有 512 个样本的静音。这会稍微延迟所有音频，但通过向 MP4 容器添加负偏移，通常可以平衡这一点。

如果考虑了所有这些因素，连接AAC块将会完全无缝！

升级到 Remotion 4.0.130 或更高版本，以从 Lambda 上更快的渲染中受益。
我们期待未来为降低成本和提升用户体验而进一步改进性能！