精华内容
下载资源
问答
  • WebRTC音频编码(转)

    千次阅读 2017-07-29 15:42:00
    是在GIPS被收购之后伴随WebRTC开源的编解码器,他的特点是支持16khz,24khz,32khz。支持带宽估计(这是很多语音编解码器不具备的)。并且他不是基于CELP框架,使用了频域编码框架+格型编码+算数编码的框架。具有...

    一、一个典型的IP通信模型

    二、Server2Server技术分类

    Server2Server这块也是一个专门的领域,这里只简单分个类。

    1、同一国家相同运营商之间:

    同一运营商之间也有丢包,在铁通,鹏博士等运营商中尤甚。并且在晚高峰的时候表现更加突出。

    2、同一国家不同运营商之间:

    在很多时候,由于运营商之间的结算和有限带宽的问题。运营商之间的网络不稳定。

    3、不同国家之间:

    同一个国家都这么多问题,不同国家的问题回更复杂,在不同的国家要选择好的机房,实时选择实时监控。比如以下地方。以下地区,我们端到端延时平均为157ms。

    • 中美,中欧

    • 东亚:中,日本,韩国,台湾

    • 其他地区:拉丁美洲,印度,菲律宾,泰国,南非,中东

    三、Server2Device——Lastmile技术简介

    我们在公网做实时音视频服务,丢包对抗是少不了的。

    首先我们定义下什么是丢包:没按时到的包就是丢包。一个包应该在某个时间点到,但它晚到了,即使来了但是晚了,也叫丢包。因为播放的这段时间已经过去了,即使放了,体验也不好。从整个网络上看,丢包一定有时限,否则,都通过反复重传方法,一定能送达一个包。

    Server到达device这块还可以分以下两种通路。

    1、Server经过基站到Device

    可以分为以下几种情况:

    • 不同类型的基站:3G/4G,TD和WDCDMA就不一样。

    • 相同类型的基站不同的地点:北京联通推出流量包月下行最高150kbps的服务

    • 相同基站相同地点不同时间:球赛,运动会,热点聚集区附近的基站

    • 不同国家的基站:中国的WCDMA和印度的WCDMA和美国的WCDMA

    2、Server经过家用路由器到Device

    2.4G路由和5G路由,2.4G路由覆盖面积广,但是2.4G频段很脏,容易干扰和丢包。5G路由相对好些,但是覆盖面积小。并且在公司内部,会有多个路由,很多人连一个路由。竞争严重,有时网络丢包会很高。并且有些路由器是有bug的,比如小米路由的梳状抖动模型。

    四、Device技术简介

    AVDM,AVPM,AVCM,AVNM

    1、AVDM(Audio Video Device Module):

    AVDM是主要针对device的播放,录音录像端做处理的模块。不同的平台会有不同的驱动和录音录像需求,比如XP、Vista、win7、win8。我们不能一概而论的统一选择dshow甚至是waveout来播放还是录音。在移动端、iOS、安卓,安卓本身也有java和opensles两种录音方法,并且还有一系列的配置参数。比如用什么样的参数能录立体声,关闭手机自带处理,录高音质声音,延时低等等。和device相关的还有就是硬件能力:GPU、CPU的能力,对于视频而言,不同的CPU能支持怎么样的视频编解码能力输出。

    2、AVPM(Audio Video Processing Module)

    AVPM在视频上指美颜、降噪。音频的一般前后后处理包括3A引擎、AEC、ANS、AGC、混音、加混响(音乐直播)、去混响(会议模式)。是否应该用GPU,什么情况下应该用GPU。用GPU是为了省电还是运算快?

    3、AVCM(Audio Video Coding Module)

    编解码器的选择和处理,视频包括是选择VP8、VP9,还是选择264、265,是用硬件还是用软件,是否涉及专利问题。选择硬件会遇到什么问题,选择软件会遇到什么问题,为什么用硬件会遇到很多参数不能配置的问题。是否需要和硬件厂商配合。安卓碎片化导致的硬件支持问题。高通的硬件支持有什么问题,mtk的硬件支持有什么特点。硬件支持是否还要交专利费。

    4、AVNM

    音视频的JitterBuffer,FEC,PLC,BWE。Jitterbuffer主要是为了对抗网络抖动,对不熟悉Jitterbuffer的人,早期我们经会听到一种理解,jitter为什么不拉大啊?另外jitterbuffer的设计也是要结合更多的输入才能更好发挥作用。

    BWE:带宽估计,用于估计网络的带宽,以便实时调整。但是这里会有两种估计模型,基于RTT和基于丢包,如何选择?

    以上每个点都能讲或者写很多内容,本文只做简单梳理、点到为止,以后再做专题分析。

    五、IP通信的几种结构

    1. 1v1的双工通信结构(交互):最简单的一对一通信,要做好也不容易。

    2. MxM的全双工通信结构(交互): 小型会议。(这块要注意,在移动设备上首先要移动设备的尺寸问题,展示方法和技术要求也有不同,比如多人会议时会有多种layout可能,一大N小,平均分屏)。

    3. 1xN的单工通信结构(直播)

    4. MxMxN的单双工混合结构(交互直播)

    5. N的短延时方案,随时交互

    6. N的长延时方案,永不交互(9158实际在比较早的时候就实现了这种技术)。

    六、音频编解码器选择与丢包对抗方法介绍

    前面概述了基本网络模型和一些技术需求点,下面我针对本次重点做个分享:编解码器的选择和抗丢包技术。这两项技术对整个通信网络都有影响,在不同的网络条件下选择方法也不同。但一般来说,正确的选择编解码器和对应的抗丢包技术对Lastmile和端到端的音频质量影响最大。VOIP通信很早就有了,在不同的时代,我们选择了不同的编解码器实现对音频的传输,我们通常会做下面的分类。

    1、VOIP通信中Codec选择的几个时代。

    1)ITU Gxxx时代:G711,G722,G723.1,G729ab等等

    G711主要用在移动通信基站和基站之间的包交换网络中,并且在有些提供VOIP服务的监控摄像头上使用。64kbps,8khz压缩。

    G722系列包括G722,G722.1,G722.2。是针对WB,16khz和SWB 32khz的压缩算法。比较著名的是G722.1 也就是Polycom的Siren Codec,他的特点语音编解码为数不多的频域编码框架,不仅对语音支持比较好,对音乐支持也还可以。在Polycom的VOIP设备中通常支持该编解码器。

    G722.2就是AMR-WB+,是32khz语音编解码器,同时支持音乐编码,是AMR-WB的超宽带版本,但是由于他前向兼容AMR系列的框架,内核选择了CELP编解内核,对音乐编码有先天的问题

    2)AMRNB/WB,Speex,ILBC/ISAC,SILK时代

    AMR系列:作为8kbps~12kbps的语音编解码器,在一段时间内,质量是不错的,毕竟他是WCDMA和TDCDMA标准选择的语音编解码器。也通过3GPP标准开源。在有一段时间Yy语音和QTalk,微信语音留言都使用了AMR编解码器。但是他的问题是,有专利费,固定比特率。抗丢包性能一般。

    • Speex:Speex是由Jean Marc Valin(也是CELT的主要发明人)开发的编解码器,特点是免专利费,开源。支持宽带超宽带。缺点是这个编解码器可能是为了避开专利,并且受限于很多因素,编码质量并不好。无论是窄带宽带超宽带,对抗丢包,质量都很一般。但是这也是站在今天的角度看当时的技术,并且在当时能够提供免专利费的全频带,低速率(16kbps左右)语音编解码器确实没有,可以说,Speex填补了空白。并且Speex有一个显著特点是,Speex实际上不是一个编解码器,是一个音频处理集。包括AGC,AEC,ANS。可以完整的应用在一个VOIP通信系统中,并且他的AEC的自适应滤波部分做的相当不错,在PC上可以拿来使用。

    • ILBC和ISAC:ILBC编解码器是GIPS(WebRTC前身)第一个开源出来的编解码器。8khz,13.3kbps。窄带编解码器。他的特点是,抗丢包性好。信源编码的基础是去冗余,信道编码的基础是加冗余。去冗余的弊端就是抗丢包差,所以ILBC反其道行之,减少帧间冗余的压缩,增加每个帧独立性,使得当发生丢包的时候,丢包对抗效果好。ILBC在部分呼叫中心公司有广泛应用。ISAC是在GIPS被收购之后伴随WebRTC开源的编解码器,他的特点是支持16khz,24khz,32khz。支持带宽估计(这是很多语音编解码器不具备的)。并且他不是基于CELP框架,使用了频域编码框架+格型编码+算数编码的框架。具有一定特殊性。ISAC继承了ILBC的抗丢包优点,但是缺点也相当突出,由于用了频域编码器,高频语音编码效果不好,听起来有金属音,PESQ-WB MOS分低。

    • SILK:SILK面世时代比较晚,是以上编解码器中最晚开发一个编解码器。他的发明人是Ken Vos,也是ILBC,ISAC的主要开发者。Ken VOS在离开GIPS之后去了高通,为高通开发了一个宽带编解码器。然后到Skype为Skype开发SILK。Skpye有一段时间也是使用GIPS的方案,用ILBC和ISAC。后面自己开发Codec,他们第一个自己的Codec是VSOPC(好像,这里缺一个wiki的链接)。但是质量很差,用户抱怨。故请来了Vos开发SILK。Vos又在Skpye尝试新框架,Vos的SILK使用了预测加噪声整形的混合框架(第一使用类似框架的是Broadcom的BV16,BV32编解码器)。使用STP+LTP+STNS+LTNS两层后反馈嵌套(BV16和BV32是一个前馈+一个后馈,这里差图和wiki链接)。并且引入Delay Decision量化搜索方法,使得标量量化具有矢量量化的性能指标。可以说SILK的质量是非常好的一个编解码器。(这里差一个表),无论主观还是客观。虽然他充分挖掘相关性,但由于做到极致和非常完美,使得在丢包对抗上有一定帮助。并且他开发了RED辅助编码算法,提高他的抗丢包能力。

    我个人,是非常推荐初级和中级算法工程师仔细阅读SILK编解码器,代码质量好(EE工程师中少见),并且用了很多基础算法,很多小技巧,甚至包括自动控制理论。对提升自己的能力很有帮助。

    3)Opus/EVS时代

    Opus在2012年横空出世,按照官网的说法,opus比HEAAC好,并给了一些demo。但事实真的是这样吗,Opus是由SILK+CELT混合的编码器,学术上的叫法叫做USAC,Unify Speech and Audio Coding。这点,EVS也是。意思是不区分音乐语音的编解码器。这个编解码器内有个一Music detector去判断当前帧是语音还是音乐,语音选择语言框架编码,音乐选择音乐框架编码(注意目前还没有统一框架,原因是框架一般是人体生理模拟,因为人有两个声学器官,嘴和耳朵,所以语音是针对声带,口腔,鼻腔见面,音乐是根据人耳朵结构的时间掩蔽,频域掩蔽,双耳暗示效益编码)。所以,Opus适合电台这种音乐语音混合编码器。但是由于Opus的音乐编码CELT的质量并不突出,所以Opus在双声道低速率(24kbps~32kbps左右)效果并不突出。在网站上的demo缺少钢琴,爵士,摇滚的demo。更多是流行音乐和民谣。高频分量相对弱些。但如果使用Opus有以下要注意事情,音频码率高些,不要限制编码器的模式。另外高通宣称有OPUS专利,来自大神Ken VOS。
    EVS 主要是VoiceAge公司,Dolby公司,Fraunhofer,华为(北京苗磊兄弟,羡慕你们)联合开发的USAC编码器(这里面也有故事,和技术无关,我就不八卦了),低速率音乐编码器质量很好,源自dolby和Fraunhofer的HEAACv2技术。但是问题是,目前没有高效的嵌入式系统可用的编码器,不支持双声道,专利费不便宜哦。主要计划用在未来的VoLTE中(华为又要收苹果钱了哦)。 

    2、直播中Codec选择

    1)AAC系列与Opus
    没什么好说的,音乐电台可以选择Opus,主流的还是AAC,注意,建议立体声使用HE-AACv2,单声道选择HE-AACv1。而不是一般的AAC。HE-AACv1 = AAC + SBR,HE-AACv2 = HE-AACv1+ PS.
    AAC的合理编解码质量是在双声道64kbps~128kbps(商用编解码器和标准参考代码是不一样质量的,请区分)。HE-AACv1的合理编解码器区间是双声道40kbps~64kbps。HE-AACv2的合理编解码器区间是双声道24kbps到48kbps。

    3、丢包对抗的几种办法

    1)重传:

    传统物理信道传输中,无论是802.11还是3g/4g标准,本身就包含物理层重传机制,在IP信道中,重传也是非常有效的方法。
    优点:节省带宽,按需重传。
    约束条件,RTT时间短

    2)FEC:

    FEC有很多种,主要特点是主动抗丢包,通过增加冗余数据实现抗丢包效果。缺点是浪费带宽。一般的说,只有在丢包大于10%的时候才使用FEC。FEC技术有以下分类方法。

    • 不分级的FEC

    • 信源FEC

    • Inband FEC

    • Outband FEC

    • 信道FEC

    • Read SolomonCode

    • DigitalFountain Code

    • 分级的FEC

    • PLCPLC的意义在于当FEC和重传之后还无法恢复的时候,通过信号处理的方法对丢失的数据进行补偿。

    分类:

    • 插0法:所谓插0法就是在丢包的位置全添0.

    • 预测法,插值法,快慢放(注意,快慢放有副作用,大家不愿意接受这种做法)

    • 基于编解码模型的PLC方法

      • 特点:被动抗丢包。

      • 优点:灵活不占带宽

      • 缺点:根据编解码器的类型,对抗能力有限对低压缩比的编解码器,可以做到比较高的抗丢包效果。对高压缩比的编解码器,一般看丢包能力在5%以下。

    • 高级PLC算法,盲宽带带宽扩展(BWE),就是把8Khz拓展到16Khz。

    七、WebRTC

    Webrtc的缘来:WebRTC的前身是GIPS,在GIPS被Google收购之后,google选择将GIPS的源代码开源。但是其实不是全部。只能说绝大部分已经开源。
    ##1、Webrtc适用于什么条件
    包装开发,满足1对1,P2P,Iphone 通信,对质量没有啥要求
    二次开发,抽取webrtc的好的部分,自己开发,但是工作量很大
    ##2、Webrtc的问题

    1)P2P的问题

    WebRTC使用的是P2P的方法进行网络传输,并宣称保密性好。P2P在通信中Skype使用的比较早,有人曾经在网上分析过Skype全球有21个节点。其余都用P2P传输。但是这个前提是当时Skype大部分是基于PC+LAN/WIFI网络。适用于一对一通信,容易穿透,用户流量没限制,CPU稳定。而在Skype向手机普及,在无线网上提供VOIP服务的时候,增加了大量服务器路由。
    缺点:占用别人流量,不适合在多人通信中,要求网络稳定。
    优点:适用于demo。

    2)Lastmile的问题

    在lastmile对抗上,webrtc的对抗过于死板,缺少对现网的监控与反馈,虽然在webrtc内部有大量的不错的算法,但是缺少有机适用,比如,有些参数还是针对有线网设计的参数。

    3)Device 的回声消除

    安卓的碎片化,和回声消除的固有特点使得WebRTC在移动端无法满足让所有机型都处理的很好。

    4)如果你想用webrtc开发你要做什么

    架设服务器,监控,运维,客服。

    Lastmile网络对抗,自己做策略AVNM,前面描述了很多种网络状态,要靠单一的方法是无法满足全面做好,需要复杂的数据挖掘,分析,整理再反馈网络策略参数调整才可以完成。端的AV-D/C/P/-M算法,自己要做AV的硬件机型配置,选择和改进。需要在安卓机型做大量的回声消除算法改进。

    【本文作者】高泽华,11年音乐语音编解码学习经验。理解几十种音频编解码标准。先后在中磊电子、士兰微电子、虹软科技主导音频项目。任职YY期间负责语音音频技术工作。对音频算法在芯片设计、嵌入式系统、桌面软件。在互联网应用和专利分析方面有多年研发经验和积累。目前负责声网Agora.io的音频开发工作

    转载于:https://www.cnblogs.com/idignew/p/7256121.html

    展开全文
  • webrtc音视频编解码

    2021-02-28 10:25:30
    webrtc视频编解码应用资源 https://github.com/pion/mediadevices/tree/master/examples/webrtc https://github.com/rviscarra/webrtc-remote-screen ... 安装libvpx ...sudo apt-get update -y ...

    做webrtc视频编解码应用资源

    https://github.com/pion/mediadevices/tree/master/examples/webrtc

    https://github.com/rviscarra/webrtc-remote-screen

    https://github.com/rviscarra/webrtc-speech-to-text

    https://github.com/giongto35/cloud-morph/tree/master/pkg

    https://github.com/deepch/RTSPtoWebRTC

    https://github.com/deepch/RTSPtoWeb

    音频解码libopus 

    下载
    https://www.opus-codec.org/downloads/

    解压
    tar xf opus-1.3.1.tar.gz
    cd opus-1.3.1
    编译
    BUILD_LIBS=${HOME}/build_libs
    ./configure --prefix=${BUILD_LIBS} --with-pic --enable-float-approx
     make
     make install

    安装libvpx

    Step 1
    sudo apt-get update -y
    Step 2
    sudo apt-get install -y libvpx-dev
    Step 3
    Check the system logs to confirm that there are no related errors. You can use ZoomAdmin to check the logs, manager servers, host multiple websites and apps on your servers and more. The apps run in docker containers, to learn more
    see ZoomAdmin Features for list of features and demo videos. And you can start with the Free Plan.

    安装libx264

    原文链接:https://blog.csdn.net/jenie/article/details/110000453

    1).安装依赖的包:

    sudo apt-get update
    sudo apt-get install build-essential git-core checkinstall texi2html libfaac-dev \
    libopencore-amrnb-dev libopencore-amrwb-dev libsdl1.2-dev libtheora-dev \
    libvorbis-dev libx11-dev libxfixes-dev zlib1g-dev

    2.安装Yasm:x264需要使用yasm来针对CPU架构进行优化,提高性能。

    cd
    wget http://www.tortall.net/projects/yasm/releases/yasm-1.2.0.tar.gz
    tar xzvf yasm-1.2.0.tar.gz
    cd yasm-1.2.0
    ./configure
    make
    make install

    3.安装x264:下载源代码、编译、安装

    cd
    git clone git://git.videolan.org/x264
    cd x264
    ./configure --enable-shared    //动态库
    make
    make install

    4.此时 libx264.so默认安装在/usr/local/lib,直接编译会出现

    tmux: error while loading shared libraries: libx264.so.2: cannot open shared object file: No such file or directory

    原因就是已经安装了该共享库, 但执行需要调用该共享库的程序的时候, 程序按照默认共享库路径 /usr/lib 找不到该共享库文件. 

    如果共享库文件安装到了/usr/local/lib(很多开源的共享库都会安装到该目录下)或其它"非/lib或/usr/lib"目录下, 那么在执行ldconfig命令前, 还要把新共享库目录加入到共享库配置文件/etc/ld.so.conf中, 如下:

    # cat /etc/ld.so.conf
    include ld.so.conf.d/*.conf
    # echo "/usr/local/lib" >> /etc/ld.so.conf
    # ldconfig
    windows下x264

    https://blog.csdn.net/martinkeith/article/details/105323052

    展开全文
  • 导读:雅特生科技(Artesyn Embedded Technologies)宣布PCI Express媒体处理加速卡已支持音频编/解码器,这款现已重新命名为SharpMedia PCIE-8120的加速卡可以支持OTT网络服务和WebRTC网关等应用,也确保网络服务...
  • 确认Chrome WebRTC使用的编解码格式

    千次阅读 2017-05-09 13:07:14
    使用 webrtc-internals 确认webrtc编解码格式

    在“让WebRTC支持H264编解码”中我提供了一种优先使用 H264 编解码的思路。我们可以在浏览器那端来验证一下。

    有三种方式来验证:

    1. 在 JS 里打印 sdp
    2. 查看 Chrome 的日志 chrome_debug.log(见开启 Chrome 日志
    3. 抓包
    4. 使用 webrtc-internals

    前三种不再介绍,我们单看下 webrtc-internals 。

    在浏览器地址栏输出 chrome://webrtc-internals 就可以看到当前浏览器中的 WebRTC 状态信息。类似下面:

    找到 ssrc_xxx_recv(ssrc) ,点开,就可以看到类似下面的信息:

    蓝线标注出了浏览器使用的解码器和视频格式。

    关于 webrtc-internals 的更详细介绍,参考这里:http://testrtc.com/webrtc-internals-parameters/


    相关阅读:

    展开全文
  • WebRTC主要用来让浏览器实时获取和交换视频、音频和数据。浏览器本身不支持相互之间直接建立信道进行通信,都是通过服务器进行中转,A、B两个客户端之间信令还是要通过服务器传送,但这并不适合数据流的传输,WebRTC...

           WebRTC主要用来让浏览器实时获取和交换视频、音频和数据。浏览器本身不支持相互之间直接建立信道进行通信,都是通过服务器进行中转,A、B两个客户端之间信令还是要通过服务器传送,但这并不适合数据流的传输,WebRTC应运而生。

            WebRTC是一个开源项目,旨在建立一个浏览器与浏览器之间的信道,这个信道开源发送任何数据,而不需要经过服务器,这里说不的不需要服务器并不是真的不需要服务器了,还是需要服务器来传送信令,只是音视频数据不需要服务器进行中转传输了。

            WebRTC很大,里面包含太多东西,其中的iLBC音频编解码库很好,我想抽取出来编译成静态库在iOS平台上调用,于是,

            1、抽取了ilbc文件夹加入新建的Xcode静态库编译工程;

            2、除了ilbc文件夹里的文件,ilbc还依赖common_audio文件夹里的signal_processing文件夹中的文件;

            

            3、试着编译,发现错误,加入缺少的头文件

             

            4、错误还是有,很多方法找不到之类的,我得解决方法找不到的让其找到就行了,然后编译成功。



           编译好了后得到静态库libcodecOfiLBC.a然后就是怎么用这个库了,用这个库时需要WebRTC里的头文件ilbc.h及typedefs.h,然后封装个类来调用libcodecOfiLBC.a,建个头文件CIlbcCodec.h:

    //
    //  CIlbcCodec.h
    //  CIlbcCodec
    //
    //  Created by hkshen on 15/5/25.
    //  Copyright (c) 2015年 hkshen. All rights reserved.
    //
    
    #ifndef __CIlbcCodec__CIlbcCodec__
    #define __CIlbcCodec__CIlbcCodec__
    
    #include <stdio.h>
    
    class CIlbcCodec {
        
    public:
        unsigned char		m_pDupData[960];
        unsigned int	    m_nDupLen;
        
    public:
        CIlbcCodec();
        virtual ~CIlbcCodec();
        
        /**
         * Stop encode
         */
        void reset_encoder_impl();
        
        /**
         * Stop decode
         */
        void reset_decoder_impl();
        
        int cellcom_audio_ilbc_Codec_resetEncoder();
        
        int cellcom_audio_ilbc_Codec_resetDecoder();
        
        /**
         * WebRTC ilbc encode
         */
        int cellcom_audio_ilbc_Codec_encode(unsigned char* pByteIn, unsigned int nRawLen, unsigned char* pByteOut);
        
        /**
         * WebRTC ilbc decode
         */
        int cellcom_audio_ilbc_Codec_decode(unsigned char* pByteIn, unsigned int srcLen, unsigned char* pByteOut);
    };
    
    #endif /* defined(__CIlbcCodec__CIlbcCodec__) */

    CIlbcCodec.cpp:

    //
    //  CIlbcCodec.cpp
    //  CIlbcCodec
    //
    //  Created by hkshen on 15/5/25.
    //  Copyright (c) 2015年 hkshen. All rights reserved.
    //
    
    #include "CIlbcCodec.h"
    #include <math.h>
    #include <stdlib.h>
    #include <stdio.h>
    #include <string.h>
    #include "ilbc.h"
    //#include "defines.h"
    
    static iLBC_encinst_t *Enc_Inst = NULL;
    static iLBC_decinst_t *Dec_Inst = NULL;
    
    const short MODE = 30; //30ms
    const short FRAME_SAMPLES = 240; //MODE << 3;//240
    const short FRAME_SIZE = 480; //FRAME_SAMPLES * sizeof(short);//480
    
    const short NO_OF_BYTES_30MS = 50;
    
    static int encoding, decoding, encoderReset, decoderReset;
    
    //
    // CIlbcCodec Implementation
    //
    
    CIlbcCodec::CIlbcCodec() {
        
        memset(m_pDupData, 0 ,960);
        m_nDupLen = 0;
    }
    
    CIlbcCodec::~CIlbcCodec() {
        
    }
    
    void CIlbcCodec::reset_encoder_impl() {
        
        if (!encoding) {
            WebRtcIlbcfix_EncoderFree(Enc_Inst);
            Enc_Inst = NULL;
            encoderReset = 0;
        } else {
            encoderReset = 1;
        }
    }
    
    int CIlbcCodec::cellcom_audio_ilbc_Codec_resetEncoder() {
        
        reset_encoder_impl();
        return 1;
    }
    
    int CIlbcCodec::cellcom_audio_ilbc_Codec_encode(unsigned char *pByteIn, unsigned int nRawLen, unsigned char *pByteOut) {
        
        int bytes_remaining = 0;
        int bytes_encoded = 0;
        int bytes = 0;
        int encoded_len = 0;
        
        encoding = 1;
        
        if (Enc_Inst == NULL) {
            WebRtcIlbcfix_EncoderCreate(&Enc_Inst);
            WebRtcIlbcfix_EncoderInit(Enc_Inst, MODE);
        }
        
        //wait
        //pByteIn += nRawLen;
        bytes_remaining = nRawLen;
        
        int truncated = bytes_remaining % FRAME_SIZE;
        if (truncated) {
            bytes_remaining -= truncated;
            printf("Ignoring last %d bytes, input must be divisible by %d", truncated, FRAME_SIZE);
        }
        
        while (bytes_remaining > 0) {
            //ilbc编码
            bytes = WebRtcIlbcfix_Encode(Enc_Inst, (short *)pByteIn, FRAME_SAMPLES, (int16_t *)pByteOut);
            pByteIn += FRAME_SIZE;
            bytes_encoded += FRAME_SIZE;
            bytes_remaining -= FRAME_SIZE;
            
            pByteOut += bytes;
            encoded_len += bytes;
            
            if (bytes == -1) {
                printf("encode failed\n");
            }
        }
        pByteIn -= bytes_encoded;
        pByteOut -= encoded_len;
        
        encoding = 0;
        if (encoderReset) {
            reset_encoder_impl();
        }
        
        return encoded_len;
    }
    
    void CIlbcCodec::reset_decoder_impl() {
        
        if (!decoding) {
            WebRtcIlbcfix_DecoderFree(Dec_Inst);
            Dec_Inst = NULL;
            decoderReset = 0;
        } else {
            decoderReset = 1;
        }
    }
    
    int CIlbcCodec::cellcom_audio_ilbc_Codec_resetDecoder() {
        
        reset_encoder_impl();
        return 1;
    }
    
    int CIlbcCodec::cellcom_audio_ilbc_Codec_decode(unsigned char *pByteIn, unsigned int srcLen, unsigned char *pByteOut) {
        
        int bytes_remaining = 0;
        int bytes_decoded = 0;
        int num_samples = 0;
        short speechType = 0;
        int decode_len = 0;
        
        decoding = 1;
        if (Dec_Inst == NULL) {
            WebRtcIlbcfix_DecoderCreate(&Dec_Inst);
            WebRtcIlbcfix_DecoderInit(Dec_Inst, MODE);
        }
        
        //wait
        //pByteIn += Len;
        bytes_remaining = srcLen;
        
        while (bytes_remaining > 0) {
            //ilbc解码
            num_samples = WebRtcIlbcfix_Decode(Dec_Inst, (short *)pByteIn, NO_OF_BYTES_30MS, (short *)pByteOut, &speechType);
            
            m_nDupLen = 50;
            memcpy(m_pDupData, pByteIn, m_nDupLen);
            
            pByteIn += NO_OF_BYTES_30MS;
            bytes_remaining -= NO_OF_BYTES_30MS;
            bytes_decoded += NO_OF_BYTES_30MS;
            pByteOut += num_samples * sizeof(short);
            
            decode_len += num_samples * sizeof(short);
        }
        
        pByteIn -= bytes_decoded;
        pByteOut -= srcLen;
        
        decoding = 0;
        if (decoderReset) {
            reset_decoder_impl();
        }
        
        return decode_len;
    }


    单独编译WebRTC的ilbc工程: 点击打开链接


    展开全文
  • 导读:雅特生科技(Artesyn Embedded Technologies)宣布PCI Express媒体处理加速卡已支持最新的音频编/解码器,这款现已重新命名为SharpMedia PCIE-8120的加速卡可以支持OTT网络服务和WebRTC网关等应用,也确保网络...
  • 单独编译和使用webrtc音频回声消除模块(附完整源码+测试音频文件)
  • 音频解码: AudioDeviceWindowsCore::DoRenderThread()->AudioDeviceBuffer::RequestPlayoutData->AudioTransportImpl::NeedMorePlayData->AudioTransportImpl::PullRenderData->AudioMixerImpl::Mix->...
  • 示范网站 (广播网站) (侦听器网站) 要求 客户Firefox 23+(Windows和Mac。Android:media.peerconnection.enabled=true) 服务器: Python 2.7 / 3.2 龙卷风2.4 系统图
  • WebRTC 使用外部的音视频编解码

    千次阅读 2017-04-19 09:47:39
    WebRTC 支持使用自己的编解码器(限 native 开发),音频,视频都可以。这里以视频编码为例来分析下 WebRTC 中相应的源码。
  • 目录 AudioCodecSpec ...SdpAudioFormat //音频编解码SDP特性 名称 时钟频率 通道数 参数列表 AudioCodecInfo //音频编解码信息 采样频率 通道数 码率 是否容许舒适噪声 是否支持音频网络适配 ...
  • 阿尔卡特朗讯企业发行的WebRTC编解码器和质量工具(2014年12月) 描述 WebRTC实用工具,用于: 选择音频和视频编解码器 进行P2P音频和视频通话 检查感知质量与丢包率,帧率 安装与使用 下载所有文件并将其复制到您...
  • 1.2插入音频数据包到待解码数据包队列 1.3 解码音频数据包 1.1 接收音频数据包 cricket::BaseChannel::OnPacketReceived(bool rtcp, const rtc::CopyOnWriteBuffer & packet, __int64 packet_time_us) 行...
  • WebRTC音频

    千次阅读 2017-02-08 19:03:35
    webrtc整个的音频,采集,编码,打包,发送,到接收,解包,解码,播放,整个过程做了详细的描述
  • 年初因为工作需要,开始学习WebRTC,就被其复杂的编译环境和巨大的代码量所折服,注定是一块难啃的骨头。...音频引擎主要包含:音频设备模块ADM、音频编码器工厂、音频解码器工厂、混音器Mixer、音频前处
  • 正文字数:2602 阅读时长:4分钟通过语言编码中的码率缩减趋势,Lyra与Opus中的区别比较,Lyra的作用,XDN平台上的高效语音编码技术几个方面探讨新的Google Lyra音频...
  • WebRTC音频能量计算

    2020-12-08 19:10:59
    1.WebRTC音频能量计算 WebRTC中实现获取音频能量计算的方法是:获取音频数据最大的振幅(即绝对值最大)(范围是0-32767),然后再除以1000,得到0-32之间的数值。从数组中获取相应索引所对应的能量level等级。 我们...
  • WebRTC功能强大,集成了能分别处理音视频的API功能模块。... WebRTC的视频部分,包含采集、编解码(I420/VP8)、加密、媒体文件、图像处理、显示、网络传输与流控(RTP/RTCP)等功能。 视频采集---video_capture ...
  • 音频编解码介绍(最全v1.0)

    千次阅读 2020-12-18 21:06:24
    音频编解码介绍(最全v1.0) 目录: 1.PCMU(G.711U) 2.PCMA(G.711A) 3.ADPCM 4.LPC(Linear Predictive Coding) 5.CELP(Code Excited Linear Prediction) 6.G.711 7.G.721 8.G.722 9.G.723 10.G.723.1 11...
  • WebRTC的视频解码原理简析

    千次阅读 2019-03-31 22:23:20
    WebRTC的视频部分,包含采集、编解码(I420/VP8)、加密、媒体文件、图像处理、显示、网络传输与流控(RTP/RTCP)等功能。 视频采集---video_capture: 源代码在webrtc\modules\video_capture\main目录下,包含接口和...
  • 敬告:该系列的课程在抓紧录制更新中,敬请大家关注。敬告: 该系列的课程涉及:FFmpeg,WebRTC,SRS,Nginx,Darwin,Live555...音频解码为PCM代码实战。 4.PCM重采样原理及实战。 5.PCM编码为AAC实战。    
  • 前言 即时通讯应用中的实时音视频技术,几乎是IM开发中的最后一道高墙。...本文是一篇讲述新手如何学习音频编解码知识的文章。 说说音频编解码技术学习方法 总是有人问我研究音频编解码要看什么书,其实这是.
  • 上篇(webRTC音频相关的netEQ(四):控制命令决策)讲了MCU模块是怎么根据网络延时、抖动缓冲延时和反馈报告等来决定给DSP模块发什么控制命令的。DSP模块根据收到的命令进行相关处理,处理简要流程图如下。 从...
  • 上篇(webRTC音频相关的netEQ(三):存取包和延时计算)讲了语音包的存取以及网络延时和抖动缓冲延时的计算,MCU也收到了DSP模块发来的反馈报告。本文讲MCU模块如何根据网络延时、抖动缓冲延时和反馈报告等决定...
  • webrtc拿到订阅远端数据的answer后,设置远端sdp,启动音频渲染线程,循环向neteq的数据包接受队列中拿音频解码输出 webrtc_d.dll!webrtc::AudioDeviceWindowsCore::DoRenderThread() 行2975 C++ 启动渲染进程,...
  • 源码下载 请自行使用科学上网方式获取 ...WebRTC的编译需要2017及以上版本,因为会用到C++11、C++14的很多新特性。 安装VS2019时选择自定义安装,必须勾选如下几项: Desktop development with C++组件中 10.0
  • 本文来自网易云音乐音视频实验室负责人刘华平在LiveVideoStackCon 2017大会上的分享,并由LiveVideoStack根据演讲内容整理而成(本次演讲PPT文稿,请从文末附件下载)。...就音频而言,无论是算法多样...
  • webrtc音频处理流程

    千次阅读 2016-10-31 20:02:05
    本文概要介绍WebRTC音频处理流程,见下图 webRTC音频会话抽象为一个通道Channel,譬如A与B进行音频通话,则A需要建立一个Channel与B进行...上图中有三个Channel,每个Channel包含编解码和RTP/RTCP发送功能。
  • WebRTC 中的基本音频处理操作

    千次阅读 2019-12-13 13:56:26
    在 RTC,即实时音视频通信中,要解决的音频相关的问题,主要包括如下这些: 音频数据的采集及播放。 音频数据的处理。主要是对采集录制的音频数据的处理,即所谓的 3A 处理,AEC (Acoustic Echo Cancellation) 回声...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 3,594
精华内容 1,437
关键字:

webrtc支持音频编解码