流媒体

本文介绍了在Ubuntu零碎下配置wvp-GB28181-pro以及与ZLMediaKit联调的全流程教程。对于ZLMediaKit的配置过程请参照上一篇Ubuntu下配置ZLMediaKit的操作流程 1.装置依赖Ubuntu环境下： apt-get install -y openjdk-11-jre git maven nodejs npm2.装置MySql和Redis装置 MySql 和 Redis ，可在wvp本机也可在其余服务器上，具体操作形式此处不再具体阐明，网上很多。装置MySql后须要创立wvp数据库，执行sql/mysql.sql初始化数据库构造。 3.编译运行ZLMediaKit参照上一篇Ubuntu下配置ZLMediaKit的操作流程 4.编译wvp-pro4.1 下载代码#从gitee下载我的项目代码(此处还是装置在opt文件夹下)cd /optgit clone https://gitee.com/pan648540858/wvp-GB28181-pro.git4.2 编译前端页面cd /opt/wvp-GB28181-pro/web_src/#用淘宝源下载npm --registry=https://registry.npm.taobao.org installnpm run build4.3 打包我的项目cd /opt/wvp-GB28181-promvn package5.批改配置文件5.1 配置文件地位wvp配置文件基于spring boot的开发方式，配置文件的加载是很灵便的。默认在src/main/resources/application.yml，局部配置项是可选，你不须要全副配置在配置文件中， 齐全的配置阐明能够参看all-application.yml。 5.2 须要批改的配置内容配置文件中信息较多，以下是必须要改的 redis配置信息mysql配置信息ZLM连贯配置信息 (这里的media.id要和ZLM里的general.mediaServerId统一，ZLM的配置文件在release/linux/Debug/config.ini，也要留神端口等信息是否统一)6.启动我的项目将批改后的配置文件替换到jar包 BOOT-INF/classes 后启动。如果不想用替换jar包中配置文件的形式，能够通过指定配置文件的形式进行配置。 cd wvp-GB28181-pro/targetjava -jar wvp-pro-*.jar --spring.config.location=../src/main/resources/application.yml启动后拜访http://ip地址:18080进行登陆，默认用户名明码都是admin 7.注意事项wvp和ZLM联调胜利后，wvp会接管ZLM的配置文件，批改其中的相干信息wvp推流须要鉴权wvp联调后推流规定：推流时须要携带推流鉴权的签名sign，sign=md5(pushKey)（通过MD5转码后的32位字符串）pushKey来自数据库中user表，每个用户会有一个不同的pushKey。例如：pp=test，stream=live，pushKey=1000，ip=192.168.1.4, port=10554那么推流地址为： rtsp://192.168.1.4:10554/test/live?sign=a9b7ba70783b617e9998dc4dd82eb3c5反对推流时自定义播放鉴权Id，参数名为callId，此时sign=md5(callId_pushKey) 例如：app=test，stream=live，pushKey=1000，callId=12345678, ip=192.168.1.4,port=10554 那么推流地址为： rtsp://192.168.1.4:10554/test/live?callId=12345678&sign=c8e6e01dde2d60c66dcea8d2498ffef1具体规定和更多阐明可参照WVP官网文档

1 背景OPPO实时音视频(OPPO Real-Time Communication ORTC)，是咱们推出一套低延时、高品质、跨平台的音视频互通解决方案，通过OPPO云服务器向开发者凋谢，提供多人音视频通话、实时监控、应急指挥调度、互通直播、IOT万物互融、云游戏等能力输入。以往的音视频通信技术大多是基于SIP/H323的实现计划，本文提供一种交融计划，实现RTC与SIP的互联互通，使得RTC可能很轻易的实现与PSTN、SIP Trunk的对接，同时传统的会议终端通过该计划也能轻易接入RTC零碎。 2 ORTC简介 ORTC万物互连下的重要基础设施，解决了不同平台各色终端之间实时互连互通问题，为泛滥产品提供实时音视频通信能力，目前已上线及打算产品包含，小布视频通话，近程帮助，小游戏语音互动，云游戏，互动直播，小布会议，虚拟人，IOT等。 依靠OPPO云优质的节点资源，全网协同，动静智能路由，区域中级，就近接入，层级扇出，寰球连贯的特点，ORTC提供超低延时，超高并发，超高可用的音视频服务。 3 ORTC零碎架构ORTC是一款输入实时通信能力的PAAS云服务产品，总体架构蕴含媒体服务、信令服务、监控服务、接口服务、端侧接入SDK等。其中信令媒体是拆散的，信令通过SLB和Redis实现分布式及智能调度。媒体整体采纳SFU架构，反对级联，单个房间不同用户能够散布在多个媒体实例上。媒体反对合流录制，音视频流级联到MCU上，能够进一步实现合流后的录制、转散发。音视频传输上反对jitterbuffer、NACK、FIR、PLI, 音频反对AGC、AEC、NS，FEC解决上音频传输上下行均反对RED，视频上行反对ULPFEC。端侧SDK基于WebRTC的流程标准，所有的SDK均反对simulcast，反对实时字幕、语音激励。ORTC是在OPPO寰球混合云这个弱小底座平台根底上建设的一款高并发、低延时、跨平台、高可用的RTC服务平台。 4 SIP利用场景及架构SIP的利用无处不在，无论是思科、华为、Polycom这些传统会议厂商，还是海康、大华、宇视这些监控厂商，咱们都能找到SIP的影子，而基于SIP的产品在传统会议、监控等相干行业占据着很大一块市场。而5G及云服务的衰亡，无疑会给传统行业注入新的生机，赋予其变革的能源，因为它不仅给传统行业大大降低老本，还会晋升其效率及服务体验。举个例子，高速的监控如果上云存储上会节俭一大笔的开销，而随时随地都能实时的看到监控画面并与之互动无疑也是监管部门及用户脍炙人口的。这些能力都是RTC可能提供的，然而间接上RTC的话，无疑会给客户带去天翻地覆的革新，这也是大多数企业用户所不能承受的，他们乐见的是平滑的无缝的降级切换，而要做到这些就须要进行RTC与SIP的互联互通，并为之深度交融定制相应的解决方案。 RTC尽管是实时通信倒退的必然，而后它也有依赖的靠山，那就是根底的网络设施，因为寰球各地区，甚至同一地区的不同应用地点，不同人流量，网络信号都可能不同，造成基于纯数据网络的利用无奈很好的服务，而这时候基于PSTN的一般电话网或PTT无线对讲机可能就展现出了其稳固牢靠不掉线的特点，如果能把他们接入到RTC中无疑加强了RTC的抗弱网能力，拓展了其利用场景的范畴，而这些网络及设施的接入也须要ORTC与SIP进行融通。 随着万物互联的深刻，网络的触角延长到了力不从心的智能设施，这也为RTC提供了更广大的应用场景，这些设施平时可能对可靠性要求不高，偶然掉线也能承受；或者说他们可能就没有间接接入互联网，接入的是独立的网络，比方智慧社区的门铃，老人的手环，儿童的手表等IOT设施，其对应紧急被叫端的APP可能不是实时在线状态，这时候要获得和他们的紧急分割就须要借助于SIP外呼PSTN/LTE网络的一般电话。 而以上这些都对RTC与SIP的交融提出了需要，而要想把RTC做强做大做成音视频通信的基础设施，同时能提供各种协定的接入能力也是对ORTC的根本要求。 在下面的架构中，借助于SIP网关及SIP媒体服务器，实现了RTC服务与内部基于规范SIP协定的PSTN网络或SIP中继的无缝连接。 在ORTC与SIP的对接过程中，ORTC外部的架构是绝对独立的，通过SIP网关解决后SIP协定将会实现与WebRTC信令协定的映射转换，媒体流则通过规范的RTP/RTCP进行传输管制，而接入的SIP终端，也将被伪装成一个虚构的WebRTC Client入会。 尽管从架构上看，ORTC到SIP只需实现信令管制和媒体传输就功败垂成了，而后在施行过程上，要思考的实现细节还有很多，这其中包含转码、合流、平安传输、抗弱网个性、双流输入等。 5 ORTC-SIP 合流转码ORTC作为一款通用的音视频通信解决方案，其必然要求具备反对各种类型音视频编解码的能力，其中包含了前沿的音视频编解码Lyra、AV1，而传统SIP会议则大多应用绝对激进通用的编解码器，这就要求两者对接时具备非对称编解码的能力，而作为切入方，ORTC就要求具备解决这种非对称编码的转码性能。同时如果要间接替换第三方的服务，而只保留对方终端的话，则对方终端要看到的ORTC的合流输入，而不是当初基于SFU的多路输入，因而ORTC需具备合流（MCU）能力，即咱们的ORTC的媒体不能再仅仅是SFU，要同时具备SFU+MCU的能力输入。 具体架构兼容的施行如上图所示，sip终端通过sip服务器后，将于ORTC提供的虚构sip终端实现点对点的音视频通信，这样在两端各自与sip服务器实现背靠背的SDP协商之后，内部的媒体将转发至ORTC外部的媒体接收端，通过pipe输入至核心媒体节点后退出ORTC的智能调度散发过程，同时ORTC所有接入方的媒体数据，也将汇聚到MCU，经其合流后散发调度给sip server，sip server做进一步的加密解决后转发至sip终端。 同样，通过MCU合流后的数据，也能旁路输入，可能以直播模式交融CDN零碎进行散发，同时也具备云端录制能力。 6 ORTC-SIP抗弱网及安全控制 作为全球化经营的通信解决方案，其所面临的接入网络的根底能力及应用场景可能千差万别，有些中央网络信号强，有些中央则较弱，有些中央可能拥挤较重大，这就要求咱们的零碎具备较强的抗弱网能力，而ORTC基于WebRTC标准实现的软件，人造具备了较强的抗弱网能力。作为后来者的SIP要想完满的接入进来，则必然要求其不仅具备ARQ、FEC、FIR、PLI这些必备的抗弱网个性，还要具备较欠缺的码率、帧率动静自适应能力。 作为一款商用的实时通信软件，窃密无疑是其必备的属性，而ORTC基于wss+srtp的实现计划，给了用户全链路的信令及数据安全传输保障。而作为外来户的SIP服务，如果要完满的融入到ORTC上，则平安必定也是必要条件。因而在信令接入上sip协定须要承载在TLS上，媒体数据要采纳密级较高的SRTP传输，同时在服务部署上要做好相应的端口限度及防火墙防护。 7 ORTC-SIP 双流管制对于视频会议、直播等场景，双流的出现已成为音视频通信的必备技能。如何更好、更灵便的进行双流的切换及管制，也成为一项输入能力的重要指标。在ORTC与SIP的整个架构中，咱们提供了基于BFCP的双流传输控制协议，很好的解决了多端双流之间的来回自在切换。 8 ORTC-SIP集群随着业务的一直扩大与伸延，服务承载的并发也越来越大，而服务对象的特殊性，也要求零碎具备较牢靠的弹性扩缩容能力。服务高牢靠可伸缩，波及到的信令、sip、媒体、数据库服务均需反对集群及负载平衡。 ORTC外部借助与集群及智能路由曾经实现了集群负载及服务的主动伸缩。而sip作为一个有状态的协定，要实现牢靠的注册及呼叫上的负载平衡，则须要做不少工作。咱们目前采纳基于四层网络负载平衡外加外部服务桥接的计划，实现了端侧的平衡注册及业务散发，同时保障了在某台服务挂起时接入的sip终端主动切换至其余服务节点，不影响失常业务，提供了负载平衡能力的同时进步了软件的高可靠性。 9 瞻望5G、AI技术的倒退进一步推动了音视频技术的演进，并对RTC提出了更高的要求，更低的延时、更高的码率、帧率，给大规模的云上剖析提供了可能，也反向拓宽了5G的利用场景，晋升了AI的准确率，促成了云端AI的利用。 上图是一种采纳视频流测量心率的办法，其原理是基于皮肤中血液的强劲变动从而引发其对可见光排汇强弱的变动，进而利用滤波及离散傅里叶变换计算出心率值。将其与ORTC联合，就能够实现近程会诊的实时心率检测。在工业及非凡行业畛域联合5G及AI的利用场景还很多，而ORTC无疑将表演越来越重要的根底通信角色，逐步成为缺它不可的根底必备设施。 在目前ORTC+SIP架构根底上，咱们能够进一步扩大造成ORTC+N的场景接入能力，交融更多的流媒体协定，聚合更多的媒体利用，使得咱们的ORTC真正做到ALL IN ONE的根底通信能力平台。 10 援用[1] 网络负载平衡 http://cloud.oppoer.me/docsCe... 作者简介 Sunny OPPO高级后端工程师 领有10多年流媒体相干研发教训，先后参加并主导过IPTV、电视聊天软件、基于实时音视频监控的应急指挥调度平台、基于实时视频的多模态微表情研判零碎、RTC视频会议等我的项目的研发。 获取更多精彩内容，请扫码关注[OPPO数智技术]公众号

国内上制订视频编解码技术的组织有两个，一个是 国际电联（ITU-T），它制订的规范有 H.261、H.263、H.263+ 等，另一个是 国际标准化组织（ISO） 它制订的规范有 MPEG-1、MPEG-2、MPEG-4 等。而 H.264 则是由两个组织联结组建的 联结视频组（JVT）独特制订的新数字视频编码标准，所以它既是 ITU-T 的 H.264，又是 ISO/IEC 的 MPEG-4 高级视频编码（Advanced Video Coding，AVC）的第 10 局部。因而，不论是 MPEG-4 AVC、MPEG-4 Part 10，还是 ISO/IEC 14496-10，都是指 H.264。1、简介H.264，同时也是MPEG-4第十局部，是由ITU-T视频编码专家组（VCEG）和ISO/IEC动静图像专家组（MPEG）联结组成的联结视频组（JVT，Joint Video Team）提出的高度压缩数字视频编解码器规范。这个规范通常被称之为 H.264/AVC（或者AVC/H.264或者H.264/MPEG-4 AVC或MPEG-4/H.264 AVC）。 2、H264 编码分层H.264 被分为 视频编码层（Video Coding Layer, VCL） 和 网络形象层（Network Abstraction Layer, NAL）。前者 VCL 关注编码局部，重点在于编码算法以及在特定硬件平台的实现；而后者 NAL 负责格式化数据以及包封装，以保证数据在各种信道和存储介质上的传输。 视频编码层波及的概念： 视频压缩技术： 帧内预测压缩，解决的是空域数据冗余问题。帧间预测压缩（静止预计与弥补），解决的是时域数据冗徐问题。整数离散余弦变换（DCT），将空间上的相关性变为频域上无关的数据而后进行量化。CABAC 压缩。I帧：关键帧，采纳帧内压缩技术。P帧：向前参考帧，在压缩时，只参考后面曾经解决的帧。采纳帧间压缩技术。B帧：双向参考帧，在压缩时，它即参考后面的帧，又参考它前面的帧。采纳帧间压缩技术。GOP：两个I帧之间是一个图像序列；一个图像序列中只有一个I帧。网络形象层波及的概念： SODB：数据比特串（String Of Data Bits），即 VCL 编码后的最原始的数据（长度不肯定是8的整数，故需补齐）。RBSP：原始数据字节流（Raw Byte Sequence Payload），即在 SODB 的前面增加了 rbsp_trailing_bits（第一个比特为1，接下来是0，直到字节对齐）。Emulation Prevention Bytes：防竞争码（0X03），即在编码时，每遇到间断两个 0x00 字节，就插入一个字节的0x03（如 0x000001 => 0x00000301）。解码时将0x03去掉。也称为脱壳操作。EBSP：扩大字节序列载荷（Extension Byte Sequence Payload），即在 RBSP 的根底上减少了防竞争码（0x03）。NALU：NAL单元（NAL Unit），蕴含NALU头和NALU主体（个别为RBSP）。NALU Start Codes：NALU包开始码，因为NALU中不蕴含大小/长度信息，因而不能间接连贯NALU包来构建码流，因为无奈晓得开始、完结地位。通常应用 0x000001 或 0x00000001 作为开始码，四字节的开始码通常用于 SPS、PPS、IDR等NALU，其余采纳三字节。// 逻辑关系SODB + rbsp_trailing_bits = RBSPmixin(RBSP, 0x03) = EBSPNALU header + NALU body(RBSP or EBSP) = NALUNALU Start Codes + NALU + NALU Start Codes + NALU + ... = H.264 Bits Stream // Annex-B3、视频编码TODO ...

以下为即构后盾负责人在2020QCon技术大会上的分享内容： 大家下午好。我是来自即构的廖念波，明天分享的主题是《即构音视频服务的架构实际》。简略介绍一下本人。我是一个在互联网行业工作快20年的老兵，之前在腾讯服务过，起初退出了即构，目前是负责即构的后盾技术研发。 即构是一家成立了5年的守业公司，即构这个名字来自即刻构建音视频通信能力。咱们心愿通过四行代码就能够让客户疾速取得音视频通信能力。 即构尽管是一个初创型的公司，但公司的外围开创团队和核心技术团队，在音视频技术这块实际上有超过19年的积攒，他们大部分是来自腾讯、华为、中兴、YY等国内最早从事音视频研发的人员。目前咱们服务的企业客户有4000多家，高峰期的每日通话日均互动时长冲破了20亿分钟。 我明天的分享次要从以下4个方面开展： 第一，带大家疾速理解音视频行业的业务状态 第二，介绍音视频云的架构 第三，介绍即构的多核心调度 最初，简略介绍我对技术经营的了解 一、业务介绍 1.即构流媒体业务简介 从下图中大家能够看到，实时音视频通信服务看起来是比较简单的。右边是各个端各个状态的推流，对应直播场景的话，就是一个主播，她能够通过Webweb、手机APP或小程序，甚至用一个第三方的软件，推入流到咱们的云上。 左边是收听观看主播音频视频的观众，他们所应用的设施也应用反对咱们的SDK。咱们的客户只有集成咱们的SDK，不须要再思考“服务器寰球散布，就近接入、日常运维”等因素，就能够疾速实现音视频实时通信的能力。 两头是即构的实时音视频通信云，咱们提供了各种能力，比方各种转封装转协定，反对各个端，还能把多路流依照肯定的视频布局，混流变成一路流。 其实相比传统的CDN直播，咱们突出的场景或用户诉求，是可能进行低延时的实时对话和互动。相比传统的CDN，它的老本也会是较高一点的。因为它部署的节点和传输要求走的线路，相对来说是必须优质的。 为了均衡老本和体验，咱们插入了多极灰度。中最常见显著的一种做法，当观众没有参加实时互动时，那么能够默认用 CDN推的流去收看，所以咱们也反对转推CDN。在实时互动时，咱们可能做到150ms-800ms这样一个寰球端到端的低延时。 2.即构的次要业务诉求 即构是做ToB服务的，ToB业务的第一个诉求，是高可用。 第二是低时延延时。咱们既然是做实时音视频通信，低时延第一眼是首要的，如果延时比拟大，那么对会话就很不天然了。 第三是大规模的散发。一路流推到咱们云端之后，可能最多要散发到几百万甚至上千万的观众各个终端上。 第四是弱网的抗丢包性。咱们的企业客户次要是在中国，但客户的用户，很多是寰球散布的在欧洲或者东南亚，所以咱们面向的是寰球散布的用户。不论是本地网络，还是直达互相通信过程中，都不可避免的会产生网络品质抖动问题，咱们在后盾能够监控到能够看到这种监控，在不同区域、不同国家的用户，它的网络品质差异是十分大的。 下面介绍了咱们业务的整体详情，大家能够看到直观了解上还是比较简单和和参差的。但这个业务的次要难点，第一它必须是高可用的，这是对客户的承诺。第二，在用户寰球散布的状况下，怎么做到低时延，怎么反抗丢包？接下来我将通过流媒体架构设计和多中心化的调度服务，介绍即构是怎么通过架构和技术来实现寰球低延时互动和大规模散发的。 篇幅关系，残缺内容和演讲PPT可扫描下方二维码获取。作为一名后盾技术的老兵，廖念波老师还在演讲中分享了本人对于后盾经营的丰盛教训，扫码即可查看。