使用FFMPEG单独转码HLS分段

9
我正在记录一个高比特率的HLS流,以连续的方式进行直播。然后我想异步转码成不同格式/比特率。我已经基本实现了这个功能,但是在每个片段之间出现了音频伪像(间隙和爆破声)。
以下是一个ffmpeg命令行的示例:
ffmpeg -threads 1 -nostdin -loglevel verbose \
   -nostdin -y -i input.ts -c:a libfdk_aac \
   -ac 2 -b:a 64k -y -metadata -vn output.ts

检查示例音频文件后发现音频末尾存在间隙:

End

文件开头看起来明显被削弱了(虽然这可能不是一个问题)。

Start

我的怀疑是这些工件的发生是因为转码没有整个流的上下文。
有什么想法可以说服FFMPEG生成适合放回HLS流的音频吗?
**更新1**
这里是原始片段的开头/结尾。 如您所见,开头仍然相同,但结尾在30秒处干净地结束。 我期望有一定程度的填充与有损编码,但我认为HLS有一种无缝播放的方法(这是否与iTunes方法和自定义元数据有关?)

Original Start Original End

**更新2**

因此,我将原始文件(128k AAC in MPEG2 TS)和转码文件(64k AAC in AAC/ADTS 容器)都转换为 WAV 格式并进行了对比。以下是结果:

Side-by-side start Side-by-side end

我不确定这是否代表客户将如何播放它,但是在解码转换后的文件时,在开头引入了一个间隙,并使片段变得更长,这似乎有点奇怪。鉴于它们都是有损编码,如果存在填充,我希望两者都能同样存在。根据http://en.wikipedia.org/wiki/Gapless_playback的说法 - 只有少数编码器支持无缝播放 - 对于MP3,我已经切换到ffmpeg中的lame,目前问题似乎已经解决。对于AAC(请参见http://en.wikipedia.org/wiki/FAAC),我尝试过libfaac(而不是libfdk_aac),它似乎也可以产生无缝音频。然而,后者的质量并不是很好,如果可能的话,我宁愿使用libfdk_aac。

波形与输入文件相比如何? - vipw
已更新原始波形并进行比较。 - rayh
1个回答

0
这更多是一个概念性的答案,而不是包含明确工具使用的答案,抱歉,但它可能在任何情况下都有一些用处——它通过引入处理层中的更多复杂性来消除引入音频伪影的问题。
我的建议是根本不要拆分未压缩的输入音频,而只生成一个连续的压缩流,将其传输到音频代理(例如icecast2服务器或类似产品,如果icecast不支持AAC,则使用其他产品),然后在代理的客户端上使用压缩音频块进行拆分/重组。
因此,这里的方法是定期(比如每60秒)连接到代理并收集一个略大于您轮询周期的音频块(比如75秒?)-这需要设置为并行运行,因为有时会有两个客户端运行-甚至可以从cron运行,或者从shell脚本后台运行...
一旦这个工作正常运行,你将拥有一系列重叠一点的音频块-然后你需要做一些处理工作来比较这些块,并隔离每个块中唯一的音频部分...

显然这只是一个简化,但假设代理不添加任何元数据信息(即ICY数据或提示),那么以这种方式拆分音频应该允许连接处理的块而没有任何音频伪影,因为原始音频输入只有一个输出集,并且比较它们将非常容易,因为您实际上不关心格式,此时只是字节。

这里的好处是您已将音频编码器与客户端断开连接,因此,如果您想并行运行其他进程以转换为不同的格式或比特率或更积极地分块流以供其他消费者使用,则在代理的编码器侧面不会发生任何变化-您只需使用类似于上述的工具链向代理添加另一个客户端即可。


我喜欢有一个简单的代理的想法,它可以缓冲来自设备的音频数据...这将允许重新启动编码而不会丢失数据...特别是如果它了解样本并且能够根据样本边界对数据进行分块。 - rayh
然而,如果没有解决原始问题,将音频转码为60秒的块只会在块的边界引入这些问题 - 这些伪影似乎是aac编码的结果,因此它们可能也会影响任何快速合并的音频文件。 - rayh
可能现在已经是古老的历史了,抱歉,但这就是为什么我建议在帧边界处剪切压缩音频(诚然,在您想要的位置可能无法完全被整除,但不会差太远)...现在,如果您将两个不同的压缩音频块并在一起运行,仍然会产生伪影,但如果它们最初是连续的,则不会。 - Malcolm Herbert

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接