是否可以通过标准的GET请求将广告或消息动态地拼接到MP3文件中? [英] Is it possible to splice advertisements or messages dynamically into an MP3 file via a standard GET request?

问题描述

假设您有一个MP3文件，该文件为60,000,000字节，并且您还具有一个500,000字节的MP3广告，两者均以相同的比特率进行编码.

Say you have an MP3 file and it's 60,000,000 bytes, and you also have an MP3 advertisement that's 500,000 bytes, both encoded at the same bit rate.

是否可以使用nginx或apache模块将MP3"Content-Length"标头值更改为60,500,000，然后控制传入的"Content-Range"请求，以便前500,000字节返回广告音频，以及任何范围大于500,000的请求开始返回偏移量为500,000字节的常规音频文件?

Would it be possible using an nginx or apache module to change the MP3 "Content-Length" header value to 60,500,000 and then control the incoming "Content-Range" requests so the first 500,000 bytes return the advertisement audio, and any range request greater than 500,000 begins returning the regular audio file with a 500,000 byte offset?

还是只能使用FFmpeg之类的应用程序将广告(或消息)拼接到MP3文件中以重新呈现整个文件?

Or is it only possible to splice advertisements (or messages) into an MP3 file using an application such as FFmpeg to re-render the entire file?

很抱歉，如果这是一个愚蠢的问题，我只是想跳出框框.

Apologies if this is a stupid question, I'm just trying to think outside of the box.

推荐答案

您不能在没有伪影和解码器错误的情况下随意拼接MP3.

You cannot arbitrarily splice MP3 without artifacts and decoder errors.

由于位库.基本上，特定的MP3帧可以包含来自另一帧的数据，以便在需要时更有效地使用可用带宽.忽略位存储库还会导致伪像和/或解码器错误.

You also generally cannot cut/splice MP3 on frame boundaries due to the Bit Reservoir. Basically, a particular MP3 frame may contain data from another frame to more efficiently use the available bandwidth when its needed. Ignoring the bit reservoir can also cause artifacts and/or decoder errors.

您可以 做的是对广告进行重新编码，并最终重新加入视频流.也就是说，在广告插入时，将流解码为PCM，为您的广告混合(或替换为音频)，然后将此并行流重新编码为PCM.如果编码参数相同，则最终(在几个额外的MP3帧之后)，您将拥有相同的比特流，然后可以返回从同一缓冲区读取流.

What you can do is re-encode your advertisement and eventually re-join the stream. That is, at the point of ad insertion, decode the stream to PCM, mix (or replace in the audio) for your ad, and have this parallel stream re-encoded to PCM. If the encoding parameters are the same, eventually (after a couple of extra MP3 frames), you'll have identical bitstreams, and you can go back to reading the stream from the same buffer.

如果您要在互联网广播(实时)流上插入广告，请记住，您必须在服务器上为每个客户端(或至少每个广告变体和计时变体)进行插入).如果这是用于播客或其他预先录制的内容，则建议使用FFmpeg路由.您无需构建任何内容，就可以对输出进行编码，然后进行流传输和缓存，并且可以与其他编解码器兼容，而无需为每个编解码器/容器构建一次性代码.

If you're doing this for ad-insertion on internet radio (live) streams, keep in mind that you'll have to do this on the server for every client (or at least, for each ad variant and timing variant). If this is for podcasts or other pre-recorded content, I'd recommend the FFmpeg route. You won't have to build anything, you can stream and cache the output as its being encoded, and you'll have compatibility with other codecs without building one-off code for each codec/container.

这篇关于是否可以通过标准的GET请求将广告或消息动态地拼接到MP3文件中?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！