一机通吃四种码流：MEDAI V2 拉流兼容 RTMP / RTSP / M3U8 / FLV 全解析一机通吃四种码流：

一机通吃四种码流：MEDAI V2 拉流兼容 RTMP / RTSP / M3U8 / FLV 全解析

标签：RTMP RTSP HLS HTTP-FLV 多协议拉流 MEDAI V2

现场做直播最尴尬的情况之一：手里有一台编码器，却发现对方给过来的流地址打不开——监控摄像头给的是 rtsp://，平台回传的是 rtmp://，网页源是 http://xxx.m3u8，CDN 边缘节点又是 http://xxx.flv。格式不兼容，就得临时加一台转码服务器、再串一个网关软件，链路越长越容易出问题。

本文从四种主流码流格式的技术原理讲起，拆解它们的封装方式、传输机制与地址结构，并结合 MEDAI V2 的双路网络拉流能力，演示"什么格式都拉得进来、拉进来还能加工、加工完再分发出去"的完整实战。

一、为什么拉流端必须"什么格式都能吃"

1.1 现实世界里，信号源从来不是单一格式

信号来源	常见给出格式	协议前缀
直播平台 / 云端服务器回传	RTMP	`rtmp://`
安防监控摄像头、NVR、医疗示教设备	RTSP	`rtsp://`
网页分发源、移动端分发源、CDN 回源	HLS	`http://...m3u8`
CDN 边缘低延迟分发、网页直播源	HTTP-FLV	`http://....flv`

一场大型活动里四种格式同时出现的场景并不罕见：主会场摄像机走 RTMP 回传、场外监控走 RTSP、领导手机端观看走 HLS、大屏网页预览走 HTTP-FLV。

1.2 格式不兼容的真实代价

很多团队遇到格式不兼容，第一反应是"加个转码服务器"。这个方案能跑通，但代价明确：

延迟叠加：每多一次转封装/转码，链路延迟增加 1~3 秒甚至更多；
画质损失：重新编码必然带来一代画质损失，纯转封装虽无损但仍有缓冲开销；
故障点翻倍：服务器进程崩溃、端口不通、进程假死——每个中间节点都是新的风险点；
现场成本：多一台设备就要多一个电源、多一根网线、多一个人盯。

1.3 理想链路：拉得进、加工得了、出得去

对一台现场编码设备而言，完整能力应该是三段式：

拉得进：不挑格式，RTMP/RTSP/HLS/HTTP-FLV 都能作为输入源接进来；
加工得了：接入后能切换、能叠加、能抠像，而不是只能"透传"；
出得去：加工后的信号能以任意协议再分发出去（本地服务 + 多路推流）。

这也是本文后面要展示的 MEDAI V2 完整链路。

二、四种码流格式技术拆解

2.1 RTMP：直播行业的通用语

RTMP（Real-Time Messaging Protocol）基于 TCP 长连接（默认端口 1935），把音视频消息切分成 Chunk 流式发送：每个 Chunk 携带 Message Header（含时间戳、消息长度、类型 ID），视频数据 Type ID 为 9、音频为 8。握手（C0/C1/C2 与 S0/S1/S2）完成后，客户端通过 AMF 命令 connect → createStream → play / publish 建立会话。

延迟：1~3 秒；
优势：生态最完整，几乎所有直播平台、所有服务器软件（SRS、Nginx-RTMP）都支持；
短板：基于 TCP，弱网丢包时重传会累积延迟。

2.2 RTSP：控制面与数据面分离

RTSP（Real-Time Streaming Protocol，默认端口 554）是一个控制协议，它本身不传输媒体数据，而是像遥控器一样控制底层的 RTP 流：

OPTIONS — 询问服务器支持的方法；
DESCRIBE — 获取 SDP 描述，里面写明有几路媒体、编码格式、RTP 端口、负载类型；
SETUP — 为每一路媒体（视频/音频）建立传输通道，确定用 UDP 还是 TCP；
PLAY — 开始传输；
TEARDOWN — 结束会话。

数据面由 RTP（承载音视频载荷，带时间戳与序号）与 RTCP（统计丢包、抖动，用于同步与质量控制）组成：

UDP 承载：延迟最低（可到 200~500ms），但丢包会导致花屏；
TCP 承载（interleaved 模式）：RTP 包复用在 RTSP 的 TCP 连接上，穿透性强，适合跨网段、跨防火墙场景。

工程提示：拉 RTSP 时能选 TCP 模式就优先选 TCP——公网/跨网段环境下 UDP 经常被防火墙拦截，症状是"DESCRIBE 成功但画面始终黑屏"。

2.3 HLS / M3U8：把流切成文件下载

HLS（HTTP Live Streaming）是苹果提出的方案，思路非常"Web 化"：服务器把直播流切成一个个小分片（TS 或 fMP4），客户端不断下载一个 m3u8 索引文件 得知"现在该下载第几片"。

一个直播 m3u8 文件的典型结构：

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:1201
#EXTINF:6.000,
stream1201.ts
#EXTINF:6.000,
stream1202.ts
#EXTINF:6.000,
stream1203.ts

关键字段含义：

字段	含义
`#EXT-X-TARGETDURATION`	单个分片的最大时长（秒），决定分片粒度
`#EXT-X-MEDIA-SEQUENCE`	当前播放列表中第一个分片的序号
`#EXTINF`	该分片的实际时长
末尾无 `#EXT-X-ENDLIST`	表示这是直播流，列表会持续滑动更新

延迟：10~30 秒（受分片时长与客户端缓冲片数影响）；
优势：走标准 HTTP，任何浏览器、手机、CDN 天然支持，穿透性最好；
注意点：m3u8 是文本索引，不是流本身——复制地址时要复制完整的 http://.../xxx.m3u8，只复制域名是拉不到流的。

2.4 HTTP-FLV：长连接上的流式封装

HTTP-FLV 把 FLV 封装的音视频直接挂在一条 HTTP 长连接上持续下发：FLV 文件由 Header + 一串 Tag 组成（script tag 放元数据、audio tag 放音频、video tag 放视频），服务端边生成边用 chunked 方式推送，客户端边收边播。

延迟：1~3 秒，与 RTMP 相当；
优势：基于 HTTP，可穿透防火墙、可接入 CDN；配合 flv.js（MSE 方案）无需 Flash 即可在浏览器播放；
典型场景：国内直播平台网页端、设备网页预览。MEDAI V2 推流后的网页实时预览，正是基于 HTTP-FLV 实现的。

2.5 四种格式横向对比

请添加图片描述

维度	RTMP	RTSP	HLS（M3U8）	HTTP-FLV
封装	RTMP Chunk	RTP 包	TS / fMP4 分片	FLV Tag
传输层	TCP	TCP 控制 + UDP/TCP 数据	HTTP	HTTP
默认端口	1935	554	80 / 443	80 / 443
典型延迟	1~3s	200~500ms	10~30s	1~3s
防火墙穿透	一般	UDP 模式差，TCP 模式好	最好	很好
终端兼容	需专用播放器	监控生态/播放器	全终端浏览器	浏览器（flv.js）
典型来源	直播平台、编码器	IPC、NVR、示教设备	CDN 分发、移动端	CDN 边缘、网页源

2.6 地址格式速查

RTMP      rtmp://192.168.5.101:1935/live/stream0
RTSP      rtsp://192.168.5.101:554/live/stream0
HLS       http://192.168.5.101:8080/live/stream0/hls.m3u8
HTTP-FLV  http://192.168.5.101:8080/live/stream0.live.flv

格式	必看要点
RTMP	应用名（app）与流名（stream）都要对，端口常被省略为默认 1935
RTSP	部分厂商地址带用户名密码：`rtsp://user:pass@ip:554/...`；跨网段优先 TCP 模式
HLS	必须以 `.m3u8` 结尾；只填域名或只到目录会拉不到
HTTP-FLV	以 `.flv` 结尾；需要服务端支持长连接推送

三、MEDAI V2 多格式拉流实战

MEDAI V2 提供 NET1 / NET2 两路网络拉流输入，可以把远端任意格式的网络流接入设备作为信号源。下面按实际操作流程演示。

3.1 拉流配置页面总览

进入 网络配置 → 拉流配置 页面，即可看到网络输入（NET1）、拉流解密与 RTMP 输入（NET2）三个区域，底部是两路网络流的预监画面：

请添加图片描述

网络输入（NET1）：配置第一路网络拉流地址；
拉流解密：拉取加密流时填写 6 位验证码；
RTMP输入（NET2）：配置第二路网络拉流地址。

3.2 NET1：四种地址都能填

在 NET1 的地址栏中直接粘贴目标流地址，打开开关即开始拉流：

请添加图片描述

四种格式均可填入（示例）：

rtmp://192.168.5.101/live/stream0            # RTMP 直播流
rtsp://192.168.1.64:554/stream1              # RTSP 监控流
http://cdn.example.com/live/room01.m3u8      # HLS 分发源
http://cdn.example.com/live/room01.flv       # HTTP-FLV 分发源

填写建议：地址必须与推流端/源站给出的完全一致，包括应用名、流名、端口与扩展名。首次接入建议先用 VLC 验证该地址可播，再填入设备，可以少走很多弯路。

3.3 NET2：RTMP输入通道

页面下方的"RTMP输入"区域用于配置 NET2 网络输入源，操作方式与 NET1 相同：

请添加图片描述

NET1 与 NET2 是两路完全独立、可同时在线的拉流通道——这意味着可以同时接入两种不同格式的信号源，例如 NET1 拉 RTSP 监控流、NET2 拉 RTMP 回传流，随时切换，互为备份。

3.4 加密流的拉流解密

若源端启用了推流加密（源端点击"生成验证码"获得 6 位验证码），拉流端必须在"拉流解密"栏输入该验证码并启用解密，才能正常拉取——视频与声音均加密传输，未解密的播放器（如 VLC）只能看到花屏或黑屏：

请添加图片描述

注意：目前设备仅支持一路拉流解密，验证码需从推流端的推流加密功能中获取。

3.5 预监与播放器验证

拉流成功后，页面底部预监状态区实时显示两路网络流解码后的画面，这是判断"格式是否被正确识别、画面是否正常"的第一手依据：

请添加图片描述

也可以用 VLC、PotPlayer 等播放器打开"网络串流"验证同一路地址，与设备预监互相印证：

请添加图片描述

判读方法：

预监有画面且流畅 → 格式识别正确、链路正常；
预监黑屏但地址在播放器里能播 → 优先查地址是否被改写（如 HLS 少了 .m3u8 后缀）；
预监卡在最后一帧 → 源端断流或网络中断，重新开关拉流即可。

四、拉进来之后：加工与再分发

拉流只是第一步。MEDAI V2 的价值在于：网络流进设备后，与本地 UVC 摄像头、NDI 源处在同一个处理平面，可以做切换、叠加与再编码。

4.1 作为编码输出源

在 编码配置 → 信号配置 页面，"视频输出"可直接在 UVC / NDI / NET1 / NET2 之间选择：

音频输入：选"跟随视频"则声音跟随视频源自带音轨；选"WLM"则切换到无线 MIC（接 USB 2.0 口）；
选中 NET1/NET2 后点击"应用配置"，编码器立即以该网络流作为输出源，硬件 Scaler 统一分辨率、切换瞬间刷新 IDR 帧，输出无绿屏花屏。

4.2 作为叠加副输入源

进入 特效配置 → 视频叠加 页面，可以把网络流叠加到本地摄像头画面上：

请添加图片描述

配置要点（依据说明书）：

主输入源：固定为 UVC（本地摄像机）；
副输入源：下拉可选 NDI / NET1 / NET2——即任意一路拉进来的网络流；
背景图片：支持本地上传自定义背景；
模式选择：Mode 1~5 共五种叠加模式，配置后点击"应用"并启用开关生效。

例如 Mode 下的画中画布局，可以实现"本地机位为主画面 + 远端网络流为小窗"的连线效果：

请添加图片描述

注意：五种叠加模式切换时，需先应用参数、再重新开关启用开关方可生效。

4.3 协议转换再分发

加工后的信号可以通过设备内置的六种本地流媒体服务同时对外输出：

RTMP本地服务：rtmp://<设备IP>/live/stream0（H.264，低延迟）
RTSP本地服务：rtsp://<设备IP>/live/stream0（H.264/H.265）
SRT本地服务：srt://<设备IP>:9000?streamid=...（H.264/H.265，抗丢包）
HLS本地服务：http://<设备IP>:8080/live/stream0/hls.m3u8（H.264，兼容性最佳）
HTTP本地服务：http://<设备IP>:8080/live/stream0.live.flv（HTTP-FLV/HTTP-MPEGTS，网页预览）
NDI功能：局域网内自动发现

这就是协议转换的全部秘密：拉进来的格式与送出去的格式完全解耦——进 RTSP、出 RTMP；进 HLS、出 NDI，一台设备完成过去需要"转码服务器 + 网关软件"才能做的事。

五、四个典型协议转换场景

场景一：安防 RTSP → 直播 RTMP

需求：园区/厂区已有海康、大华等 IPC（只提供 RTSP），需要把画面推到公��直播平台给管理层观看。

链路：IPC 的 rtsp:// 地址填入 NET1 → 信号配置视频输出选 NET1 → 推流配置填平台 RTMP 地址 → 同步配置开始推流。

价值：无需部署 NVR 转发或转码服务器，一台设备把安防协议直接桥接到直播生态。

场景二：远端 HLS → 本地低延迟 NDI

需求：导播系统（vMix/OBS）要接入一路来自总部的 HLS 分发源，但导播台不认 m3u8。

链路：总部 HLS 地址填入 NET2 → 设备解码后开启 NDI 输出 → vMix 在同一局域网自动发现该源。

价值：把"高延迟分发格式"转换回"制作域低延迟格式"，导播可直接切、可叠加。

场景三：CDN 的 HTTP-FLV → 叠加本地机位 → HLS 分发

需求：线上嘉宾通过 CDN 的 FLV 流接入，本地主持人机位要与其同屏，最终分发给移动端观众。

链路：FLV 地址填入 NET1 → 视频叠加中主输入 UVC（主持人）、副输入 NET1（嘉宾）、选一种叠加模式 → 媒体输出取 HLS 地址分发。

价值：一次编码同时完成"连线合成 + 多终端分发"。

场景四：双路异构源热备

需求：重要直播不允许中断，主信号是 RTMP 回传流，备用信号是 RTSP 专线。

链路：NET1 填 RTMP 主路、NET2 填 RTSP 备路，两路同时在线并在预监区显示；主路异常时，在信号配置中把视频输出从 NET1 切到 NET2，编码器自动刷新 IDR 帧，输出端无花屏。

价值：格式不同也能互为备份——这正是"多格式兼容"最直接的业务收益。

六、多格式拉流排障速查表

现象	优先怀疑	处理路径
RTSP 地址连上但黑屏	UDP 被防火墙拦截	改用 RTSP over TCP 模式；确认 554 端口可达
HLS 地址拉不到	地址不是完整 m3u8	确认以 `.m3u8` 结尾；先用浏览器/VLC 验证
HTTP-FLV 无画面	服务端不支持长连接推送	确认地址以 `.flv` 结尾；检查 CDN 是否开启 FLV 分发
RTMP 拉流失败	应用名/流名错误或源端已停	核对 app 与 stream 名；确认源端推流时长在增长
有画面无声音	源端无音轨 / 加密未正确解密	确认源端有音频输入；检查 6 位验证码与"启用解密"
画面花屏马赛克	丢包 + 参考帧依赖	RTSP 改 TCP；降低码率；等待下一个关键帧恢复
能拉到但延迟很大	源端本身是 HLS 高延迟格式	属正常现象，HLS 分片机制决定 10~30s 延迟
预监正常但无输出	输出源未切换	到信号配置把"视频输出"选为对应 NET 源并应用配置

七、总结

多格式拉流能力，表面看是"地址前缀不一样"，本质上是封装格式、传输机制、会话模型三者的差异：

RTMP 靠 Chunk 长连接，是直播生态的通用语；
RTSP 控制面与数据面分离，靠 SDP 描述媒体、靠 RTP/RTCP 传数据，是监控领域的基本盘；
HLS 把流切成文件再用 m3u8 索引，牺牲延迟换取全终端兼容；
HTTP-FLV 把 FLV Tag 挂在 HTTP 长连接上，兼顾低延迟与网页可播。

MEDAI V2 的处理方式很直接：在入口侧不挑格式——NET1/NET2 两路网络输入可以接入 RTMP/RTSP/HLS/HTTP-FLV 任意来源；在内部统一处理平面——拉进来的网络流与本地 UVC、NDI 一样可切换、可叠加、可抠像；在出口侧六协议并行——RTMP/RTSP/SRT/HLS/HTTP/NDI 同时在线，外加 5 路 RTMP 并行推流。

结果就是：过去的"转码服务器 + 网关软件 + 多台编码器"，被压缩成了一台设备的几个配置项。

核心要点回顾：

四种格式差异在封装与传输层：RTMP=Chunk/TCP、RTSP=RTP(UDP或TCP)、HLS=TS分片+m3u8索引、HTTP-FLV=FLV Tag/HTTP长连接
延迟梯队：RTSP(200~~500ms) < RTMP ≈ HTTP-FLV(1~~3s) << HLS(10~30s)
HLS 地址必须以 .m3u8 结尾，HTTP-FLV 以 .flv 结尾；RTSP 跨网段优先 TCP 模式
MEDAI V2 双路拉流：NET1（网络输入）+ NET2（RTMP输入）可同时在线，支持不同格式互为备份
加密流需输入源端 6 位验证码并启用解密，目前仅支持一路解密
拉进来的网络流可作为"视频输出"编码源，也可作为"视频叠加"副输入源（Mode 1~5），切换模式需先应用再重新开关
协议转换：进 RTSP 出 RTMP、进 HLS 出 NDI，一台设备替代转码网关