用 FFmpeg 解码的原始 PCM 音频文件或 mp3 文件哪个更快？

Question

我非常深入地开发我的 Android 应用程序，当我第二次处理我的音频文件以尝试更长的音频剪辑（1000 毫秒长）时，我现在又遇到了音频故障。在我没有遇到 160 毫秒长的文件出现任何故障之前。

• 背景：我正在制作一个节拍器，所以想象一下回调中大约有 100 行代码来不断确定要播放的音频文件以及播放时长。

没有进入我的代码，我只是想知道文件大小或文件类型是否对性能有任何影响？我相信我正在使用示例Player 渲染类(source)（用于原始文件输入），它似乎在每次回调时加载文件的音频数据。这可能会从更大的数组中加载数据会减慢速度？虽然，它也可能是我添加到回调中的新功能/逻辑。

我知道人们经常谈论使用 mp3 和使用 FFmpeg 解码。有没有人在 mp3 和 raw 之间进行过任何基准测试，使用 mp3 是否有任何性能优势，或者主要是为了减少您的 APK 大小？

很抱歉，如果在某处讨论过这个问题，但是，我找不到任何文章提到这两种文件类型之间的这一方面。更仔细地观察渲染类，我的直觉告诉我文件大小“不应该”是一个因素......否则我会继续调试，如果可以的话，可能会得到一些系统跟踪。

Answer 1

要使用@llogan 的建议来回答，这里有一些使用 ffmpeg 命令行实用程序的基准：

mp3：

ffmpeg -benchmark -i sound.mp3  -f null -
ffmpeg version 3.4.6-0ubuntu0.18.04.1 Copyright (c) 2000-2019 the FFmpeg developers
  built with gcc 7 (Ubuntu 7.3.0-16ubuntu3)
  configuration: --prefix=/usr --extra-version=0ubuntu0.18.04.1 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --enable-gpl --disable-stripping --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librubberband --enable-librsvg --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-omx --enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libopencv --enable-libx264 --enable-shared
  libavutil      55. 78.100 / 55. 78.100
  libavcodec     57.107.100 / 57.107.100
  libavformat    57. 83.100 / 57. 83.100
  libavdevice    57. 10.100 / 57. 10.100
  libavfilter     6.107.100 /  6.107.100
  libavresample   3.  7.  0 /  3.  7.  0
  libswscale      4.  8.100 /  4.  8.100
  libswresample   2.  9.100 /  2.  9.100
  libpostproc    54.  7.100 / 54.  7.100
Input #0, mp3, from 'sound.mp3':
  Duration: 00:00:01.03, start: 0.023021, bitrate: 121 kb/s
    Stream #0:0: Audio: mp3, 48000 Hz, stereo, s16p, 121 kb/s
    Metadata:
      encoder         : LAME3.100
Stream mapping:
  Stream #0:0 -> #0:0 (mp3 (native) -> pcm_s16le (native))
Press [q] to stop, [?] for help
Output #0, null, to 'pipe:':
  Metadata:
    encoder         : Lavf57.83.100
    Stream #0:0: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
    Metadata:
      encoder         : Lavc57.107.100 pcm_s16le
size=N/A time=00:00:01.00 bitrate=N/A speed=83.6x    
video:0kB audio:188kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
bench: utime=0.008s
bench: maxrss=37292kB

原始：

ffmpeg -benchmark -f s16le -channels 2 -sample_rate 44100 -i sound.raw -f null -
ffmpeg version 3.4.6-0ubuntu0.18.04.1 Copyright (c) 2000-2019 the FFmpeg developers
  built with gcc 7 (Ubuntu 7.3.0-16ubuntu3)
  configuration: --prefix=/usr --extra-version=0ubuntu0.18.04.1 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --enable-gpl --disable-stripping --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librubberband --enable-librsvg --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-omx --enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libopencv --enable-libx264 --enable-shared
  libavutil      55. 78.100 / 55. 78.100
  libavcodec     57.107.100 / 57.107.100
  libavformat    57. 83.100 / 57. 83.100
  libavdevice    57. 10.100 / 57. 10.100
  libavfilter     6.107.100 /  6.107.100
  libavresample   3.  7.  0 /  3.  7.  0
  libswscale      4.  8.100 /  4.  8.100
  libswresample   2.  9.100 /  2.  9.100
  libpostproc    54.  7.100 / 54.  7.100
[s16le @ 0x56493de82c00] Estimating duration from bitrate, this may be inaccurate
Guessed Channel Layout for Input Stream #0.0 : stereo
Input #0, s16le, from 'sound.raw':
  Duration: 00:00:01.09, bitrate: 1411 kb/s
    Stream #0:0: Audio: pcm_s16le, 44100 Hz, stereo, s16, 1411 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (pcm_s16le (native) -> pcm_s16le (native))
Press [q] to stop, [?] for help
Output #0, null, to 'pipe:':
  Metadata:
    encoder         : Lavf57.83.100
    Stream #0:0: Audio: pcm_s16le, 44100 Hz, stereo, s16, 1411 kb/s
    Metadata:
      encoder         : Lavc57.107.100 pcm_s16le
size=N/A time=00:00:01.08 bitrate=N/A speed= 819x    
video:0kB audio:188kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
bench: utime=0.001s
bench: maxrss=36752kB

通过这些结果，（如果我没看错的话）似乎 .raw 比 .mp3 快​​了大约 7 毫秒。在内存消耗方面，.raw 比 .mp3 高 1 MB。如果使用 48000 码流速率解码，.raw 在内存消耗上比 .mp3 高 2 MB。

使用这些数据，看起来使用 Raw 在技术上可能会更快，尽管 mp3 的优势在于文件大小非常紧凑。所以对我来说，我的文件大小相对较小（190kB x 9 个文件），这不是一个很大的因素。话虽如此，加载声音文件的时间不到 10 毫秒并不可怕，我认为这不会影响您的应用程序的性能。

Answer 2

如果您正在制作节拍器应用程序，大概您只是在播放与用户选择的节奏同步的“咔哒”声。

如果是这样，我的建议是将您的“点击”声音存储在 MP3 中，在应用启动时将其解码到内存中，然后通过监控音频中已请求的帧数在正确的时间播放它流回调。

MP3 的解码时间就变得无关紧要了，因为您不是实时进行的。

Answer 3

与任何压缩 mp3 文件相比，RAW PCM 始终播放得更快。

Mp3 文件包含 - mp3 编码数据 - 需要解码为 Raw PCM，然后由任何播放器播放。

与 mp3 文件（压缩）相比，RAW PCM 文件（未压缩）的尺寸更大。

如果您将此文件与 APK 捆绑在一起，则 APK 的大小会发生变化。