html语音对话,HTML5实时语音通话聊天MP3压缩传输3KB每秒

本文介绍了如何利用RecorderH5 GitHub开源库优化实现H5语音通话,通过WebRTC实现P2P连接,支持边录边转码的MP3格式,实现实时3KB每秒传输,适用于局域网对讲和轻量级微信语音通话模拟。文章详细讲解了技术细节和优化策略,包括音频采集、编码、播放以及WebSocket替代方案。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

自从Recorder H5 GitHub开源库优化后,对边录边转码成小语音片段文件实时上传服务器这种操作支持非常良好,因此以前不太好支持的H5语音通话已经有了更好的突破空间。因此花了两晚时间打造了一个H5语音通话聊天的demo。

b8f9bfe4d10b55928ef61e8b7763cc38.png

一、把玩方法

准备局域网内两台设备(Peer A、Peer B)用最新版本浏览器(demo未适配低版本)分别打开demo页面 (也可以是同一浏览器打开两个标签)

勾选页面中的H5版语音通话聊天,在Peer A中点击新建连接

把Peer A的本机信手动复制传输给Peer B,粘贴到远程信息中,并点击确定连接

把Peer B自动生成的本机信息手动复制传输给Peer A,粘贴到远程信息中,并点击确定连接 双方P2P连接已建立,使用页面上方的录音功能,随时开启录音,音频数据会实时发送给对方

局域网H5版对讲机:joy:

二、技术特性

(1)数据传输

github demo中考虑到减少对服务器的依赖,因此采用了WebRTC P2P传输功能,无需任何服务器支持即可实现局域网内的两个设备之间互相连接,连接代码也算简单。有服务器支持可能就要逆天了,不过代码也会更复杂。

如果正式使用,可能不太会考虑使用WebRTC,用WebSocket通过服务器进行转发可能是最佳的选择。

WebRTC局域网P2P连接要点( 实际代码 其实差不多,只不过多做了点兼容):

/******Peer A(本机)******/

var peerA=new RTCPeerConnection(null,null)

//开启会话,等待远程连接

peerA.createOffer().then(function(offer){

peerA.setLocalDescription(offer);

peerAOffer=offer;

});

var peerAICEList=[......] //通过peerA.onicecandidate监听获得所有的ICE连接信息候选项,如果有多个网络适配器,就会有多个候选

//创建连接通道对象,A端通过这个来进行数据发送

var peerAChannel=peerA.createDataChannel("RTC Test");

/******Peer B(远程)******/

var peerB=new RTCPeerConnection(null,null)

//连接到Peer A

peerB.setRemoteDescription(peerAOffer);

//开启应答会话,等待Peer A确认连接

peerB.createAnswer().then(function(answer){

peerB.setLocalDescription(answer);

peerBAnswer=answer;

});

//把Peer A的连接点都添加进去

peerB.addIceCandidate(......peerAICEList)

var peerBICEList=[......] //通过peerB.onicecandidate监听获得所有的ICE连接信息候选项,如果有多个网络适配器,就会有多个候选

var peerBChannel=... //通过peerB.ondatachannel得到连接通道对象,B端通过这个来进行数据发送

/*******最终完成连接********/

//连接到Peer B

peerA.setRemoteDescription(peerBAnswer);

//把Peer B的连接点都添加进去

peerA.addIceCandidate(......peerBICEList)

/*

peerA peerB分别等待peerA/BChannel.onopen回调即完成P2P连接

,然后通过监听peerA/BChannel.onmessage获得对方发送的信息

,通过peerA/BChannel.send(data) 发送数据。

*/

(2)音频采集和编码

由于是在我的 Recorder库 中新加的demo,因此音频采集和编码都是现成的,Recorder库有好的兼容性和稳定性,因此节省了最大头的工作量。

编码最佳使用MP3格式,因为此格式已优化了实时编码性能,可做到边录边转码,16kbps 16khz的情况下可做到2kb每秒的文件大小,音质还可以,实时传输时为3kb每秒,15分钟大概3M的流量。

用wav格式也可以,不过此格式编码出来的数据量太大,16位 16khz接近50kb每秒的实时传输数据,15分钟要37M多流量。其他格式由于暂未对实时编码进行优化,使用中会导致明显卡顿。

降噪、静音检测等高级功能是没有的,毕竟是非专业人员:joy: 要求高点可以,但不要超出范围太多啦。

(3)音频实时接收和播放

接收到一个音频片段后,本应该是立即播放的,但由于编码、网络传输导致的延迟,可能上个片段还未播放完(甚至未开始播放),因此需要缓冲处理。

因为存在缓冲,就需要进行实时同步处理,如果缓冲内积压了过多的音频片段,会导致语音播放滞后太多,因此需要适当进行对数据进行丢弃,实测发现网络正常、设备性能靠谱的情况下基本没有丢弃的数据。

然后就是播放了,本应是播完一个就播下一个,测试发现这是不靠谱的。因为结束一个片段后再开始播放下一个发出声音,这个过程会中断比较长时间,明显感觉得出来中间存在短暂停顿。因此必须在片段未播完时准备好下一个片段的播放,并且提前开始播放,达到抹掉中间的停顿。

我写了两个播放方式:

实时解码播放

双Audio轮换播放

最开始用一个Audio停顿感太明显,因此用两个Audio轮换抹掉中间的停顿,但发现不同格式Auido播放差异巨大,播放wav非常流畅,但播放mp3还是存在停顿(后面用解码的发现是得到的PCM时长变长了,导致事件触发会出现误差,为什么会变长?怪异)。

因此后面写了一个解码然后再播放,mp3这次终于能正常连续播放了,wav格式和双Audio的播放差异不大。实时解码里面也用到了双Audio中的技巧,其实也是用到了两个BufferSource进行类似的轮换操作,以抹掉两个片段间的停顿。

不过最终播放效果还是不够好,音质变差了点,并且多了点噪音。如果有现成的播放代码拿过来用就就好了。

三、应用场景

数据传输改成WebSocket,做个仿微信语音通话H5版还是可以的(受限于Recorder浏览器支持)

局域网H5版对讲机(前端玩具)

......没有想到 完。

总结

以上所述是小编给大家介绍的HTML5实时语音通话聊天MP3压缩传输3KB每秒,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对脚本之家网站的支持!

如果你觉得本文对你有帮助,欢迎转载,烦请注明出处,谢谢!

<think>好的,我现在需要处理用户的新查询:“请使用中文回答我或者给我介绍一下: (要求16k, 16bit,pcm格式”。看起来用户之前已经询问过关于音频采样率和采样点的问题,现在他们可能想深入了解PCM格式的具体参数,特别是16kHz采样率和16位深度的PCM音频。 首先,我需要确认用户的需求。他们可能是在进行音频处理、开发相关应用,或者在处理音频数据时需要符合这些规格。用户可能想了解这些参数的意义、如何计算存储需求、应用场景,以及相关的技术细节。此外,用户可能还希望知道如何生成或处理这种格式的音频文件,或者在不同环境下如何应用这些参数。 接下来,我要回顾之前的对话历史。上一次用户询问的是48kHz下5ms对应的采样点数,我详细解释了采样率、时间与采样点的关系,并扩展到了实际应用和不同采样率的对比。现在用户转向了16kHz、16bit、PCM格式,可能需要类似的结构,但重点放在这三个参数上。 用户可能对以下内容感兴趣: 1. 16kHz采样率的意义和应用场景。 2. 16bit位深度的含义及其对音质的影响。 3. PCM格式的基本概念,与其他音频格式的区别。 4. 存储空间的计算方法,比如每秒所需的存储量。 5. 如何生成或处理16k 16bit PCM格式的音频。 6. 实际应用中的例子,如语音识别、通信系统等。 需要确保回答清晰,结构合理,涵盖定义、计算、应用和注意事项。同时,用户可能希望看到示例或对比,比如不同位深度的区别,或者不同采样率下的音质差异。此外,可能需要解释PCM的无压缩特性,以及为什么在某些场景下选择PCM。 需要注意的是,用户可能没有明确说出他们的深层需求,比如他们可能在开发需要低延迟的语音应用,或者处理音频数据存储问题。因此,在回答时,除了基本参数解释,还应提供实际应用的例子和潜在的问题,如文件大小与质量的权衡。 还要检查是否有技术细节需要深入,比如PCM的字节序(大端或小端),如何读取或写入这种格式的文件,或者常见的工具和库(如FFmpeg)如何处理这些参数。不过,用户可能只需要基础介绍,所以需要平衡深度和广度,避免信息过载。 最后,确保语言简洁,使用中文,避免专业术语过多,必要时进行解释。可能需要用类比或示例帮助理解,比如用电话音质说明16kHz采样率的适用场景,或用动态范围解释16bit的细节表现。</think>以下是关于 **16kHz 采样率、16bit 位深度、PCM 格式** 的详细介绍: --- ### **1. 核心参数定义** - **采样率(16kHz)** 表示每秒采集 **16,000 次** 音频信号。 - **覆盖频率范围**:理论上最高可记录 `16kHz / 2 = 8kHz` 的声音(根据奈奎斯特定理)。 - **适用场景**:适合人声通话(如电话语音频段为 300Hz~4kHz)、语音识别、低带宽传输等对高频细节要求不高的场景。 - **位深度(16bit)** 表示每个采样点用 **16位二进制数(2字节)** 存储声音的振幅大小。 - **动态范围**:约 `20 × log₁₀(2¹⁶) ≈ 96dB`,可区分从极弱到较强的声音层次。 - **量化精度**:振幅被分为 `65,536 (2¹⁶)` 个离散等级,精度足以满足大多数通用音频需求。 - **PCM(脉冲编码调制)** - **原理**:直接存储未经压缩的原始音频采样数据。 - **特点**:无压缩、无损质量、高兼容性,但文件体积较大。 --- ### **2. 存储空间计算** - **单声道每秒数据量**: \[ 16,000 \text{ 采样点/秒} \times 2 \text{ 字节/采样点} = 32,000 \text{ 字节/秒} ≈ 31.25 \text{ KB/秒} \] - **1分钟单声道音频**: \[ 31.25 \text{ KB/秒} \times 60 \text{ 秒} ≈ 1.83 \text{ MB} \] - **立体声(双声道)**:数据量翻倍(约 `62.5 KB/秒`)。 --- ### **3. 文件格式与编码** - **常见容器格式**: - `.wav`:Windows 标准 PCM 容器,包含音频参数头信息。 - `.raw`/`.pcm`:纯裸数据,无头信息,需手动指定参数解析。 - **数据排列方式**: - 采样点按时间顺序排列,单声道直接存储,双声道交替存储(如 `左-右-左-右…`)。 - 字节序(大端或小端)需与读取端一致(通常小端为主)。 --- ### **4. 典型应用场景** 1. **语音通信** - 电话系统(如 VoIP)、对讲机等,优先保证低带宽和实时性,16kHz/16bit 可满足清晰人声需求。 - 示例:微信语音消息的压缩前原始数据可能采用类似格式。 2. **语音识别** - 语音助手(如 Siri、小爱同学)通常接收 16kHz PCM 数据,匹配人声频段并降低计算复杂度。 3. **嵌入式设备** - 资源有限的硬件(如单片机、低功耗传感器)优先使用低采样率、低位深度的 PCM 数据以减少存储和传输压力。 4. **音频预处理** - 机器学习训练前,常将音频统一降采样至 16kHz 以标准化输入维度。 --- ### **5. 与其他格式对比** | 参数 | 16kHz/16bit PCM | 48kHz/24bit PCM | MP3压缩格式) | |---------------|------------------------|--------------------------|-------------------------| | **音质** | 电话级,人声清晰 | 高保真,音乐细节丰富 | 有损压缩,细节丢失 | | **文件体积** | 较小(31.25KB/秒) | 大(288KB/秒) | 极小(4~8KB/秒) | | **延迟** | 低(适合实时传输) | 较高 | 需编解码,延迟较高 | | **用途** | 语音、低带宽场景 | 音乐制作、影视音频 | 流媒体、存储 | --- ### **6. 生成与处理示例** - **生成 PCM 文件**: 使用音频库(如 Python 的 `wave`、C 的 `libsndfile`)或录音设备直接录制为 PCM。 ```python import wave with wave.open("audio.wav", "wb") as f: f.setnchannels(1) # 单声道 f
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值