1.手把手教你10分钟快速搭建webrtc
2.音视频协议--NACK系列一
3.FFmpeg/WebRTC/RTMP音视频流媒体技术
4.C/C++开发人员要了解的几大著名C/C++开源库
5.2024年 C++音视频开发学习路线（ffmpeg/rtsp/srs/webrtc/hls）
6.IOS技术分享| WebRTC iOS源码下载&编译
手把手教你10分钟快速搭建webrtc
搭建Webrtc步骤详解： 为了快速搭建Webrtc，我们参考了logan的GitHub项目，提供了Android和H5客户端，以及Java搭建的信令服务器。首先，基于Android的电子拍卖源码示例可以使用webrtc_android项目，而iOS端的开发将在后续补充。在PC端，我们利用H5和Java搭建的信令服务器进行点对点通信。 搭建流程如下：**NAT检测与流媒体中继**
使用谷歌官方提供的coturn作为STUN服务，完成NAT检测与流媒体中继。**使用自研信令服务器（Java Springboot）
** 为了实现客户端之间的通信，我们使用Java Springboot开发信令服务器。**客户端开发
** 客户端已经开发了安卓与H5（基于谷歌浏览器），实现了app-to-app、app-to-PC、PC-to-PC的点对点通信，目前尚不支持多人视频通话。 **注意事项****PC的H5使用adapter.js实现屏幕共享
** 在PC端的H5应用中，通过使用谷歌提供的adapter.js可以实现屏幕共享功能，同时在具备摄像头或麦克风的条件下，也能实现视频通话。**浏览器兼容性测试
** 当前测试结果显示，Chrome浏览器支持良好，理论上Firefox浏览器也应兼容。对于Safari浏览器，可能需要打开特定设置进行测试，由于缺少苹果设备，该测试尚未完成。Webrtc的原理与架构
Webrtc是由谷歌主导的开源流媒体传输和编解码框架。其主要架构包括：**NAT类型检测服务器
****流媒体中继服务器
****信令交换服务器
****客户端流媒体编解码
** 客户端使用谷歌开源的编解码库进行音视频编解码。搭建环境
搭建Webrtc所需的环境包括：服务器（CentOS 7.9，JDK 1.8），PC端（Windows ，JDK 1.8），以及安卓端（Android 9.0）。安装与配置步骤
**安装依赖
** 使用命令安装所需的软件包。**获取并编译coturn服务
** 从GitHub下载coturn源码，进行编译与安装，并配置服务器。**生成证书与配置服务器
** 生成服务器证书，并配置coturn服务以启动。as汇编源码测试与验证
**使用ICE测试
** 在Chrome或Firefox浏览器中进行ICE测试，验证STUN服务器的正常运行。**搭建信令服务器
** 使用Java Springboot搭建信令服务器，完成客户端间的通信。**客户端配置与测试
** 在客户端配置信令服务器地址和coturn服务器参数，进行点对点通信测试。优化与扩展
**兼容性优化
** 优化客户端对音频共享的支持，提高兼容性。**多人视频通话功能
** 开发多人视频通话功能，实现更多场景下的实时通信。**动态密码功能
** 实现动态密码功能，增强通信的安全性。学习资源与实践
欲深入了解Webrtc的开发与实践，可访问FFmpeg/WebRTC/RTMP/NDK/Android音视频流媒体高级开发的学习资源，免费获取更多音视频学习资料包、大厂面试题、技术视频和学习路线图。音视频协议--NACK系列一
在WebRTC技术中，前向纠错（FEC）与丢包重传（NACK）是抵抗网络错误的关键手段。FEC通过在发送端添加纠错码，确保数据包在接收端正确检查与纠正；而NACK机制在接收端发现数据丢失后，向发送端发送报文，促使发送端重新发送丢失的数据包。NACK机制在RFC中有详细定义。
本文以WebRTC源代码为基础，针对Video数据包的发送与接收，深入分析了NACK丢包重传机制的实现。主要内容涉及SDP协议中NACK的协商、接收端对丢包的判定、NACK报文的构造、发送、接收与解析，以及RTP数据包的重传。
在NACK框架中，NACK与ACK是通知机制的对比，当接收方未收到数据时，向发送方发送通知。根据RFC协议，重传未到达数据的类型分为RTPFB和PSFB。在WebRTC中，NACK功能与视频编解码器关联，java洋葱源码用于补偿因RTT延迟较小而产生的丢包问题。WebRTC在处理NACK重传时，设计了一个重传码率控制器，通过统计单位时间窗口周期内的数据发送量，限流以避免网络风暴。
NACK算法构建与实现方面，WebRTC的NACK算法通过NACKList进行数据包处理与反馈。具体流程包括接收RTP包、解析包头信息、数据帧获取与处理、构建NACKList，以及将NACKList通过RTCP反馈给发送端，实现数据包重发。
优化音视频流畅度过程中，发现NACK机制存在一定的问题，如通话初期有7~秒黑屏现象。分析后，马赛克问题可能与NACK参数优化不足有关。而黑屏问题可能与Android版本的NACK请求数据量较大且响应较慢有关，而iOS版本的NACK请求则更少且反应更快。针对这些问题，需要优化NACK机制参数与反馈机制，确保音视频流畅度。
通过改进NACK机制，结合网络状况与设备特性进行针对性优化，可以有效提升WebRTC通话过程中的音视频流畅度，降低黑屏、马赛克与卡顿现象，提供更优质的用户体验。
FFmpeg/WebRTC/RTMP音视频流媒体技术
深入探索FFmpeg、WebRTC和RTMP的音视频流媒体技术，本文将逐步为您解析各个领域的重要知识点与实战技巧。
首先，音视频基础知识不容忽视。对于FFMPEG环境搭建，无论是Windows还是Linux平台，我们都应熟练掌握。此外，深入理解音频与视频的基础，使用如Medialnfo与VLC播放器等常用工具，将使我们对音视频处理有更全面的datax 源码调试认识。
接下来，FFMPEG命令是音频、视频处理的利器，涵盖视频录制、多媒体文件分解与复用、裁剪与合并、与视频互转、直播相关操作，以及各种滤镜应用。编程实战中，音视频渲染需借助SDL环境，包括事件处理、线程操作、YUV视频播放与PCM声音播放。FFmpeg API的框架、内存模型与常用结构体，构成了更深层次的音视频处理能力。音视频编码领域，AAC与H编解码原理、解码与编码流程深入解析，使我们掌握音视频编码的核心。封装格式如FLV、MP4与多媒体转封装格式实战，是音视频分发的关键。音视频过滤器实战则聚焦于音视频过滤器的使用，包括视频过滤器的详细说明。播放器开发实战涉及播放器框架分析、音视频解码、播放控制与同步，掌握ffmpeg播放器源码解析，如ffplay.c中的意义，将使我们全面掌握播放器开发。
流媒体技术的深入理解是音视频技术的关键。了解RTMP、HLS、HTTP-FLV等流媒体协议，wireshark抓包技术，FFmpeg在流媒体服务器中的应用，以及首屏秒开技术、负载均衡部署方式，将使我们能够构建高效、源码免费制作稳定的流媒体服务。
最后，WebRTC技术的发展与应用是音视频领域的一大亮点。从中级开发到高级开发，深入研究WebRTC通话原理，搭建开发环境，配置coturn服务器，采集音视频数据，理解一对一会话流程，设计信令服务器，实现Web与Android、iOS间的通话，掌握AppRTC，将使您成为WebRTC开发的专家。高级开发中，自定义摄像头分辨率、调整编码器顺序、实现多方通话、利用Janus框架构建会议系统，以及理解拥塞控制算法、FEC、jitter buffer等，将使您的WebRTC项目更具竞争力。
本文旨在为您提供FFmpeg、WebRTC与RTMP音视频流媒体技术的全面解析与实战指导，更多音视频相关信息，欢迎继续探索与实践。
C/C++开发人员要了解的几大著名C/C++开源库
在开源软件领域，众多知名的国产软件如暴风音影、腾讯会议、PC版微信等，背后都依托于一些大型的C/C++开源库。本文将深入介绍几种日常工作中常用的C/C++开源库，为开发者提供借鉴与参考。
**多媒体处理开源库FFmpeg
**FFmpeg，享有盛名的音视频多媒体处理开源库，几乎每个做过音视频编解码开发的开发者都熟悉。它包含了广泛而全面的音视频编码协议，如H、H、MPEG4、H等，并提供了一整套音视频处理解决方案。从音视频采集与编码、解码、格式转换到视频抓图和加水印，FFmpeg都能轻松应对。其强大的sdk接口允许开发者直接接收和发送码流，读写文件，进行编解码操作，以及修改解码数据格式等。
FFmpeg基于C语言实现，执行效率接近汇编语言，特别适合对实时性有高要求的音视频处理场景。项目中常包含优化效率的汇编代码，直接控制操作以达到最优性能，不依赖通用编译器生成的汇编代码。
几乎所有的视频播放器都依赖FFmpeg的音视频解码功能，包括暴风影音、QQ影音、腾讯视频、爱奇艺视频、优酷视频等。播放器通过将压缩的视频图像帧解码为并连续显示来实现动态播放效果。帧率达到帧时，人眼就能感知连续动态的播放。
FFmpeg支持多种音视频格式的相互转换，广泛应用于格式工厂、暴风转码、QQ音影视频格式转换工具、狸窝视频转换器、迅捷视频转换器等软件。
**实时音视频处理开源库WebRTC
**WebRTC，由Google发起的实时音视频通讯开源库，提供了从音视频采集、编码、网络传输到解码渲染的整套解决方案。WebRTC使得开发者能够轻松构建实时音视频应用，无需下载插件，只需编写简单的JavaScript程序即可实现。
WebRTC基于C/C++实现，具有跨平台性能，支持Windows、MAC、iOS和Android等多系统，通过调用相应系统的SDK即可构建音视频应用。虽然称为WebRTC，它不仅支持Web间通讯，还支持Windows、Android和iOS平台。
WebRTC因其出色的音视频效果和网络适应性，广泛应用于视频会议、实时音视频直播等领域。腾讯会议、华为WeLink、字节飞书、阿里钉钉、科达、ZOOM、小鱼易连等均采用了WebRTC方案提供视频会议服务。声网（Agora）基于开源WebRTC库，提供了多个行业的音视频互动解决方案，服务覆盖了包括小米、陌陌、斗鱼、哔哩哔哩、新东方、小红书、HTC VIVE、The Meet Group、Bunch、Yalla等企业和机构。
**Chromium浏览器内核开源库Chromium
**Chromium是Google的久负盛名的浏览器开源项目，作为Chrome浏览器的引擎，其设计理念强调简单、高速、稳定与安全。Chromium采用了WebKit渲染引擎和V8 JavaScript引擎，支持沙盒、黑名单、无痕浏览等功能，提供了稳定与安全的网页浏览环境。
Chromium与Chrome浏览器的关系：Chromium是Google的开源项目，而Chrome是基于Chromium维护的浏览器，添加了更多功能并进行了优化。Chromium面向的是极客、开发人员和体验新功能的用户。
Chromium的根目录下包含了多个文件夹，如Android WebView实现、Chromium浏览器代码、base模块、breakpad崩溃报告、build构建配置、cc合成器实现等。Chromium使用多进程架构，支持多种协议的网络通信，提供丰富的API接口，适合开发者深入研究。
**Chromium嵌入式框架开源库CEF
**CEF，Chromium Embedded Framework，是一个基于Chromium的开源浏览器控件，使用C++实现。它作为浏览器控件嵌入到应用程序中，允许在应用窗口中打开网页。CEF提供了稳定且丰富的API接口，支持Windows、Linux、Mac等多个平台，能与Webkit渲染引擎和HTML5特性兼容。
CEF典型应用场景包括：嵌入浏览器控件到本地应用、创建轻量级浏览器壳、离线渲染Web内容、自动化Web测试等。许多C/S架构的PC桌面程序，如QQ、PC版微信、企业微信、钉钉、飞书、迅雷、爱奇艺视频客户端、优酷视频客户端、有道词典、有道云笔记、MindMaster等，都内嵌了CEF浏览器控件。
**多协议网络传输开源库libcurl
**libcurl是一个跨平台的网络传输库，支持多种协议如ftp、ftps、mon_objc和rtc_sdk_framework_objc配置，选择性添加所需Framework文件夹代码文件。
分离工程过程中，需关注现有代码库依赖。完全分离需对头文件引用进行大量修改。分离工程旨在最小化修改，进行优化。
总结接触WebRTC代码的经验，分离OC工程虽有助于专注二次开发，但需谨慎处理现有代码库依赖问题。若需完全分离，需对源码进行大量修改。了解更多细节请参阅原文链接。
开源视频解决方案？
探索开源视频解决方案：Yangwebrtc、Licode、Janus与Mediasoup的比较</ 在构建音视频系统时，开源技术无疑提供了快速而经济的途径，然而也伴随着技术债务的可能。让我们深入剖析 Yangwebrtc、Licode、Janus-gateway 和 Mediasoup 这四大开源解决方案，以帮助你做出明智的选择。Yangwebrtc
自主研发的结晶：</Yangwebrtc 以其自定义的Webrtc/Srt/Rtmp架构而闻名，适用于教育、医疗等多元化应用场景。它的优点在于编译简单，适合中国本土生态，但谷歌Lib的问题和复杂的编译过程可能成为挑战。Licode
全面的SFU/MCU平台：</Licode 不仅提供媒体通信和用户管理等基础功能，还支持分布式部署。其亮点在于无需二次开发，社区活跃。然而，Linux支持有限，代码结构复杂，Android/iOS SDK支持有限，性能方面略逊一筹。Janus-gateway
WebRTC服务器中的明星：</Janus以其C语言编写的WebRTC服务器而著名，尤其适合Linux环境。社区交流可能局限，但其源码清晰，部署指南详细，链接如下：/meetecho/janus-gateway，部署步骤详尽。 Janus的优势在于其插件式架构，支持SIP、TextRoom和Streaming等多种插件，传输层兼容多种协议，性能卓越。然而，复杂性高和异步I/O处理机制的局限性也需留意。Mediasoup
Mediasoup，由Node.js和C++打造，专为WebRTC流媒体服务器设计。它关注底层数据传输，性能高效，WebRTC优化明显。与Janus相比，Mediasoup在实时性和效率上更胜一筹。其他选项
Medooze以其全面的功能而闻名，但C++开发的Mediasoup在性能上略优。Jitsi以其丰富的组件如Video-Bridge和活跃的社区吸引开发者，Kurento则凭借成熟的C++开发和详尽的文档吸引成熟项目。对于Go语言爱好者，pion/webrtc是个学习的好选择。决策建议
选择哪种方案，关键在于团队的技术熟悉度、项目需求、业务规模、分布式支持的考虑、二次开发的灵活性、时间限制以及社区的活跃度。务必在投入前进行彻底的测试和研究，确保选择最适合的开源视频解决方案。