1.【流媒体游戏】流媒体是源码什么意思 流媒体游戏怎么
2.FFmpeg学习(一)开篇
3.详解 WebRTC 协议原理与框架
4.每日开源：一个巨硬的产品级嵌入式流媒体库
5.udp如何实现可靠性传输？（附开源项目）
6.详解 WebRTC 协议原理与框架、WebRTC编程问题迎刃而解
【流媒体游戏】流媒体是源码什么意思 流媒体游戏怎么
流媒体是什么意思
流媒体（Streaming Media）是一种采用流式传输方式在Internet播放的媒体格式。它通过视频传送服务器将节目发送到网络上，源码用户通过解压设备进行解压，源码节目就能像发送前那样显示。源码流媒体极大地方便了人们的源码立体指标源码工作和生活，无论身处何地，源码都能享受到高质量的源码远程教育、视频点播、源码网络电台和网络视频。源码
流媒体原理
流式传输需要缓存，源码因为互联网传输是源码基于包传输的，数据包在网络中选择的源码路由可能不同，导致到达客户端的源码时间延迟不一。因此，源码缓存系统用于弥补延迟和抖动的影响，确保数据包的顺序正确，使媒体数据能够连续输出，避免播放停顿。流式传输通常使用RTP/UDP协议传输实时数据，RTSP协议交换控制信息，以提供播放、快进、快倒、暂停及录制等功能。
流媒体游戏怎么下载
虽然大多数**和音乐网站仅提供在线收看或收听，但可以通过一些技巧下载流媒体文件。首先，可以从HTML源代码中查找URL，打开网页源文件，使用记事本进行搜索，找到SWF、WMV、RM、ASF、AVI等后缀的文件即可。
其次，可以使用保存文件查找法，右键单击目标另存为，找到.m3u或.mp3文件，将.m3u改为.mp3，然后使用下载工具下载。
有时还需要查找RAM或ASX文件中的地址，用记事本打开这些文件，找到**的下载链接。
使用播放器属性查找法也很有效，例如在RealOne Player中，通过“文件→剪辑属性→查看剪辑信息”，可以看到当前播放的影音文件的地址。
最后，还可以通过右键查看播放链接的跟庄进退公式源码属性来获取下载链接，通常这些链接使用MMS或PNM等协议。
FFmpeg学习(一)开篇
为什么要学习FFmpeg？本人希望深入研究音视频领域，音视频领域内容丰富，我计划从多个方面逐步学习：FFmpeg常用功能实践、FFmpeg源码研究、OpenGL、OpenGLES、Metal、AR、WebRTC、直播架构等。
当前音视频有哪些应用场景？从众多应用场景可以看出，音视频技术至关重要，尤其在5G时代，网络传输问题得到极大提升，音视频需求将爆发式增长。以下是一个简单播放器架构图：
音频解码和视频解码一般使用FFmpeg解码，iOS8之后提供了VideoToolBox框架支持硬解码。视频渲染通常使用OpenGL直接利用GPU渲染，还有GPUImage、SDL、VLC等第三方框架。
音视频播放中的音视频同步是一项复杂的技术。学习一项技术需要高效的方法，只有不断实践才能深刻理解。学习FFmpeg也需要好的文档，以下列举一些必备的学习文档地址：
以上都是英文文档，如果英文学习困难，可以参考以下中文资料：
此外，推荐两本非常好的书籍：
相关学习资料推荐，点击下方链接免费报名，先码住不迷路~
1. FFmpeg简介：FFmpeg是一套用于记录、转换数字音频、视频并将其转化为流的开源计算机程序。采用LGPL或GPL许可证。它提供了录制、转换以及流化音视频的完整解决方案。它包含了非常先进的音频/视频编解码库libavcodec，为了保证高可移植性和编解码质量，libavcodec里很多code都是从头开发的。FFmpeg在Linux平台下开发，但也可以在其他操作系统环境中编译运行，包括Windows、Mac OS X等。这个项目最早由Fabrice Bellard发起，年至年间由Michael Niedermayer主要负责维护。许多FFmpeg的开发人员都来自MPlayer项目，当前FFmpeg也是放在MPlayer项目组的服务器上。项目的名称来自MPEG视频编码标准，前面的网页源码怎样取"FF"代表"Fast Forward"。
2. FFmpeg能做什么
3. FFmpeg架构模块组成：我们先看一张FFmpeg的架构图：
下载好的源码，我们也可以看到大致的源码结构：
3.1 libavutil
3.2 libavformat
FFmpeg是否支持某种媒体封装格式，取决于编译时是否包含了该格式的封装库。根据实际需求，可进行媒体封装格式的扩展，增加自己定制的封装格式，即在AVFormat中增加自己的封装处理模块。
3.3 libavcodec
AVCodec中实现了目前多媒体绝大多数的编解码格式，既支持编码，也支持解码。AVCodec除了支持MPEG4、AAC、MJPEG等自带的媒体编解码格式之外，还支持第三方的编解码器，如H.(AVC)编码，需要使用x编码器；H.(HEVC)编码，需要使用x编码器；MP3(mp3lame)编码，需要使用libmp3lame编码器。如果希望增加自己的编码格式或硬件编解码，则需要在AVCodec中增加相应的编解码模块。
3.4 libavfilter
3.5 libavdevice
3.6 libswscale
3.7 libpostproc
3.8 libswrressample
3.9 ffmpeg
3. ffsever
3. ffplay
4. FFmpeg安装：下载源码后，我们可以查看一下目录结构：
输入./configure --help命令查看配置信息
内容太多需要分页，输入./configure --help | more
从上面的帮助，我们可以尝试输入：./configure --list-decoders查看所有解码器
接下来我们可以尝试输入：./configure --list-encoders查看所有编码器
接下来我们可以尝试输入：./configure --list-filters查看所有滤镜器
接下来我们可以尝试输入：./configure --list-muxers查看FFmpeg的封装，封装Muxing是指将压缩后的编码封装到一个容器格式中，我们输入./configure --list-muxers来查看FFmpeg支持哪些容器格式：
从上面打印信息来看，FFmpeg支持生成裸流文件，如H.、AAC、PCM，也支持一些常见的格式，如MP3、MP4、FLV、M3U8、WEBM等。
从上面解封装又称为解复用格式的支持信息中可以看到，FFmpeg支持的demuxter非常多，包含image、MP3、FLV、MP4、MOV、AVI等。
从支持的协议列表中可以看到，FFmpeg支持的流媒体协议比较多，包括MMS、HTTP、HTTPS、HLS、eclipse 清理编译源码RTMP、RTP，甚至支持TCP、UDP，它还支持使用file协议的本地文件操作和使用concat协议支持的多个文件串流操作。
接下来我们可以尝试输入：./configure --list-parsers查看FFmpeg支持的解析器
接下来我们可以尝试输入：./configure --list-bsfs查看FFmpeg支持的字节流过滤器
接下来我们可以尝试输入：./configure --list-indevs查看有效的输入设备
接下来我们可以尝试输入：./configure --list-outdevs查看有效的输出设备
详解 WebRTC 协议原理与框架
WebRTC，全称为Web Real-Time Communication，是一个强大的实时通信API，它允许网页浏览器进行语音和视频对话，且于年由Google等公司开源并成为W3C推荐标准。WebRTC的核心在于其安全的实时传输协议（SRTP），确保数据加密、认证和完整性，实现音视频通信的可靠性。架构图展示了核心层（包括Voice Engine、Video Engine和Transport）与应用层的互动，其中Video Engine负责VP8/VP9编解码，Audio Engine处理编码、网络适配和回声消除，Transport则基于UDP协议进行高效数据传输。
WebRTC的核心功能包括音频处理（如Opus编解码、网络适配和回声消除）、视频处理（VP8/VP9编码、防抖和图像处理）、以及传输模块，它利用UDP协议提供实时、低延迟的通信。视频渲染则在应用层进行。WebRTC支持自定义开发，允许扩展API实现各种功能，如美颜、贴图等。
要使用WebRTC，开发者可以利用提供的Web API（JavaScript接口）或Native C++ API进行编程，涉及的API包括Network Stream API、RTCPeerConnection和Peer-to-peer Data API。WebRTC的架构灵活，支持P2P连接，但在NAT和防火墙环境下需要额外的ICE和STUN/TURN协议来解决连接问题。
WebRTC的协议栈涉及RTP、SETP和SCTP等协议，其中Session组件基于libjingle实现，而Transport则处理数据传输。源码结构复杂，但通过理解基本网络协议如RTP、SDP、ICE、RTCP等，可以深入学习WebRTC的实现细节。
总之，layer表格分页源码WebRTC为实时通信提供了强大的工具，开发者需要掌握基本网络协议知识，理解其架构和API，才能充分利用这一技术进行音视频应用的开发。
每日开源：一个巨硬的产品级嵌入式流媒体库
哈喽，我是老吴。
今天分享一个比较复杂的开源项目：live 是一个开源的流媒体库，用于实现实时流媒体的传输和处理。它提供了一套跨平台的 C++ 类库，帮助快速构建高效、可靠的流媒体服务器和客户端应用程序。
live的代码量庞大，约9w行代码。如果专注于核心逻辑，代码量缩减到约8K行。使用live，你可以收获高效可靠的流媒体库，了解产品级的C++项目设计，掌握音视频基础知识，甚至获得基于select()的C++事件循环库。live在媒体播放器、流媒体服务器、视频监控系统等领域应用广泛，如VLC、FFmpeg、GStreamer均使用live实现流媒体的接收和播放。
live基于C++，语法相对简单，适合专注于学习C++类设计和编写专业的C++软件。为了理解源码，需要补充多媒体、流媒体的理论知识。通过阅读和运行相关应用，加深对理论知识的理解。
编译live库后，会生成4个静态库：libBasicUsageEnvironment.a和libUsageEnvironment.a用于实现事件循环、上下文管理、任务管理等；libliveMedia.a负责多媒体流化，包括音视频编解码、流媒体协议实现；libgroupsock.a负责网络IO功能，核心是TCP、UDP的读写。简单示例是RTP传输MP3音频，涉及server和client两个程序。
server程序的核心逻辑包括准备运行环境、设置数据来源、设置数据目的地。TaskScheduler用于任务管理，基于select()实现事件循环。BasicUsageEnvironment用于上下文管理。数据流化本质是网络传输，Source和Sink分别表示数据源和目的地，本例中Source是MP3FileSource，Sink是MPEG1or2AudioRTPSink。client端程序同样初始化Source和Sink。
RTP协议简介，RTP（Real-time Transport Protocol）是一种用于实时传输音频和视频数据的网络传输协议，基于UDP，用于在IP网络上传输实时媒体数据。RTP协议设计目标是提供低延迟、高效率的传输，以满足实时应用需求。主要特点包括时间戳、序列号、负载类型、NACK反馈和RTCP（Real-time Transport Control Protocol）等。
关键问题是如何实现数据一帧帧流化？关注点不是具体音视频格式解析或特定协议实现，而是live对音视频流化的整体框架。通过示例分析，live本质上将音视频数据逐帧解码，通过RTP协议经网络发送。live封装了多种数据Source和Sink，但无需详细了解每个概念。仍以RTP传输MP3数据为例，分析live的工作流程。
首先，需要对相关类的关系有大概概念：MediaSource是所有Source的父类，各种具体音视频Source基于其派生；MediaSink是所有Sink的父类，派生出FileSink、RTPSink等众多Sink类。Sink类最关键的成员函数是startPlaying()，用于使用Source对象获取帧数据，然后发送至网络。
RTP传输MP3的主要逻辑包括准备就绪后调用MediaSink::startPlaying()启动数据流化，在packFrame()调用Source对象的getNextFrame()。getNextFrame()最终调用MP3FileSource的doGetNextFrame()，负责MP3音频解码，解码完成后，回调afterGettingFrame()，正常时调用sendPacketIfNecessary()发送数据，并添加至事件循环调度器中。一段时间后，MultiFramedRTPSink的sendNext()被调用，推动新一帧数据传输，直到Source中的所有帧数据被消费。
live如何创建RTSP服务器？通常RTP协议与RTSP协议结合使用，对外提供RTSP服务器服务。RTSP提供控制实时流媒体传输和播放的标准化方式，可以控制播放、暂停、停止、快进、后退等功能。添加几行代码即可创建RTSP服务器。RTSP服务器封装实现RTSP服务，类似HTTP协议，是文本协议。服务器包括接受客户端连接、读取客户端数据、解析和处理数据的操作。
总结，live是一个开源的多媒体流媒体库，支持常见流媒体协议，提供高效可靠的流媒体传输功能，适用于构建流媒体服务器和客户端应用程序。使用live需要熟悉C++编程和网络编程知识，官方提供丰富示例代码，帮助快速熟悉库的使用方法。
udp如何实现可靠性传输？（附开源项目）
在UDP应用中，实现可靠性传输并非其固有特性，但可以通过应用层策略来弥补。这里，我们将探讨几种方法，包括RUDP和UDT，以及如何通过源码分析实现。
首先，TCP通过重传策略确保数据的可靠性。当数据段未收到确认时，TCP会启动重传定时器，如果超时未收到确认，会根据网络情况动态调整重传时间。此外，TCP还使用窗口确认机制，通过序列号和确认号来保证数据的有序到达。
相比之下，UDP作为无连接协议，不提供这些内置机制。然而，RUDP通过引入改进的拥塞控制、重发机制和淡化服务器算法，为实时应用如音频和视频提供了增强的数据服务质量。RTP则依赖底层网络的服务，虽然不保证数据顺序，但通过序列号支持重组和位置确定。
UDT，一个建立在UDP之上的协议，通过添加拥塞控制和数据可靠性控制来实现可靠传输。UDT采用面向连接的方式，支持双向数据流，并结合了速率控制和流量控制。它通过固定包大小、定时器和报文类型来管理数据传输，确保数据的可靠接收。
一种简单的实现方法是模拟TCP确认机制：发送端发送数据并分配序列号，接收端接收数据后确认，发送端根据确认删除已发送的数据，通过定时任务检查是否需要重传未确认的数据。
在实际项目中，可以参考开源项目如github.com/caozhiyi/Hud...来深入理解UDT的实现细节。这些技术虽然复杂，但为UDP提供了在特定应用场景下的可靠性保障。
详解 WebRTC 协议原理与框架、WebRTC编程问题迎刃而解
WebRTC，全称Web Real-Time Communication，是一种允许网页浏览器进行实时语音和视频对话的API，自年由Google等公司开源并被W3C推荐后，迅速在开发者中普及。它通过SRTP加密RTP数据，确保通信的安全性。核心架构由四部分组成：Voice Engine、Video Engine、Transport以及应用层API，各自处理音频、视频、传输和扩展功能。
在架构图中，绿色部分代表WebRTC核心层，提供基础API，紫色部分是应用层，开发者可以根据需要扩展。核心层的Voice Engine包含编码解码、网络适配和回音消除等功能，Video Engine负责VP8/VP9视频编解码，以及防止视频抖动和图像处理。Transport模块则利用UDP协议实现高效、实时的数据传输，并通过计算估计网络带宽，支持非音视频数据传输。
要使用WebRTC，开发者可以利用javascript Web API或本地C++ API，开发实时通信应用。WebRTC允许基于浏览器的网络流API、RTCPeerConnection和P2P数据API构建应用，如音频视频聊天。架构上，WebRTC通过P2P直接在浏览器间传输媒体流，但需要通过ICE、STUN和TURN等协议解决NAT和防火墙带来的挑战。
WebRTC协议栈涉及RTP、SETP、SCTP等协议，Session组件基于libjingle库，而Transport层则使用了libjingle的网络和传输组件。源码结构复杂且快速变化，涉及PeerConnection、模块化设计、网络传输模块和基础网络协议理解，如RTP报头格式、RTCP报告和扩展等。
学习WebRTC需要对基本网络协议有深入理解，如RTP负载格式、RTP报头扩展以及RTCP报告间隔。资源方面，可通过书籍、示例代码和开发者社区来深入学习，如跨平台的WebRTC Demo项目。
Miracast技术详解（四）：Sink源码解析
Miracast Sink端源码最早出现在Android 4.2.2版本中，可通过android.googlesource.com查看。然而，在Android 4.3版本之后，Google移除了这部分源码，详细移除记录可在android.googlesource.com上查阅。尽管Sink端代码被移除，但Source端源码依然存在。通过使用Android手机的投射功能，仍可实现Miracast投屏发送端的功能。
为了查看源码，推荐使用Android Studio，以便利用IDE的代码提示和类/方法跳转功能。首先新建一个Native Project，将libstagefright相关源码拷贝至cpp目录，并导入必要的include头文件。在CMakeLists.txt中添加这部分源码后，同步环境，以此引用相关类与头文件，提升查看源码的效率。
Sink端核心类主要包括：WifiDisplaySink.cpp、RTPSink.cpp、TunnelRenderer.cpp。通过分析可得知，初始化操作主要在wfd.cpp中的main()方法内完成，重点关注sink->start()方法启动WifiDisplaySink，进而使用ip和端口参数执行相关操作。
RTSP通讯涉及关键步骤，包括创建RTSP TCP连接、处理连接状态与数据异步通知。当连接建立后，开始进行RTSP协商与会话建立，处理RTSP M1-M7指令。请求与响应流程需参考前面的RTSP协议分析文章，这里不详细展开。
处理RTSP消息时，首先判断消息类型，是Request还是Response。对于Request，主要处理Source端M1请求，并响应M2确认。对于Source端M3请求，处理相关属性及能力，如RTP端口号、支持的音频和视频编解码格式等。M4与M5请求则分别进行常规的响应处理。
在发送完Setup M6请求后，注册onReceiveSetupResponse()回调，用于完成RTSP最后一步，即发送PLAY M7请求。此时，Source端会按照Sink指定的UDP端口发送RTP数据包，包含音视频数据。
RTSP协商与会话建立完成后，数据流通过RTPSink处理，建立UDP连接并解析RTP数据包。在TunnelRenderer中接收并播放音视频流。流程包括消息处理、环境初始化、TS包解析、音视频裸流解码与播放等。
源码解析过程中，关键步骤包括初始化RTPSink、建立UDP连接、处理RTP与RTCP数据、解析TS包并获取音视频裸流等。移植Native Sink端难点在于隔离与处理Native相关依赖，如异步消息机制、网络连接实现等。建议在应用层实现RTSP连接、音视频解码与渲染功能，然后移植底层解析代码，以减少依赖，提高移植效率。
