简介RTP.NET是基于.NET框架实现的实时传输协议封装库面向需要开发网络电话、视频会议、在线音视频直播等实时通信应用的中高级.NET开发者。压缩包仅三百KB包含二十六个文件其中C#源码展示核心实现exe示例可直接运行体验dll类库供二次引用chm帮助文档提供协议说明另有sln/csproj工程文件和配置文件便于编译调试与二次开发。目前已有百余人学习下载。资源内置会话管理类负责创建与管理RTP会话参与者类记录发送端与接收端的源地址、同步源标识等元数据同时提供数据包化、负载类型识别和事件驱动接口覆盖数据收发、状态通知等关键环节。借助自带示例与帮助手册可快速掌握RTP时间戳与序列号同步、RTCP质量监控与丢包恢复机制为开发实时音视频传输功能提供可直接参考的代码基础。1. RTP.NET 是传输链路的最后一百米它解决什么、适合谁拿到 RTP.NET.rar 这份压缩包的人多半不是在找库而是在解决一个具体得不能再具体的问题SIP 或者 GB/T 28181 信令已经协商成功预览按钮按下去对端黑屏、超时、或者画面一顿一顿抓包一看 RTP 包要么没出去要么出去了对端完全不认。RTP.NET 把 RTP/RTCP 的打包、收发、序号维护和时间戳管理封装成 .NET 可直接引用的程序集让你从裸写 RTP 头里解放出来同时保留对这些细节的控制权。适合苦于媒体链路黑匣子的 .NET 后端工程师、做国标平台或视频接入网关的开发者以及不想被整套 WebRTC 框架绑架、只想把媒体流稳定送达的人。下文按接入链路推进协议、选型、参数、排错最后落到两个硬技巧。2. RTP 头字段和 RTCP 报告先看懂协议再碰 RTP.NET 封装RTP.NET 这类库最大的价值是帮你打包、拆包、发送和接收但它不会替你判断“对端为什么不理你”。所有媒体对接故障最终都要回到 RTP 头字段和 RTCP 报告里找答案。所以我不建议先写代码建议先能在抓包里读懂一个 RTP 包。2.1 RTP 头里最容易被库隐藏的三个字段RTP 固定头 12 字节按大端序排列。版本号 V 占 2bit当前几乎都是 2P 是填充位X 是扩展位CC 表示 CSRC 数量M 是标记位这些平时库都处理好了。真正需要你手写或校验的是后面三块PT 载荷类型占 7bit、sequence number 序号占 16bit、timestamp 时间戳占 32bit再后面是 SSRC 同步源标识占 32bit。这三块的典型翻车姿势如下。PT 必须和 SDP 里协商好的动态载荷类型一致例如 H.264 常被约定为 96如果把 96 写成了 97播放器拿到包直接丢。序号是逐包递增的用于检测丢包和乱序常见的实现错误是每发一帧重置一次序号导致对端认为丢包率达到 99%。时间戳的单位不是毫秒而是采样率倒数视频固定 90kHz、音频按采样率。很多代码把视频时间戳按毫秒递增在国标平台和 SIP 通话里表现为音画不同步和越来越卡。下表把三者的常见误用列出来字段位数正确含义高频错误PT7bit载荷类型动态 PT 由 SDP 的 artpmap 指定不查 SDP 直接写死 96sequence number16bit每发送一个 RTP 包加 1判断丢包或乱序按帧重置、乱序不处理timestamp32bit采样时刻视频 90kHz 时钟按毫秒填导致音画不同步这里有一个血泪经验永远不要相信库默认给的时间戳。很多封装把 timestamp 参数暴露成 int却不说单位你填 3000 它照发对端也照收但攒到 RTCP 做同步时才发现时钟不对。收到“RTCP 同步不了”或者“播放器快进式卡顿”这种玄学问题时先回来看时间戳单位。2.2 RTCP 不是可选项SR/RR 是平台判定会话是否存活的依据RTP 只管数据搬运质量反馈和控制信息走 RTCP。RTCP 里最常见的四种报文SR 发送方报告、RR 接收方报告、SDES 源描述、BYE 离开通知。SR 报文里有一对关键时间戳——NTP 时间戳和 RTP 时间戳它们来自同一个采样时刻音视频两路流拿到各自的 SR 之后就能算出播放对齐的偏移。RR 报文则反馈接收方的丢包率、抖动和最近一次收到 SR 的延迟发送端靠它调整码率或触发重传。在国标平台这类场景里RTCP 还有一层特殊作用它是平台判定“这条 RTP 会话还活着”的探针之一。部分平台网关在收到几拍 RTCP SR 之后才把预览状态机切到可用如果只发 RTP 不发 RTCP信令面看起来正常但平台侧会报预览失败并提示媒体会话异常。RTP.NET 常见的封装都内置了 RTCP SR 的周期发送默认间隔接近 5 秒。这个间隔对窄带场景合理但对平台判活来说太慢。我一般把 RTCP 间隔调到 1 到 3 秒代价是带宽多出几 Kbps换来平台侧更快的会话确认和更稳的预览启动。RTP 与 RTCP 的端口关系也值得注意。RTP 用偶数 UDP 端口时RTCP 习惯用相邻的奇数端口但这不是协议强制的而是端口分配约定。SDP 里如果只写了 RTP 端口很多实现会 1 当 RTCP 端口RTP.NET 初始化时如果端口绑定方式不同要么手动把 RTCP 端口配到和信令一致要么接受对端抓不到 RTCP。这个问题在 NAT 环境下尤其隐蔽对内网调试没问题一跨网段对端就报会话失败。2.3 用 tshark 验证一个 RTP 包判断标准先于代码代码动手前先用抓包工具把基准数据拿到手。tshark 是命令行下最顺手的工具下面这条命令抓指定端口上的 UDP 包并解析 RTP 详情tshark -i eth0 -f udp port 5004 -V -Y rtp-V 输出协议树-Y rtp 过滤出 RTP 包。如果当前 tshark 版本没有内置 RTP 解码器可以用-d udp.port5004,rtp动态指定解码只是要注意这会把该端口上所有 UDP 包都按 RTP 解析。正常输出里能看到固定头各字段。重点核对三行Payload type 是否与 SDP 的 artpmap 一致Sequence number 是否按 1 递增Timestamp 的差值是否稳定等于帧间隔对应的采样数。如果看到 sequence number 重复说明发送端在重置序号如果 timestamp 抖动很大说明打包线程没有按采样节奏走。还有一个经验性参数RTP 包的网络层长度。H.264 单包不超过 1200 字节比较稳妥超过 1400 容易在 MTU 边界被 IP 分片分片后 UDP 丢一个 IP 分片整个包就没了。抓包时看到长度长期贴着 1500就应该怀疑是不是没做链路层拆分。这些判断标准不依赖任何库RTP.NET 只是帮你执行不帮你决策。3. 拿到 RTP.NET.rar 之后程序集选择、SDP 协商与参数怎么传压缩包下载下来只是第一步。真正决定项目成败的是后续几个选择库里挑哪个程序集、SDP 里的参数怎么映射到库的 API、在 .NET 6 环境下能不能直接用。这三个问题处理完接入才算正式开始。3.1 先分清是哪个 RTPRTP.NET 不是 RPG Maker 的 RTP搜索 RTP.NET 时特别容易混进一批游戏相关结果。rpgvxace rtp 需要运行这个游戏、rpgvx rtp is not found 之类的问题说的是 RPG Maker 系列的 Runtime Package也就是游戏运行需要的素材库和实时传输协议没有任何关系。如果你是为了解决 RTP.NET.rar 里的媒体传输问题误装游戏运行库不会对调试有任何帮助。区分方式很简单看包里有没有 RtpSession、RtpPacket、RtpListener 这类类名有就是实时传输协议库如果包里是 Graphics、Audio、System 目录结构那是游戏素材运行库。这种同名撞车在下载站里很常见名称里带 rtp 的包未必是你要的那个先花一分钟检查命名空间比下载后踩坑划算。3.2 从 .rar 里选出正确分支哪个 DLL 能引用RTP.NET.rar 这类包通常长这样源码工程、一份编译产物、若干文档。编译产物可能在 bin\Debug 或 bin\Release 下优先选 Release 目录里的 DLL。选择 DLL 时先确认目标框架老库常见 .NET Framework 2.0/4.x纯托管实现居多在 .NET Framework 项目里直接添加引用即可。若你在 .NET Core / .NET 6 项目里引用旧 DLL多数情况下直接引用也能跑因为 RTP 协议代码基本只依赖 System.Net.Sockets 和基本集合遇到少数依赖 Remoting 或 BinaryFormatter 的分支运行时会抛 TypeLoadException 或 MethodAccessException。这时不要死磕直接把源码重编进项目去掉那几个不兼容的依赖。项目里引用 DLL 的方式Reference IncludeRTPNet HintPathlib\RTPNet.dll/HintPath Privatetrue/Private /Reference或者更省事把源码目录拷进解决方案工程引用项目而不是 DLL。RTP.NET 体积不大重编译一次成本低换来的是能直接断点进打包和拆包逻辑媒体问题排查时这一步非常值。重编译前先用反射或文本搜索检查程序集里有没有 System.Runtime.Serialization 命名空间的引用有就优先处理能少走弯路。3.3 SDP 与 RTP 参数的对应关系端口、PT、SSRC 一次对齐RTP 参数不是自描述的双方必须在会话建立时通过信令对齐。标准做法是 SDP 协商。一个典型视频流的 SDP 片段mvideo 5004 RTP/AVP 96 artpmap:96 H264/90000 afmtp:96 packetization-mode1 arecvonly这段 SDP 的含义本端在 UDP 5004 端口接收视频 RTP动态 PT 96 对应 H.264时间戳时钟 90kHz分包模式为 1允许 FU-A 分片。RTP.NET 初始化时要把这几项逐一填入本地端口 5004、远端地址和端口、PT 96、时钟 90000。任何一个错位都会导致对端收到包但解不出流。国标平台场景下还要盯住 SSRC。标准做法是在 SDP 中约定一个四字节 SSRC用十六进制字符串表示平台侧校验收到的 RTP 包 SSRC 是否等于约定值不等就丢弃。RTP.NET 里 SSRC 通常是初始化会话时的一个 uint 参数注意把 SDP 里的十六进制转成 uint 时别写成字符串比较。常见坑是大小写不一致0xABCD1234 和 0xabcd1234 数值上没区别但转成字符串比较的代码会判定不相等表现就是平台侧仍然提示媒体会话异常。这种问题抓包都难发现因为数值其实是对的。3.4 初始化一个 RTP 会话的最小代码拿到 SDP 之后最小初始化逻辑如下var localPort 5004; // 与 m 行端口一致 var remoteIp IPAddress.Parse(192.168.1.20); // 对端媒体地址 var remotePort 5004; // 对端 RTP 端口 var session new RtpSession(localPort); session.PayloadType 96; // SDP artpmap 的动态 PT session.Ssrc 0xABCD1234; // SDP 约定的 SSRC session.TimestampClock 90000; // 视频固定时钟 session.RtcpInterval TimeSpan.FromSeconds(3);// 平台判活依赖 RTCP session.Start();这里要注意RtpSession 是这类库最常见的会话类名你手里那份如果类名不同按职责找等价物。localPort 是本地绑定端口必须和 SDP m 行一致否则对端回包没人收remoteIp 和 remotePort 填写对端媒体地址很多设备信令地址和媒体地址不是同一个NAT 环境下尤其容易填错填错了表现为“发送端在发、接收端没反应”。PayloadType 决定对端如何解释载荷。Ssrc 建议显式设置并填写 SDP 里约定的值默认随机值在国标平台极可能被拒。TimestampClock 决定内部时间戳累加方式错则音画不同步。RtcpInterval 按平台判活要求调短原因见上一章。初始化之后收包、发包、自动 RTCP 都由会话对象承担你只需要关注载荷组装。4. 最小收发链路把 H.264 流送出去再收回来SDP 对齐之后最值得先跑通的就是一条不经过任何服务器的点对点链路一端用 RTP.NET 发 H.264另一端接收后在本地用 ffmpeg 验证解码。这一步成功再往国标平台或 SIP 网关接就有基准对照。4.1 发送端按 90kHz 时间戳和无缝序号打包H.264 的 RTP 封包最简单的是 Single NAL Unit一个 NAL 包放进一个 RTP 包。从文件读入或编码器拿到一帧编码数据后按 NAL 起始码切出一个个 NAL逐个封装发送。发送端关键代码var nal ExtractNalUnit(frameBytes, ref offset); // 按起始码切 NAL var rtpPacket session.CreatePacket(nal); rtpPacket.Timestamp timestamp; // 当前帧的采样时刻 session.Send(rtpPacket); timestamp 3000; // 90000 / 30fps 3000每帧递增参数说明CreatePacket 内部完成 RTP 头填充sequence number 由会话自动加 1别手动改改了丢包判断就失真。timestamp 的步长是 90000 除以帧率30fps 就是 3000。注意时间是“采样时刻”不是时刻差一帧一加别在每包上重复加。切 NAL 时注意 H.264 的 Annex-B 格式起始码可能是 00 00 01 或 00 00 00 01只按三字节找会把四字节起始码的前三字节误判成一个 NAL实际项目总在这里翻车。提示起始码可能是 00 00 01也可能是 00 00 00 01。只按三字节匹配会把四字节起始码误判成一个 NAL建议先匹配四字节失败再回退三字节。这个发送端故意没有处理 FU-A 分片。NAL 小于 MTU 时单包没问题但真实视频流一帧往往几十 KB必须分片。分片逻辑放到最后一章统一讲先跑通单包链路更利于隔离问题。4.2 接收端序号连续性检测与基础抖动估计对端接收代码核心是事件回调session.PacketReceived (sender, args) { var packet args.Packet; var seqDelta (ushort)(packet.SequenceNumber - lastSeq); if (seqDelta ! 1) { Console.WriteLine($丢包或乱序: 期望 seq{lastSeq 1}, 实际{packet.SequenceNumber}); } lastSeq packet.SequenceNumber; enqueue(packet.Payload); // 交给解码缓冲 };代码说明sequence number 是 16bit用 ushort 做差才能正确处理回绕直接比较大小在 seq 从 65535 回 0 时会误报。这里的丢包检测只是打印日志生产环境应把丢包率统计进 RTCP RR 并反馈给发送端。收到的 Payload 直接排队队列长度就是抖动缓冲先入先出缓冲深度怎么设放到最后一章讲。4.3 用 ffmpeg 验证整条链路不需要 RTSP 服务器要确认这条链路真的能解码最省事的方案是准备一个 SDP 文件让 ffmpeg 自己拉 RTP 流。SDP 内容和第 3 章的协商片段一致v0 mvideo 5004 RTP/AVP 96 artpmap:96 H264/90000然后执行ffmpeg -protocol_whitelist file,udp,rtp -f sdp -i recv.sdp -f null -参数说明-protocol_whitelist 限制协议白名单新版本 ffmpeg 默认不放行 RTP必须显式加 file,udp,rtp。-f sdp 按 SDP 文件解析媒体格式。输出到 -f null - 表示只解码不写文件看控制台有没有报错。如果控制台连续输出解码错误说明 RTP 载荷组装有问题如果正常有 frame 计数链路就是通的。这个验证完全不依赖 RTSP、SIP 或任何服务器是隔离问题的最短路径。抓包配合判断ffmpeg 解码正常但自己的接收端代码解不出问题在代码侧ffmpeg 也不解码问题在发送端封包或 SDP 参数。这一对照能省掉大量无头绪调试。5. RTP.NET 集成排错六个常见翻车现场与对症下药这一章整理我在这类同步对接中反复遇到的六个问题。每条按现象、原因、解决展开能直接拿来对照。5.1 现象国标平台信令正常但取流黑屏现象SIP 信令已 200 OK平台侧日志出现 start preview failed 或媒体会话异常之类提示预览窗口黑屏。原因平台侧下发的 SDP 里的媒体 IP 和端口与 RTP.NET 实际绑定不一致或者约定 SSRC 在 RTP 包头没对上平台直接丢弃。另一个常被忽视的原因是 RTCP 没按约定端口上报平台等不到 SR 判定会话不存活。解决第一步在发送端所在主机抓包确认出包目标地址和端口就是平台下发的 SDP 中的地址端口第二步核对 SDP 中 SSRC 十六进制串与 RTP 包头值我建议在代码里把 SSRC 写成常量并与 SDP 强一致第三步确认 RTCP 周期发送已开启RTP.NET 里没有显式开关时就把 RtcpInterval 配小3 秒内平台侧状态机基本会切到正常。这个问题 80% 靠抓包能定位不建议在平台侧反复重启取流。5.2 现象多路并发预览时画面互相串流现象同一个进程开了多路通道A 通道显示 B 通道画面且平台侧时常报通道错误。原因所有通道共用一个 RtpSession 实例或发送端的 SSRC 没有按通道唯一化。RTP 对端区分流靠 SSRC同一个 SSRC 出现在不同通道上平台按 SSRC 建索引就会把流串到一起。解决每路通道独立创建 RtpSession绑定各自端口SSRC 每路唯一。注意 CreatePacket 时如果手动覆盖了 SSRC必须保证它在所有并发会话中不重复否则只是“看起来每路独立实际包头都长一个样”。5.3 现象延迟越来越大播放器逐渐不同步现象刚启动时正常运行几分钟后音画越来越不同步视频延迟可感知地增长。原因RTP 时间戳没有按采样时钟递增或者发送线程在场景高并发时被延迟执行但时间戳又按“系统当前时间换算”导致接收端认为时钟漂移缓冲越排越长。解决回到发送端检查时间戳计算。正确做法是发送线程维护独立计数视频每帧加 90000/fps音频按采样周期累加不读墙钟。RTP.NET 的会话若提供自动时间戳确认它使用的是采样计数而不是 DateTime把发送线程改为每帧 sleep 到固定节奏也能抑制延迟溢出。5.4 现象.NET Framework 下正常升级 .NET 6 后直接抛异常现象同一套代码在 .NET Framework 4.8 下收发正常迁移到 .NET 6 控制台后启动即崩异常指向程序集加载或方法不存在。原因老 RTP.NET 分支有依赖 BinaryFormatter 或 Remoting 的代码少数封装带 P/Invoke 原生库仅支持 x86。这些在 .NET Core 起都不受支持。解决优先从源码重编译把调用 BinaryFormatter 和 Remoting 的路径删掉或替换成普通对象传递原生依赖则换成纯托管分支。重编译前先用反射检查程序集引用了哪些 System.Runtime.Serialization 命名空间能少走弯路。5.5 现象H.264 画面偶发花屏和马赛克现象整条链路连通但播放时随机出现花屏、绿块重连后恢复一段时间再犯。原因多半是 FU-A 分片重组逻辑没有处理 S/E 位。H.264 大帧被切成多个 RTP 分片接收端必须以 FU-A 的 S 分片为起始、E 分片为结束把中间负载按顺序拼接成一个完整 NAL中间的乱序和丢包如果不处理重组出的 NAL 就是坏的坏 NAL 就解码成花屏。解决接收端实现一个分片重组缓冲区S 位包开始缓冲、E 位包结束并输出、非 S/E 包追加、下一个 S 包到来时清空上一个不完整的缓冲。丢包导致缺 E 包时靠序列号间隙判断并主动丢弃缓冲。重组细节和代码见下一章。5.6 注意RTP.NET 不是 SRTP也不是万能的音视频框架涉及安全或大规模场景时别硬套。标准 RTP 不加密里面的音视频数据明文可见。RTP.NET 各分支一般都不带 SRTP 支持需要加密时常见方案是引入 SRTP 实现或在其外层做安全传输协商也别指望它帮你做编码解码、回音消除、带宽自适应这些要配专门组件。选型时确认你的场景只需要“无损地按 RTP 格式搬运媒体”这才是这个库的价值边界。6. 抖动估计与 FU-A 重组给 RTP.NET 补两个硬补丁6.1 按 RFC 3550 维护抖动估计接收端缓冲区深度需要量化。RFC 3550 附录 A.8 给出的抖动估计是一条递推公式RTP.NET 不一定会暴露这个内部状态但它依赖的每个量你都能拿到包到达时刻和 RTP 时间戳。核心如下var transit arrivalTime - packet.Timestamp; // 到达时间减采样时间 var d Math.Abs(transit - lastTransit); jitter (d - jitter) / 16.0; // 指数加权平均 lastTransit transit;参数说明transit 要与时钟统一。arrivalTime 用单调时钟换算成同样单位比如 90kHz 时钟下的“采样次数”不能拿 DateTime 相减墙钟回拨会污染 jitter。递推系数 16 是 RFC 建议值系数越小抖动估计越平滑但对持续突发越不敏感。缓冲深度可以设为 4 到 8 倍 jitter 值视频再补上最大单帧分片数带来的排队延迟。这个参数组合是我在接入网关时的习惯起点先跑一天再按丢包与延迟取舍。6.2 FU-A 重组的关键判断H.264 大 NAL 分片以 FU-A 方式传输负载类型为 28。接收端重组逻辑if (payload[0] 28) // FU-A { bool start (payload[1] 0x80) ! 0; bool end (payload[1] 0x40) ! 0; var nalHeader (byte)((payload[0] 0xE0) | (payload[1] 0x1F)); if (start) { buffer.Clear(); buffer.Add(nalHeader); } buffer.AddRange(payload.Skip(2)); if (end) { feedDecoder(buffer.ToArray()); buffer.Clear(); } } else if (payload[0] 24) // STAP-A按需另处理判断要点FU-A 的 payload 前两个字节分别是 FU indicator 和 FU header真正的 NAL 头由 FU indicator 的高 3 位F、NRI和 FU header 的低 5 位type拼出来。S 位为 1 时开启新的重组缓冲E 位为 1 时把缓冲完整交给解码器。经典错误是把 payload[0] 直接当 NAL 头送进解码器或者只在 S 包到达时输出导致花屏。先按 S/E 位重组再谈丢包重传顺序错了重传也没用。这套重组逻辑我最早是在一次接摄像头取流时踩了坑图像十几秒一花重连就好。一度怀疑编码器、怀疑网络最后抓包比对才发现是 FU-A 的 S 位判断写成了“首包且不是 E”丢一个分片后缓冲永不释放后续数据全部串位。早一点把 S/E 位和序列号间隙放在一起处理能少走很多弯路。希望帮到你。本文还有配套的精品资源点击获取