gpt4 book ai didi

javascript - HTML 音频对象报告错误的文件持续时间

转载 作者:行者123 更新时间:2023-11-28 12:16:42 25 4
gpt4 key购买 nike

我开始使用 AAC 音频文件而不是 MP3 来避免时间漂移,但现在我发现自己在 Chrome 中遇到了一个问题,报告音频持续时间不正确。

我有一个示例音频可以帮助说明问题。音频的实际持续时间是 22:01,但 Chrome 显示的持续时间是 20:13,但如果您实际播放音频的结尾,则持续时间会开始变化,直到它会是正确的。

Sample AAC audio here!

问题的根源是什么?我读到也许可以通过输入正确的元数据来解决,但它似乎是正确的......

一些有趣的数据:

Chrome 中的 MP3 显示21:58

Safari 中的 AAC 显示22:10

Safari 中的 MP3 显示准确的持续时间22:01

有没有机会让它在任何地方都一样工作?

我保留 MP3 文件以防万一 here

最佳答案

原因

问题是 AAC 是一种格式。这意味着没有像容器格式(例如“mp4”)一样提供全局文件头,因此浏览器必须根据最初加载的比特率来猜测时间数据包 header ( ADTS ) 和服务器提供的文件长度。

由于浏览器在整个流被消耗之前不知道实际的样本长度,因此结果将根据浏览器(或底层系统)尝试预测持续时间的方式而变化。

AAC 还可以使用可变比特率 (VBR) 进行编码,这使得正确预测持续时间变得非常困难,因为开始时找到的比特率可能不是用于的比特率稍后会提供其他示例数据包。

当然也有可能文件/编码已损坏或有错误。

顺便说一句,这些同样的挑战也适用于 MP3 文件。这就是为什么它们有时也会显示不正确的持续时间。

解决方法

第一个是使用恒定比特率 (CBR) 对 AAC 进行编码。这将使浏览器能够更可靠地预测时间,因为如果变化明显,VBR 可以随时放弃计算。这很可能会影响文件大小。

如果 CBR 不是一个选项,一种解决方法是为 AAC 流提供容器格式,例如 MP4,它可以将持续时间存储在开始时加载的全局 header 中 - MP4 可以由 Audio 元素作为缓冲音频使用。执行此操作时,您将获得正确的时间(小数位可能存在一些舍入误差):

AAC 在 Firefox 中加载到 MP4 容器中:
snapshot using mp4 container in firefox

Chrome 中的 MP4 容器中加载了 AAC
snapshot using mp4 container in chrome

要为 AAC 生成 MP4 容器,您可以使用免费的 ffmpeg 等。使用这些参数将按原样复制 AAC(不会进行重新编码,因此结果将具有与以前相同的质量和比特率):

ffmpeg.exe -i "Lesson+53-A.aac" -c:a copy "Lesson+53-A.mp4"

您还会看到 ffmpeg 指出这个问题:

[aac @ 0000000001c624a0] Estimating duration from bitrate, this may be inaccurate [...]

另一个可能不太方便的解决方法是提供持续时间作为元数据,例如文件名本身(类似于“myfile_MMSS.aac”)或作为 URL 中的哈希标签/参数,或者单独旁加载元数据。

后者将产生一定的影响,因为我们无法覆盖 native 播放器的持续时间字段(以跨浏览器友好的方式),这可能需要您构建自定义播放器界面,以便您可以将元数据显示为持续时间而不是浏览器预测为一个。

关于javascript - HTML 音频对象报告错误的文件持续时间,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/47960743/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com