音频媒体来源扩展

Dale Curtis
Dale Curtis

简介

媒体源扩展 (MSE) 为 HTML5 <audio><video> 元素提供扩展缓冲和播放控制。虽然最初开发这些播放器是为了支持基于 HTTP 动态自适应流式传输 (DASH) 的视频播放器,但下文将介绍此类播放器可如何用于音频,特别是无间断播放

您可能听过一张音乐专辑,里面的歌曲在曲目间无缝切换,甚至现在甚至可能正在听一首。音乐人打造的这种无间断播放体验既是一种艺术选择,也是黑胶唱片CD 的工件,其中的音频以连续的串流形式写入。遗憾的是,由于 MP3AAC 等现代音频编解码器的工作方式,这种流畅的听觉体验如今往往无法获得。

我们将在下面详细说明原因,但现在先从演示开始。以下为优秀的 Sintel 的前三十秒视频,将其分成五个独立的 MP3 文件,并使用 MSE 进行重新组合。红线表示在各 MP3 创建(编码)期间引入的缺口;您会在这些点听到干扰声。

演示

糟糕!这样的体验会很糟糕,但是我们可以做得更好。只需再多做一点工作,我们就可以使用上述演示中完全相同的 MP3 文件,通过 MSE 来消除这些令人厌烦的间隙。下一个演示中的绿线表示文件已联接的位置以及消除间隙的位置。在 Chrome 38+ 上,可以流畅播放!

演示

创作无间断内容的方法多种多样。在本演示中,我们将重点关注普通用户存放在哪些类型的文件。其中每个文件都是单独编码的,而不考虑其前后的音频片段。

基本设置

首先,让我们回溯并介绍 MediaSource 实例的基本设置。顾名思义,Media Source Extensions 只是对现有媒体元素的扩展。下面,我们为音频元素的来源属性分配了一个表示 MediaSource 实例的 Object URL;就像设置标准网址一样。

var audio = document.createElement('audio');
var mediaSource = new MediaSource();
var SEGMENTS = 5;

mediaSource.addEventListener('sourceopen', function() {
    var sourceBuffer = mediaSource.addSourceBuffer('audio/mpeg');

    function onAudioLoaded(data, index) {
    // Append the ArrayBuffer data into our new SourceBuffer.
    sourceBuffer.appendBuffer(data);
    }

    // Retrieve an audio segment via XHR.  For simplicity, we're retrieving the
    // entire segment at once, but we could also retrieve it in chunks and append
    // each chunk separately.  MSE will take care of assembling the pieces.
    GET('sintel/sintel_0.mp3', function(data) { onAudioLoaded(data, 0); } );
});

audio.src = URL.createObjectURL(mediaSource);

连接 MediaSource 对象后,它会执行一些初始化并最终触发 sourceopen 事件;此时,我们可以创建一个 SourceBuffer。在上面的示例中,我们创建了一个 audio/mpeg 文件,它能够解析和解码 MP3 片段;还有几种其他类型可供选择。

异常波形

我们稍后会回顾一下代码,但现在让我们更仔细地看一下刚刚附加的文件,特别是文件末尾。下图显示了 sintel_0.mp3 轨道中两个频道的最后 3000 个样本的平均值。红线上的每个像素都是 [-1.0, 1.0] 范围内的一个浮点样本

sintel_0.mp3 的结尾

那么这些零(无声)样本怎么回事?!它们实际上是由编码过程中引入的压缩失真所致。几乎每个编码器都会引入某种类型的填充。在本例中,LAME 在文件末尾正好添加了 576 个填充样本。

除了末尾的内边距之外,每个文件的开头也添加了内边距。如果我们向前看一下 sintel_1.mp3 轨道,会看到前面存在另外 576 个内边距样本。内边距大小因编码器和内容而异,但我们知道每个文件中包含的 metadata 的确切值。

sintel_1.mp3 的开头

sintel_1.mp3 的开头

每个文件开头和结尾的无声部分是导致上一个演示中各片段之间出现故障的原因。为了实现无间断播放,我们需要消除这些无声部分。幸运的是,使用 MediaSource 可以轻松地完成此操作。在下面,我们将修改 onAudioLoaded() 方法,以使用附加窗口时间戳偏移量来移除此无声部分。

示例代码

function onAudioLoaded(data, index) {
    // Parsing gapless metadata is unfortunately non trivial and a bit messy, so
    // we'll glaze over it here; see the appendix for details.
    // ParseGaplessData() will return a dictionary with two elements:
    //
    //    audioDuration: Duration in seconds of all non-padding audio.
    //    frontPaddingDuration: Duration in seconds of the front padding.
    //
    var gaplessMetadata = ParseGaplessData(data);

    // Each appended segment must be appended relative to the next.  To avoid any
    // overlaps, we'll use the end timestamp of the last append as the starting
    // point for our next append or zero if we haven't appended anything yet.
    var appendTime = index > 0 ? sourceBuffer.buffered.end(0) : 0;

    // Simply put, an append window allows you to trim off audio (or video) frames
    // which fall outside of a specified time range.  Here, we'll use the end of
    // our last append as the start of our append window and the end of the real
    // audio data for this segment as the end of our append window.
    sourceBuffer.appendWindowStart = appendTime;
    sourceBuffer.appendWindowEnd = appendTime + gaplessMetadata.audioDuration;

    // The timestampOffset field essentially tells MediaSource where in the media
    // timeline the data given to appendBuffer() should be placed.  I.e., if the
    // timestampOffset is 1 second, the appended data will start 1 second into
    // playback.
    //
    // MediaSource requires that the media timeline starts from time zero, so we
    // need to ensure that the data left after filtering by the append window
    // starts at time zero.  We'll do this by shifting all of the padding we want
    // to discard before our append time (and thus, before our append window).
    sourceBuffer.timestampOffset =
        appendTime - gaplessMetadata.frontPaddingDuration;

    // When appendBuffer() completes, it will fire an updateend event signaling
    // that it's okay to append another segment of media.  Here, we'll chain the
    // append for the next segment to the completion of our current append.
    if (index == 0) {
    sourceBuffer.addEventListener('updateend', function() {
        if (++index < SEGMENTS) {
        GET('sintel/sintel_' + index + '.mp3',
            function(data) { onAudioLoaded(data, index); });
        } else {
        // We've loaded all available segments, so tell MediaSource there are no
        // more buffers which will be appended.
        mediaSource.endOfStream();
        URL.revokeObjectURL(audio.src);
        }
    });
    }

    // appendBuffer() will now use the timestamp offset and append window settings
    // to filter and timestamp the data we're appending.
    //
    // Note: While this demo uses very little memory, more complex use cases need
    // to be careful about memory usage or garbage collection may remove ranges of
    // media in unexpected places.
    sourceBuffer.appendBuffer(data);
}

无缝波形

应用附加窗口后,再来看一下波形,看看这个闪亮的新代码有什么成就。从下方您可以看到,sintel_0.mp3 末尾的静音部分(红色)和 sintel_1.mp3 开头的静音部分(蓝色)均已移除;这使得我们可以在各片段之间实现无缝过渡。

合并 sintel_0.mp3 和 sintel_1.mp3

总结

至此,我们将所有五个片段无缝拼接成了一个片段,演示视频到此结束。在开始之前,您可能已经注意到,onAudioLoaded() 方法没有考虑容器或编解码器。这意味着,无论容器或编解码器类型如何,所有这些技术都可以运行。您可以在下面重放原始演示版支持 DASH 的碎片 MP4,而不是 MP3。

演示

如果您想了解更多信息,请查看以下附录,更深入地了解无间断内容创建和元数据解析。您还可以探索 gapless.js,详细了解支持此演示的代码。

感谢您阅读本邮件!

附录 A:创建无间断内容

创作没有间断的内容并非易事。下面,我们将逐步介绍如何创建本演示中使用的 Sintel 媒体。首先,您需要一份为 Sintel 提供的无损 FLAC 曲目副本;为便于后续使用,下面提供了 SHA1。要使用工具,您需要安装 FFmpegMP4BoxLAME,并使用 afconvert 安装 OSX。

unzip Jan_Morgenstern-Sintel-FLAC.zip
sha1sum 1-Snow_Fight.flac
# 0535ca207ccba70d538f7324916a3f1a3d550194  1-Snow_Fight.flac

首先,我们会拆分 1-Snow_Fight.flac 曲目的前 31.5 秒。我们还想添加从 28 秒开始的 2.5 秒淡出,以避免播放结束后有任何点击。通过使用以下 FFmpeg 命令行,我们可以完成所有这些操作,并将结果放入 sintel.flac

ffmpeg -i 1-Snow_Fight.flac -t 31.5 -af "afade=t=out:st=28:d=2.5" sintel.flac

接下来,我们将该文件拆分为 5 个 wave 文件,每个文件 6.5 秒;这是最简单的方法,因为几乎所有编码器都支持提取该文件。同样,我们可以精确地使用 FFmpeg 执行此操作,其后将有以下元素:sintel_0.wavsintel_1.wavsintel_2.wavsintel_3.wavsintel_4.wav

ffmpeg -i sintel.flac -acodec pcm_f32le -map 0 -f segment \
        -segment_list out.list -segment_time 6.5 sintel_%d.wav

接下来,我们来创建 MP3 文件。LAME 有多种用于创建无间断内容的选项。如果您可以控制内容,可以考虑使用 --nogap,对所有文件进行批量编码,以避免在片段之间出现内边距。不过,出于本演示的目的,我们需要填充,因此,我们将使用 wave 文件的标准优质 VBR 编码。

lame -V=2 sintel_0.wav sintel_0.mp3
lame -V=2 sintel_1.wav sintel_1.mp3
lame -V=2 sintel_2.wav sintel_2.mp3
lame -V=2 sintel_3.wav sintel_3.mp3
lame -V=2 sintel_4.wav sintel_4.mp3

以上就是创建 MP3 文件所需的全部操作。现在,我们来介绍如何创建碎片化 MP4 文件。我们将按照 Apple 的说明创建可在 iTunes 上掌控的媒体内容。下面,我们会按照说明将 wave 文件转换为中间 CAF 文件,然后再使用推荐的参数在 MP4 容器中将其编码为 AAC

afconvert sintel_0.wav sintel_0_intermediate.caf -d 0 -f caff \
            --soundcheck-generate
afconvert sintel_1.wav sintel_1_intermediate.caf -d 0 -f caff \
            --soundcheck-generate
afconvert sintel_2.wav sintel_2_intermediate.caf -d 0 -f caff \
            --soundcheck-generate
afconvert sintel_3.wav sintel_3_intermediate.caf -d 0 -f caff \
            --soundcheck-generate
afconvert sintel_4.wav sintel_4_intermediate.caf -d 0 -f caff \
            --soundcheck-generate
afconvert sintel_0_intermediate.caf -d aac -f m4af -u pgcm 2 --soundcheck-read \
            -b 256000 -q 127 -s 2 sintel_0.m4a
afconvert sintel_1_intermediate.caf -d aac -f m4af -u pgcm 2 --soundcheck-read \
            -b 256000 -q 127 -s 2 sintel_1.m4a
afconvert sintel_2_intermediate.caf -d aac -f m4af -u pgcm 2 --soundcheck-read \
            -b 256000 -q 127 -s 2 sintel_2.m4a
afconvert sintel_3_intermediate.caf -d aac -f m4af -u pgcm 2 --soundcheck-read \
            -b 256000 -q 127 -s 2 sintel_3.m4a
afconvert sintel_4_intermediate.caf -d aac -f m4af -u pgcm 2 --soundcheck-read \
            -b 256000 -q 127 -s 2 sintel_4.m4a

现在,我们有多个 M4A 文件,需要先对这些文件进行适当分片,然后才能将其与 MediaSource 一起使用。出于我们的目的,我们将使用 1 秒的 fragment 大小。MP4Box 会将每个碎片化的 MP4 写为 sintel_#_dashinit.mp4 以及一个可以舍弃的 MPEG-DASH 清单 (sintel_#_dash.mpd)。

MP4Box -dash 1000 sintel_0.m4a && mv sintel_0_dashinit.mp4 sintel_0.mp4
MP4Box -dash 1000 sintel_1.m4a && mv sintel_1_dashinit.mp4 sintel_1.mp4
MP4Box -dash 1000 sintel_2.m4a && mv sintel_2_dashinit.mp4 sintel_2.mp4
MP4Box -dash 1000 sintel_3.m4a && mv sintel_3_dashinit.mp4 sintel_3.mp4
MP4Box -dash 1000 sintel_4.m4a && mv sintel_4_dashinit.mp4 sintel_4.mp4
rm sintel_{0,1,2,3,4}_dash.mpd

大功告成!现在,我们已为 MP4 和 MP3 文件提供无间断播放所需的正确元数据。请参阅附录 B,详细了解这些元数据是什么样的。

附录 B:解析无间断元数据

就像创建无间断内容一样,解析无间断元数据可能会很棘手,因为没有标准的存储方法。下面,我们将介绍两种最常见的编码器(LAME 和 iTunes)如何存储其无间断元数据。首先,我们来为上面使用的 ParseGaplessData() 设置一些辅助方法和大纲。

// Since most MP3 encoders store the gapless metadata in binary, we'll need a
// method for turning bytes into integers.  Note: This doesn't work for values
// larger than 2^30 since we'll overflow the signed integer type when shifting.
function ReadInt(buffer) {
    var result = buffer.charCodeAt(0);
    for (var i = 1; i < buffer.length; ++i) {
    result <<../= 8;
    result += buffer.charCodeAt(i);
    }
    return result;
}

function ParseGaplessData(arrayBuffer) {
    // Gapless data is generally within the first 512 bytes, so limit parsing.
    var byteStr = new TextDecoder().decode(arrayBuffer.slice(0, 512));

    var frontPadding = 0, endPadding = 0, realSamples = 0;

    // ... we'll fill this in as we go below.

我们先介绍 Apple 的 iTunes 元数据格式,因为这种格式最容易解析和解释。在 MP3 和 M4A 文件中,iTunes(和 afconvert)以 ASCII 格式写入一小段,如下所示:

iTunSMPB[ 26 bytes ]0000000 00000840 000001C0 0000000000046E00

这是在 MP3 容器内的 ID3 标记内和 MP4 容器内的元数据 Atom 内编写的。为此,我们可以忽略第一个 0000000 标记。接下来的三个词元是前填充、结束填充和非填充样本总数。用每一个元素除以音频的采样率,就可得出每个音频的时长。

// iTunes encodes the gapless data as hex strings like so:
//
//    'iTunSMPB[ 26 bytes ]0000000 00000840 000001C0 0000000000046E00'
//    'iTunSMPB[ 26 bytes ]####### frontpad  endpad    real samples'
//
// The approach here elides the complexity of actually parsing MP4 atoms. It
// may not work for all files without some tweaks.
var iTunesDataIndex = byteStr.indexOf('iTunSMPB');
if (iTunesDataIndex != -1) {
    var frontPaddingIndex = iTunesDataIndex + 34;
    frontPadding = parseInt(byteStr.substr(frontPaddingIndex, 8), 16);

    var endPaddingIndex = frontPaddingIndex + 9;
    endPadding = parseInt(byteStr.substr(endPaddingIndex, 8), 16);

    var sampleCountIndex = endPaddingIndex + 9;
    realSamples = parseInt(byteStr.substr(sampleCountIndex, 16), 16);
}

另一方面,大多数开源 MP3 编码器会将无间断元数据存储在静默 MPEG 帧内部的特殊 Xing 标头中(它处于静默状态,因此不理解 Xing 标头的解码器只会播放静音)。遗憾的是,此代码并非始终存在,并且包含一些可选字段。在本演示中,我们可以控制媒体,但在实践中,还需要进行一些额外的检查,才能知道无间断元数据何时实际可用。

首先,我们将解析总样本数。为简单起见,我们将从 Xing 标头读取该标头,但也可以通过常规的 MPEG 音频标头构造该标头。Xing 标头可以使用 XingInfo 标记进行标记。这个标记后面恰好是 4 个字节,其中有 32 位表示文件中的帧总数;将该值乘以每帧的样本数,即可得出文件中的样本总数。

// Xing padding is encoded as 24bits within the header.  Note: This code will
// only work for Layer3 Version 1 and Layer2 MP3 files with XING frame counts
// and gapless information.  See the following document for more details:
// http://www.codeproject.com/Articles/8295/MPEG-Audio-Frame-Header
var xingDataIndex = byteStr.indexOf('Xing');
if (xingDataIndex == -1) xingDataIndex = byteStr.indexOf('Info');
if (xingDataIndex != -1) {
    // See section 2.3.1 in the link above for the specifics on parsing the Xing
    // frame count.
    var frameCountIndex = xingDataIndex + 8;
    var frameCount = ReadInt(byteStr.substr(frameCountIndex, 4));

    // For Layer3 Version 1 and Layer2 there are 1152 samples per frame.  See
    // section 2.1.5 in the link above for more details.
    var paddedSamples = frameCount * 1152;

    // ... we'll cover this below.

现在,我们已经有了样本总数,接下来可以读取填充样本的数量。这可能写在嵌套在 Xing 标头中的 LAME 或 Lavf 标记下,具体取决于您的编码器。此标头后面恰好 17 个字节,有 3 个字节分别表示前端和结束填充(每个均为 12 位)。

xingDataIndex = byteStr.indexOf('LAME');
if (xingDataIndex == -1) xingDataIndex = byteStr.indexOf('Lavf');
if (xingDataIndex != -1) {
    // See http://gabriel.mp3-tech.org/mp3infotag.html#delays for details of
    // how this information is encoded and parsed.
    var gaplessDataIndex = xingDataIndex + 21;
    var gaplessBits = ReadInt(byteStr.substr(gaplessDataIndex, 3));

    // Upper 12 bits are the front padding, lower are the end padding.
    frontPadding = gaplessBits >> 12;
    endPadding = gaplessBits & 0xFFF;
}

realSamples = paddedSamples - (frontPadding + endPadding);
}

return {
audioDuration: realSamples * SECONDS_PER_SAMPLE,
frontPaddingDuration: frontPadding * SECONDS_PER_SAMPLE
};
}

由此,我们便拥有了一个完整的函数来解析绝大多数无间断的内容。不过,极端情况层出不穷,因此在生产环境中使用类似代码之前应格外小心。

附录 C:垃圾回收

系统正在根据内容类型、平台专用限制和当前播放位置,主动回收属于 SourceBuffer 实例的内存。在 Chrome 中,系统首先会从已播放的缓冲区中回收内存。不过,如果内存用量超过平台专用限制,则会从未播放的缓冲区中移除内存。

如果因回收内存而导致播放在时间轴上出现间隙,如果间隙足够小,则可能会出现故障;如果间隙过大,则可能会完全停滞。这两者都不是出色的用户体验,因此请务必避免一次性附加过多数据,并从媒体时间轴中手动移除不再需要的范围。

您可以通过每个 SourceBufferremove() 方法移除范围;该方法接受一个 [start, end] 范围(以秒为单位)。与 appendBuffer() 类似,每个 remove() 会在完成后触发 updateend 事件。在事件触发之前,不应发出其他移除或附加操作。

在桌面版 Chrome 中,您可以同时在内存中保存约 12 MB 的音频内容和 150 MB 的视频内容。您不应跨浏览器或平台依赖这些值;例如,它们肯定无法代表移动设备。

垃圾回收仅影响添加到 SourceBuffers 的数据;在 JavaScript 变量中可以缓冲的数据量不受限制。如有必要,您还可以在同一位置重新附加相同的数据。