当webm提取aac时，持续时间不一致 [英] when webm extracts aac, the duration is inconsistent

问题描述

当我尝试从webm中提取aac时，持续时间会不一致. aac少了十分钟.不同的webm视频，差距不一样.

When I try to extract aac from webm, there will be inconsistencies in duration. aac is ten minutes less. Different webm videos, the gap is not the same.

webm视频是由chrome extension chrome.tabCapture.capture 生成的

webm video is generated by chrome extension chrome.tabCapture.capture

代码:

chrome.tabCapture.capture({
  video: true,
  audio: true,
  videoConstraints: {
    mandatory: {
      minWidth: 1920,
      minHeight: 1080,
      maxWidth: 1920,
      maxHeight: 1080,
      maxFrameRate: 30,
      minFrameRate: 30,
    }
  }
})

上面的代码将返回一个流，我将使用JS的 MediaRecorder 方法来处理此流，最后将其另存为webm文件.

The above code will return a stream, I will use JS's MediaRecorder method to process this stream, and finally save it as a webm file.

代码:

new MediaRecorder(stream, {
  audioBitsPerSecond: 128000,
  videoBitsPerSecond: 2500000,
  mimeType: 'video/webm;codecs=vp9'
})

如果您不知道上面代码的含义，没关系，我将解释主要信息:

If you don't know the meaning of the above code, it doesn't matter, I will explain the main information:

1. 宽度:1920
2. 高度:1080
3. FPS:30
4. audioBits:128000
5. videoBits:2500000
6. mimeType:video/webm;codecs=vp9

1. width: 1920
2. height: 1080
3. FPS: 30
4. audioBits: 128000
5. videoBits: 2500000
6. mimeType: video/webm;codecs=vp9

我尝试了很多方法，如下所示:

I tried a lot of methods, like the following:

# 1
ffmpeg -i ./source.webm -y -fflags +genpts -max_muxing_queue_size 99999 -r 15 -crf 30 -filter:v crop=750:560:0:0 ./x.mp4
ffmpeg -i ./x.mp4 -y -vn -acodec libfdk_aac -b:a 200k ./x.aac

# 2
ffmpeg -i ./source.webm -y -vn -acodec libfdk_aac -b:a 200k ./x.aac

# 3
ffmpeg -i ./source.webm -y -vn -acodec libfdk_aac -b:a 200k -map 0 ./x.aac

# 4
ffmpeg -i ./source.webm -y -max_muxing_queue_size 99999 -r 15 -crf 30 -filter:v crop=750:560:0:0 ./x.mp4
ffmpeg -i ./source.webm -y -vn -acodec aac -b:a 200k ./x.aac

# etc.

但无一例外，一切都失败了.这个问题困扰了我四天.

But without exception, all failed. I have been plagued by this problem for 4 days.

webm文件下载网址: https://drive.google.com/file/d/1m4fC1hU-tXFPOZayrYCs-yteSTxw_TaW/view?usp=sharing

webm file download url: https://drive.google.com/file/d/1m4fC1hU-tXFPOZayrYCs-yteSTxw_TaW/view?usp=sharing

推荐答案

许多会议或网络录制应用程序的作用是，当音频输入丢失或静音(由某个音量阈值定义)时，它们不会存储静音. WebM和MP4是按时间索引的容器，因此媒体数据具有正确的时间戳以用于播放或编辑. .mp3或.aac不会，因此，没有时间戳记的持续时间就是记录和存储的实际音频量.另一个问题是，使用ffmpeg -i in.aac看到的持续时间是基于文件大小和名义比特率的估计值.对于VBR流，此估计可能是错误的.

What many conferencing or web recording apps do, is not store silence when audio input is missing or silent (as defined by some volume threshold). WebM and MP4 are time-indexed containers and so the media data has the correct timestamps for playback or editing purposes. .mp3 or .aac don't, so without timestamps, the duration is that of the actual amount of audio recorded and stored. An additional issue is that the duration you see with ffmpeg -i in.aac is an estimate based on the file size and the notional bitrate. For a VBR stream, this estimate can be wrong.

在带有时间戳的容器(如MP4，MKV等)中存储和使用音频

Either store and work with the audio in a container with timestamps, like MP4, MKV..etc

ffmpeg -i ./x.mp4 -y -vn -acodec libfdk_aac -b:a 200k ./x.mp4

或在音频无声的情况下插入时间戳间隔，

or plug in the timestamp gaps with audio silence,

ffmpeg -i ./x.mp4 -y -vn -af aresample=async=1:first_pts=0:min_hard_comp=0.01 -acodec libfdk_aac -b:a 200k ./x.aac

后一个命令可能仍然显示错误的估计持续时间，但是编辑器在生成峰值后将显示正确的持续时间.

This latter command may still show the wrong estimated duration but an editor, after generating peaks, will show the correct duration.

这篇关于当webm提取aac时，持续时间不一致的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！