不吃鱼的猫748-CSDN博客

原创【音视频流媒体进阶：从网络到 WebRTC】第22篇-实战：超低延迟直播方案

延迟 < 500ms（连麦互动、实时竞拍）：WebRTC（WHIP/WHEP），端到端全链路 WebRTC，推流端使用编码，播放端最小化 Jitter Buffer。延迟 500ms~2s（直播带货、在线教育）：SRT 推流 + WebRTC 或 HTTP-FLV 播放。第一公里用 SRT 保证弱网稳定性，最后一公里根据规模选择 WebRTC（小规模高互动）或 HTTP-FLV（中规模低成本）。延迟 2~5s（常规直播）：RTMP 推流 + HTTP-FLV 播放，成熟方案，成本最低。

2026-04-15 21:47:32 86

原创【音视频流媒体进阶：从网络到 WebRTC】第21篇-实战：多人视频会议系统

Janus 是由 Meetecho 开发的开源 WebRTC 服务器，采用 C 语言编写，核心设计理念是可插拔的插件体系。Janus 的核心引擎只负责 WebRTC 协议栈的处理（ICE、DTLS、SRTP），所有业务逻辑都由插件实现。这种设计带来了极大的灵活性——你可以只加载需要的插件，也可以开发自定义插件来实现特定的业务逻辑。架构选型：Mesh、MCU、SFU 三种架构各有适用场景，SFU 凭借低服务器开销和高灵活性成为当前主流SFU 核心机制。

2026-04-15 21:46:54 105

原创【音视频流媒体进阶：从网络到 WebRTC】第20篇-实战：构建一套完整的直播系统

SRS（Simple Realtime Server）是一个开源的流媒体服务器，由国人开发，在国内直播行业有着广泛的应用。协议覆盖全：支持 RTMP、HLS、HTTP-FLV、WebRTC（WHIP/WHEP）、SRT、GB28181高性能：单进程异步架构，单核可承载数千路并发易部署：提供官方 Docker 镜像，一条命令即可启动配置简洁：配置文件语法清晰，功能模块化架构层面：理解了推流端 → 流媒体服务器 → CDN → 播放端的端到端数据流，以及各环节的协议选型依据单节点。

2026-04-12 11:14:06 96

原创【音视频流媒体进阶：从网络到 WebRTC】第19篇-libwebrtc 实战：构建 P2P 音视频通话

本文从 libwebrtc 的编译开始，逐步介绍了 Native API 的核心接口、线程模型，并通过完整的代码示例演示了如何构建一个 1v1 音视频通话程序。第 15 篇：WebRTC 协议栈全景、信令设计与 WebSocket 信令服务器实现第 16 篇：ICE/STUN/TURN 的 NAT 穿越原理与 coturn 部署第 17 篇：DTLS-SRTP 的安全传输机制与密钥协商流程第 18 篇：GCC 和 BBR 拥塞控制算法在 WebRTC 中的应用第 19 篇（本文）

2026-04-12 11:13:33 83

原创【音视频流媒体进阶：从网络到 WebRTC】第18篇-WebRTC 拥塞控制：GCC 与 BBR

实时通信不能复用 TCP 的拥塞控制，因为它对延迟敏感、不能依赖重传、需要快速响应网络变化GCC 是 WebRTC 的默认拥塞控制算法，核心思想是通过观察单向延迟梯度，在拥塞发生前预警并降低码率。它由到达时间模型、卡尔曼滤波器、自适应阈值过载检测器和 AIMD 速率控制器四部分组成TWCC 取代了 REMB，将带宽估计逻辑从接收端移到发送端，提供逐包粒度的到达时间反馈GCC 结合延迟估计和丢包估计，取两者的较小值作为最终码率目标，确保在各种网络环境下的鲁棒性BBR 在实时通信中仍处于探索阶段。

2026-04-12 11:12:54 57

原创【音视频流媒体进阶：从网络到 WebRTC】第17篇-DTLS-SRTP：WebRTC 的安全传输

本文从 WebRTC 的安全需求出发，完整剖析了 DTLS-SRTP 的工作机制。WebRTC 强制加密所有媒体传输，DTLS-SRTP 是实现这一安全模型的基石DTLS 是 TLS 在 UDP 上的适配，通过重传定时器、消息分片和 Cookie 验证解决了不可靠传输带来的问题DTLS 握手流程与 TLS 1.2 逻辑一致，通过和信令通道的 TLS 保护构建信任链SRTP 保留 RTP 头部明文，加密 payload，并附加认证标签，使用 AES-128-CM 加密和 HMAC-SHA1 完整性保护。

2026-04-12 11:12:11 73

原创【音视频流媒体进阶：从网络到 WebRTC】第16篇-ICE／STUN／TURN：NAT 穿越全攻略

本文从 NAT 的分类讲起，系统地介绍了 WebRTC 中 NAT 穿越的完整方案。NAT 有四种类型，从完全锥形到对称型依次收紧。对称型 NAT 是 P2P 穿越的最大障碍STUN是轻量级协议，帮助客户端发现公网映射地址，但对对称型 NAT 无效TURN是最后的中继方案，能保证 100% 的连通性，但代价是额外的延迟和带宽ICE 框架整合 STUN 和 TURN，通过候选收集、优先级排序和连通性检查，系统化地找到最优传输路径通过边收集边发送候选来加速建连生产环境中，coturn。

2026-04-12 11:11:38 77

原创【音视频流媒体进阶：从网络到 WebRTC】第15篇-WebRTC 整体架构与信令设计

WebRTC 标准故意不定义信令协议。它只规定了 SDP 的格式和 ICE 候选的结构，但"怎么把这些数据从 A 传给 B"完全由开发者自己决定。这既是自由，也是负担。自由在于你可以用任何现有的通信机制来实现信令；负担在于你必须自己设计和实现这套系统。本文作为 WebRTC 系列的开篇，从全局视角勾勒了 WebRTC 的技术全貌。协议栈分层。

2026-04-12 11:11:00 65

原创【音视频流媒体进阶：从网络到 WebRTC】第14篇-QUIC／HTTP3 在流媒体中的应用

QUIC 不仅仅是"更快的 TCP"，它是传输层协议的一次范式转移。QUIC 的核心特性——0-RTT 连接建立、消除队头阻塞、连接迁移、内置加密——每一项都精准命中了流媒体传输的痛点HTTP/3让 HLS/DASH 无需修改应用逻辑即可获得更快的首帧加载、更好的弱网表现和真正的并行下载在流媒体场景中优势明显，但 UDP 限制、CPU 开销和调试工具链仍是需要面对的挑战MoQ 协议代表了下一代流媒体传输的方向——基于 QUIC 的 Pub/Sub 模型，有望统一低延迟和大规模分发实践层面。

2026-04-12 11:10:11 95

原创【音视频流媒体进阶：从网络到 WebRTC】第13篇-SRT 协议与低延迟传输

可靠传输：在 UDP 之上通过 ARQ 重传保证数据完整性。与 TCP 不同，SRT 的重传是有时间限制的——超过延迟窗口的丢包直接放弃，避免了 TCP 那种"不惜一切代价重传"导致的延迟累积。低延迟：用户可以通过 latency 参数精确控制端到端延迟。SRT 在这个时间窗口内尽最大努力恢复丢包，但绝不超时等待。这种"有限度的可靠性"正是实时传输所需要的。安全性：原生支持 AES-128/AES-192/AES-256 加密，密钥通过握手过程安全交换。在公网传输敏感的广电信号时，加密是刚需而非可选项。

2026-04-12 11:09:35 47

原创【音视频流媒体进阶：从网络到 WebRTC】第12篇-DASH 协议与自适应码率

DASH 的核心思想与 HLS 一致：将媒体内容切分为一系列短小的片段（Segment），通过标准的 HTTP 协议分发，客户端根据网络状况动态选择合适码率的片段进行播放。内容准备：将源媒体编码为多个码率版本，切分为 Segment 文件，并生成 MPD 描述文件内容分发：将 MPD 和 Segment 文件部署到标准的 HTTP 服务器或 CDN 上客户端播放：DASH 客户端下载 MPD，解析可用的码率和片段信息，通过 ABR 算法选择合适码率的 Segment 逐个下载、解码、渲染。

2026-04-12 11:08:53 73

原创【音视频流媒体进阶：从网络到 WebRTC】第11篇-HLS 协议原理与实践

Server（服务端）：编码器将音视频编码后，按固定时长切分为 TS 媒体切片，同时生成/更新 M3U8 播放列表文件CDN（分发网络）：标准的 HTTP CDN，负责缓存和分发 M3U8 文件与 TS 切片Client（播放器）：定时拉取 M3U8 文件获取切片列表，按顺序下载 TS 切片并解码播放HLS 的媒体切片采用 MPEG-2 Transport Stream（TS）格式。TS 最早为数字电视广播设计，其核心特点是188 字节的固定长度包。同步字节（1 byte）：固定为0x47头部标志。

2026-04-12 11:08:18 99

原创【音视频流媒体进阶：从网络到 WebRTC】第10篇-FLV 封装与 RTMP 直播实践

本文从 FLV 的二进制格式出发，逐层拆解了 Header、Tag、Audio/Video Tag Data 的结构，然后揭示了 RTMP 与 FLV 之间近乎一一对应的关系。FLV 格式简单而紧凑，线性的 Tag 链结构天然适合流式传输RTMP Message 的 payload 就是 FLV Tag Data，两者互转几乎零成本首帧三件套（Metadata + Video SeqHeader + Audio SeqHeader）是正确播放的前提HTTP-FLV。

2026-04-11 21:01:58 56

原创【音视频流媒体进阶：从网络到 WebRTC】第09篇-RTMP 协议深度剖析

RTMP（Real-Time Messaging Protocol）由 Macromedia 公司开发，2005 年 Adobe 收购 Macromedia 后接管了该协议。2012 年 Adobe 公开了 RTMP 规范（但并非完全开放，某些扩展如 RTMPE 仍为私有）。RTMP 的设计初衷是为 Flash Player 提供低延迟的音视频传输能力，后来逐渐演变为直播推流的事实标准。时至今日，RTMP 推流 + HTTP-FLV/HLS 拉流仍然是国内直播行业最主流的技术方案。

2026-04-11 21:01:26 58

原创【音视频流媒体进阶：从网络到 WebRTC】第08篇-RTSP 协议详解与 live555 实战

RTSP 定义在 RFC 2326（1998 年发布，后由 RFC 7826 更新为 RTSP 2.0），它是一个应用层信令控制协议，运行在 TCP 之上（默认端口 554）。RTSP 的职责是建立和控制媒体会话，而不是传输媒体数据本身。RTSP：信令控制（DESCRIBE、SETUP、PLAY、TEARDOWN 等）SDP：媒体描述（编码格式、采样率、RTP payload type 等）RTP：媒体数据传输（音频帧、视频帧）RTCP：传输质量反馈（丢包率、抖动、SR/RR 报告）

2026-04-11 21:00:50 103

原创【音视频流媒体进阶：从网络到 WebRTC】第07篇-抖动缓冲与前向纠错

网络抖动（jitter）是指数据包到达时间间隔的变化。如果发送端以固定间隔 T 发出数据包，在理想网络中接收端也应以间隔 T 收到。但实际上，每个包经历的网络路径延迟不同，导致到达间隔产生波动。这种波动就是抖动。包序号发送时间 (ms)到达时间 (ms)到达间隔 (ms)偏差 (ms)1010022011818-234014527+746015813-758020244+24。

2026-04-11 21:00:16 73

原创【音视频流媒体进阶：从网络到 WebRTC】第06篇-SDP 与媒体协商机制

SDP（Session Description Protocol，会话描述协议）定义在RFC 8866（前身为 RFC 4566）中。它是一种纯文本格式会话的元信息（名称、发起者、时间等）媒体流的类型（音频、视频、应用数据）编解码器的能力（支持哪些 codec、参数如何）网络传输参数（IP 地址、端口号、传输协议）SDP 不是传输协议。它不负责数据的发送和接收，也没有请求-响应的交互语义。SDP 只是一种"描述格式"——就像一张菜单，列出了餐厅提供的所有菜品，但菜单本身不负责上菜。

2026-04-11 20:59:41 87

原创【音视频流媒体进阶：从网络到 WebRTC】第05篇-RTP／RTCP 协议深度解析

RTP 定义在 RFC 3550 中，从协议分层的角度看，它是一个应用层协议，通常运行在 UDP 之上。之所以选择 UDP 而非 TCP，核心原因是实时性——TCP 的重传机制会引入不可控的延迟，对于实时音视频来说，一帧迟到的数据不如一帧丢掉的数据。│ 应用层（编解码器） ││ UDP ││ IP ││ 链路层 │一个常见的约定是：RTP 使用偶数端口，RTCP 使用紧邻的奇数端口。比如 RTP 端口是 5004，那么 RTCP 端口就是 5005。

2026-04-11 20:59:10 51

原创【音视频流媒体进阶：从网络到 WebRTC】第04篇-流媒体场景下的网络优化

Socket 选项调优是最直接的手段，、缓冲区大小、保活参数是流媒体服务的基本配置零拷贝技术sendfilesplicemmap）在文件点播和代理转发场景中能显著降低 CPU 开销带宽估计与拥塞感知是自适应码率的基础，应用层需要主动监控网络状态并配合编码器调整策略抓包分析是定位网络问题的终极武器，tcpdump+ Wireshark 的组合应该成为每个流媒体开发者的必备技能系统级调优需要从文件描述符、TCP 内核参数到应用层缓冲区管理全面考虑至此，第一篇「网络编程基础」的四篇文章就全部完成了。

2026-04-11 20:58:07 84

原创【音视频流媒体进阶：从网络到 WebRTC】第03篇-Reactor 模式与事件驱动网络框架

说完 Reactor，有必要提一下它的"对手"——Proactor 模式。两者的核心区别在于谁来执行实际的 I/O 操作ReactorProactorI/O 操作应用程序自己执行（read/write）操作系统/框架代为执行通知时机通知"fd 就绪，你可以读了"通知"数据已经读好了，给你"编程模型同步非阻塞 I/O异步 I/O典型实现用一个生活类比：Reactor 像是餐厅告诉你"你的菜好了，自己来端"；Proactor 像是服务员直接把菜端到你桌上。

2026-04-11 20:56:58 63

原创【音视频流媒体进阶：从网络到 WebRTC】第02篇-I／O 多路复用：从 select 到 epoll

io_uring是 Linux 5.1（2019）引入的新一代异步 I/O 框架，由 Jens Axboe 设计。如果说 epoll 是"通知你 fd 就绪，你自己去读写"，那 io_uring 就是"你提交读写请求，内核帮你完成后通知你"——这才是真正的异步 I/O。select：最古老、最通用，但 1024 fd 限制和 O(n) 遍历使其不适合高并发。poll：去掉了 fd 数量限制，但 O(n) 开销依旧。epoll。

2026-04-11 20:55:57 53

原创【音视频流媒体进阶：从网络到 WebRTC】第01篇-Socket 编程基础：TCP 与 UDP 的选择

Socket 最早由 BSD Unix 在 1983 年引入，至今仍是几乎所有操作系统网络编程的标准接口。它的核心思想是将网络通信抽象为类似文件 I/O 的操作——创建一个"端点"（socket），然后通过这个端点读写数据。协议、本地地址、本地端口、远端地址、远端端口。本文从 Socket 编程模型出发，分别介绍了 TCP 和 UDP 两种传输协议的编程实践。Socket是网络编程的基础抽象，理解它的 API 和行为是构建流媒体系统的前提TCP。

2026-04-11 20:54:18 57

原创 Janus WebRTC Gateway -- 从零搭建完整指南

Janus是由 Meetecho 开发的开源WebRTC 服务器（Gateway）。它本身不提供具体的音视频业务逻辑，而是充当一个通用的 WebRTC 信令和媒体中转框架，通过插件多人视频会议（VideoRoom，SFU 模式）一对一视频通话（VideoCall）流媒体分发（Streaming）音频混音会议（AudioBridge，MCU 模式）SIP 网关（对接传统电话网络）录制与回放（RecordPlay）C 语言编写，性能优秀，资源占用低插件架构灵活，可只加载需要的功能。

2026-04-10 14:05:01 533

原创【从零开始学 OpenGL：现代图形渲染实战】第10篇-综合实战项目

篇章知识点代码产出第1篇环境搭建、OpenGL 上下文窗口程序第2篇渲染管线、VBO/VAO/EBO彩色三角形第3篇Shader 工具类第4篇纹理映射、多纹理混合纹理矩形第5篇MVP 矩阵、深度测试3D 旋转立方体第6篇摄像机系统Camera 工具类第7篇Phong 光照、多光源光照场景第8篇Assimp 模型加载Mesh/Model 类第9篇FBO、天空盒、阴影进阶渲染场景第10篇综合整合完整 3D Demo。

2026-03-14 20:39:16 53

原创【从零开始学 OpenGL：现代图形渲染实战】第09篇-进阶渲染技术

到目前为止，我们所有的绘制操作都直接输出到默认帧缓冲（由 GLFW 创建的窗口自带），即屏幕上可见的画面。但 OpenGL 允许我们创建自定义帧缓冲，将渲染结果输出到一张纹理上，而非直接显示在屏幕上 —— 这就是离屏渲染。离屏渲染是实现后处理效果的基础：先将场景渲染到纹理上，然后对这张纹理做各种图像处理，最后才输出到屏幕。立方体贴图（Cubemap）是一种特殊纹理，由 6 张图片组成，分别对应立方体的 6 个面。采样时使用一个3D 方向向量而非 2D 坐标。OpenGL 枚举面右左上下前后。

2026-03-14 20:38:38 72

原创【从零开始学 OpenGL：现代图形渲染实战】第08篇-模型加载

Assimp（Open Asset Import Library）是一个开源的模型导入库，支持 40+ 种 3D 格式。无论输入什么格式，都转换为统一的数据结构。

2026-03-14 20:37:52 69

原创【从零开始学 OpenGL：现代图形渲染实战】第07篇-基础光照

法向量（Normal Vector）是垂直于表面的单位向量，它决定了表面如何与光线交互。对于立方体，每个面的法向量指向面的外侧。-0.5f, -0.5f, -0.5f, 0.0f, 0.0f, -1.0f, // 后面// ...顶点属性布局变为位置(3) + 法线(3) = stride 6// 位置属性 (location = 0)// 法线属性 (location = 1)添加键盘按键（如 1-4）来切换不同的预设材质（黄金、翡翠、白色塑料、红色橡胶）。

2026-03-14 20:37:09 65

原创【从零开始学 OpenGL：现代图形渲染实战】第06篇-摄像机系统

欧拉角（Euler Angles）角度英文含义旋转轴范围偏航角Yaw水平转头（左右看）Y 轴无限制（通常 0°~360°）俯仰角Pitch垂直点头（上下看）X 轴限制在 -89°~89°我们不使用第三个欧拉角Roll（翻滚），因为 FPS 摄像机不需要歪头。

2026-03-14 20:36:21 76

原创【从零开始学 OpenGL：现代图形渲染实战】第05篇-坐标系统与3D变换

注意矩阵乘法的顺序是从右往左读的：先 Model → 再 View → 最后 Projection。

2026-03-14 20:35:44 97

原创【从零开始学 OpenGL：现代图形渲染实战】第04篇-纹理映射

但在真实的 3D 应用中，要让物体表面呈现丰富的细节（木纹、砖墙、皮肤），逐顶点指定颜色是不现实的。每个顶点有 8 个 float（3 位置 + 3 颜色 + 2 纹理坐标），纹理坐标从第 6 个 float 开始，占 2 个分量。为了把一张 2D 图片"贴"到 3D 几何体上，我们需要告诉 GPU：几何体表面的每个点对应图片的哪个位置。与第2篇、第3篇的区别在于，每个顶点多了 2 个 float 的纹理坐标。是默认激活的纹理单元。，实时观察两种过滤方式的差异（在纹理被放大时差异最明显）。

2026-03-14 20:34:51 53

原创【从零开始学 OpenGL：现代图形渲染实战】第03篇-深入着色器与GLSL

修改顶点数据，将三角形上下翻转（顶点在下方，底边在上方），并将三个顶点颜色改为你喜欢的配色方案（例如 cyan/magenta/yellow）。

2026-03-14 20:33:57 150

原创【从零开始学 OpenGL：现代图形渲染实战】第02篇-渲染管线与第一个三角形

光栅化就是将数学描述的几何图形转换为屏幕上的像素点阵的过程，类比一下，就像把矢量图转换为位图——把"用公式描述的三角形"变成"由一个个像素点填充的三角形"。：如果三角形三个顶点有不同颜色，光栅化阶段会自动进行线性插值，使得三角形内部呈现平滑的颜色渐变。绘制矩形需要两个三角形（6个顶点），但矩形只有4个顶点，其中有2个顶点被共用了。每个片段对应屏幕上一个潜在的像素位置，并携带经过插值的属性（颜色、纹理坐标等）。三角形的三个顶点分别为红、绿、蓝色，光栅化阶段的插值会产生平滑的彩色渐变效果。

2026-03-14 20:33:00 88

原创【从零开始学 OpenGL：现代图形渲染实战】第01篇-环境搭建与第一个窗口

你可以理解为 OpenGL 的工作空间，所有的绑定状态和设置都关联到这个上下文。只有当某个线程拥有一个活动的上下文时，才能调用 OpenGL 函数。

2026-03-14 20:32:17 82

原创 SDP 协议详解

维度SDPJSON诞生时间19982001（标准化 2006）体积紧凑，约小一半较大（键名、引号、括号的开销）解析复杂度逐行解析，极简递归解析，需处理嵌套可读性需要查 RFC 才能理解每行自描述，键名即含义可扩展性通过a=行扩展天然支持嵌套和新字段生态兼容所有电信设备支持需要全部替换。

2026-03-13 17:49:14 371

原创【ffplay 源码解析系列】06-视频渲染与显示

视频渲染是 ffplay 播放管线中的最后一环——将解码后的AVFrame转化为屏幕上可见的画面。从 FrameQueue 获取待显示帧获取当前应该显示的帧像素格式映射：将 FFmpeg 的映射到 SDL 纹理格式纹理管理：检测尺寸/格式变化，按需重建 SDL 纹理纹理上传：将帧数据写入 GPU 纹理（区分 YUV 和 RGB 路径）宽高比计算：考虑 SAR 计算正确的显示矩形最终渲染：调用将纹理绘制到窗口事件循环 refresh_loop_wait_event()v。

2026-02-18 14:49:01 137

原创【ffplay 源码解析系列】11-事件处理与用户交互

至此，ffplay 源码解析系列全部完成。篇目主题核心内容第一篇整体架构与启动流程多线程架构、main() 初始化、stream_open()第二篇核心数据结构第三篇解复用线程read_thread、av_read_frame、数据包分发第四篇解码核心机制三个解码线程、avcodec 新旧 API第五篇音频输出与处理SDL 回调、audio_decode_frame、重采样第六篇视频渲染与显示video_refresh、帧调度、SDL 纹理渲染第七篇字幕处理与渲染。

2026-02-17 17:44:11 45

原创【ffplay 源码解析系列】10-AVFilter滤镜系统

用户通过-vf# 缩放到 1280x720 并顺时针旋转 90 度 ffplay video.mp4 -vf "scale=1280:720,transpose=1" # 水平翻转 + 添加文字水印 ffplay video.mp4 -vf "hflip,drawtext=text='Hello':fontsize=24:x=10:y=10" # 使用外挂字幕 ffplay video.mp4 -vf "subtitles=sub.srt"-vf参数通过return ret;if (!

2026-02-17 17:43:35 44

原创【ffplay 源码解析系列】09-音视频同步机制

音视频同步是 ffplay 最精妙的部分。它用不到 200 行核心代码（的同步部分 +），实现了一个鲁棒、高效的同步引擎。选定基准：默认以音频为主时钟（人耳敏感）持续追踪：通过pts_drift机制让时钟自由运行，只在关键节点更新动态调整：根据偏差大小，在"正常/加速/减速/丢帧"之间平滑切换双重保险：Early Drop + Late Drop 确保视频不会严重落后理解了这套机制，你就掌握了播放器最核心的技术。后续的滤镜系统、快进快退等功能都建立在这套同步体系之上。

2026-02-17 17:43:05 54

原创【ffplay 源码解析系列】08-音频可视化-波形与频谱显示

2026-02-17 17:42:31 212

原创【ffplay 源码解析系列】07-字幕处理与渲染

在多媒体领域，字幕大致分为两大类：Bitmap 字幕以图像形式存储，每条字幕实际上是一张带透明通道的小图片。常见格式包括：这类字幕的特点是：解码后直接得到像素数据（），渲染时只需做像素格式转换再叠加到视频帧上。Text 字幕以文本形式存储，需要经过文字排版和渲染才能变成可显示的图像：ffplay 内置只支持 bitmap 字幕的直接渲染。在中有一个关键判断：这里对应，对应。对于 text 字幕，ffplay 需要借助 libavfilter 中的 subtitles 滤镜进行处理，通过命令行

2026-02-17 17:41:58 41

opengl系列教程源码

【从零手写播放器：FFmpeg 音视频开发实战】 专栏教程配套代码

2017_Book_RoboticsVisionAndControl

YUMI机器人的产品手册

用户管理系统.rar

数据结构与算法 Python语言描述_裘宗燕.pdf

空空如也

【从零手写播放器：FFmpeg 音视频开发实战】专栏教程配套代码