企业官网建设流程全解析

一、 技术背景与 WHIP 协议的引入

在移动端低延迟视频上行场景中，传统的RTMP协议由于基于 TCP 协议，在面对移动网络抖动、丢包时，容易因为重传阻塞导致画面延迟堆积。虽然传统的 RTMP 兼容性较好，但在高互动性、实时指挥或远控等对延迟要求极高的特定场景中，WHIP似乎更受欢迎.

随着WebRTC技术的普及，毫秒级的低延迟分发逐渐成为一种可行的选择。然而，早期的 WebRTC 并没有统一的流媒体推流信令标准。各流媒体服务器和终端厂商在推流握手阶段，大多采用各自私有的 SDP 交换逻辑，这给 Android 客户端的通用适配带来了一定的开发成本。

为了解决信令不标准的问题，IETF 推出了WHIP（WebRTC-HTTP Ingestion Protocol）协议。WHIP 协议将复杂的 WebRTC 信令握手简化为了标准的HTTP POST 请求。客户端只需向流媒体服务器的 Endpoint发送一个携带本地 SDP 的 POST 请求，服务器在响应中返回服务端 SDP，即可简单直观地完成握手并建立 WebRTC 媒体通道。

二、 Android WHIP 推流接口

以下是本项目中设计和使用的Android WHIP 推流核心 Java 接口。该设计考虑了生产环境下的安全鉴权、HTTPS 证书验证控制、以及 RTP 层的抗弱网机制（如 NACK、Pacing 等）。

/* * Copyright (C) 1130758427@qq.com. All rights reserved. * WeChat: ldxevt *//** * 设置音频编码类型 * @param type: 1:AAC, 2:SPEEX, 3:PCMA, 5:Opus * @return {0} if successful */publicnativeintSmartPublisherSetAudioCodecType(longhandle,inttype);/** * 设置 Opus 编码器 application 类型 * 如果输入的音频是语音，可以尝试 VOIP 模式 * @param application_type: 2048: VOIP, 2049: Audio, SDK 默认是 Audio(2049) */publicnativeintSetOpusEncoderApplicationType(longhandle,intapplication_type);/** * 设置 WHIP 推流的 HTTP 入口服务地址 (Endpoint URL). * @param endpoint_url WHIP 服务器的标准 HTTP/HTTPS 接入地址字符串。不能为空。 */publicnativeintSetWhipEndpointURL(longhandle,Stringendpoint_url);/** * 设置 WHIP 推流请求的 Bearer 鉴权令牌 (Token). * @param bearer_token 用于鉴权的令牌字符串, 如果无需鉴权则传空字符串. */publicnativeintSetWhipBearerToken(longhandle,Stringbearer_token);/** * WHIP 推送时, 如果音频是 G711 编码, 是否要转为 Opus. * @param value 1: 开启转码，0: 关闭转码(默认). */publicnativeintSetWhipG711ToOpus(longhandle,intvalue);/** * 设置用于验证 WHIP HTTPS 信令请求服务器证书的 CA 证书集文件路径 (.pem). */publicnativeintSetWhipHttpCaBundlePath(longhandle,Stringpath);/** * 设置 WHIP HTTP 信令请求时是否验证服务器的 SSL/TLS 证书。 * @param value 1: 开启验证（默认）; 0: 关闭验证. */publicnativeintSetWhipHttpSslVerifyPeer(longhandle,intvalue);/** * 设置 WHIP HTTP 信令请求时是否验证服务器证书中的域名与请求的 URL 域名是否匹配。 */publicnativeintSetWhipHttpSslVerifyHost(longhandle,intvalue);/** * 设置 WHIP HTTP 信令请求的连接超时与整体超时时间（单位：毫秒）。 */publicnativeintSetWhipHttpConnectTimeoutMs(longhandle,inttimeout_ms);publicnativeintSetWhipHttpTimeoutMs(longhandle,inttimeout_ms);/** * [抗弱网配置] 设置 WHIP 是否启用 RTP 的 NACK（丢包重传响应）功能, 仅用于视频包. * @param value 1: 开启视频 RTP 层的 NACK 响应（默认开启），0: 关闭机制. */publicnativeintSetWhipRtpNackEnabled(longhandle,intvalue);/** * [抗弱网配置] 设置 WHIP 是否启用视频 RTP 协议层的 Pacing（平滑匀速发送）功能。 * 能够有效防止突发大码率导致路由器队列丢包。 */publicnativeintSetWhipRtpPacingEnabled(longhandle,intvalue);/** * 设置转发视频流（如 RTSP/RTMP 转 WHIP）的真实编码平均千比特率 (kbps)。RTP Pacing 使用。 */publicnativeintSetWhipEncodedVideoKbitrate(longhandle,intkbitrate);/** * 启动 / 停止 WHIP 推流. */publicnativeintStartWhipStream(longhandle,intreserve);publicnativeintStopWhipStream(longhandle,intreserve);

核心设计考虑：

1. 音频本地自适应转码（AAC/G711 → Opus）：WebRTC 规范强制要求音频使用Opus编码。如果 Android 采集端输入的是传统安防的 G.711(PCMU/PCMA) 或常用的 AAC，SDK 支持在底层直接进行本地重采样并转码为 Opus，从而降低流媒体服务器后端的实时转码压力。
2. 平滑整流与重传（NACK & Pacing）：在无线移动网络下，网络抖动较为常见。通过开启NACK（丢包重传）可以及时尝试补齐因偶发丢包丢失的视频包；配合Pacing（平滑匀速发送）机制，可以使高码率数据帧在时间轴上更平稳地分发，减少瞬间高拥堵造成的丢包风险。

三、 系统支持的格式与特性矩阵

在系统落地和工程实践中，为了适配多样化的业务诉求，该底层流媒体模块实现了较为完整的功能矩阵：

• ** 视频格式兼容**：支持H.264与H.265的编码模式。
• 音频格式支持：集成了AAC、G.711（PCMA/PCMU）以及 Opus。
• ** 跨协议音频转换**：支持G.711 自动转 Opus与AAC 自动转 Opus，以便直接对接标准的 WebRTC 接收端。
• 灵活的流裁剪控制：根据实际网络带宽环境，支持音视频同步推送、只推送视频（纯画面）或只推送音频（纯对讲/纯广播）。
• 客户端同步录像：在向外推流的同时，系统支持在 Android 客户端本地同步开启录像，实时生成标准的MP4 文件。

四、 跨协议多路转发融合矩阵测试与场景复盘

为了检验这套流媒体推流模块在不同数据源和配置下的运行状态，我们搭建了多路并发与跨协议融合分发环境。

在测试中，系统对同源数据流实现了高强度的并发分发：

• 上行通路：同时启动WHIP 协议推流与传统 RTMP 协议推流。
• 下行通路：Android 手机本地同时启动内嵌的RTSP 服务供外部拉流对齐。
• 端侧备份：在推送端同步使能本地MP4 录像功能。

通过 PC 解码端同屏播放并对比网页标准北京时间（带有毫秒显示），我们对几种典型场景下的传输效果进行了观察：

🟢 场景 A：相机采集（H.264 + 720P + AAC）多路并发测试

• 配置：Android Camera1 采集1280*720 @ 25fps，H.264 编码，音频采用 AAC 采集（WHIP 推送时，SDK 内部自动转码为规范的 OPUS）。同时在媒体流中注入了自定义 SEI 元数据。

📊 场景 A 实测效果图：

⏱️ 延迟与效果复盘：

• 【基准源】标准北京时间网页：13:25:26:206
• 【窗口 1】网页端 WebRTC (WHIP上行)：13:25:25:922
• 测算全链路延迟：约为 284 ms
• 效果反馈：在 H.264 相机采集场景下，全链路延迟控制在毫秒级，画面运行流畅度较好。同时，控制台能够正常解析出随流注入的自定义 SEI 数据（包含日期时间2026-10-16），基本实现了数据和画面的时间同步。

🔵 场景 B：相机高清采集(H.265 + 1080P + Opus)流传输测试

• 配置：Android Camera2 采集1920*1080 @ 25fps，使能硬编(H.265)。音频直接配置为Opus编码以适应 WebRTC。

📊 场景 B 实测效果图：

⏱️ 延迟与效果复盘：

• 【基准源】标准北京时间网页：15:26:01:877
• 【窗口 1】网页端 WebRTC (WHIP上行/H.265硬解)：15:26:01:559
• 测算全链路延迟：约为 318 ms
• 效果反馈：虽然 1080P 分辨率与 H.265 编码增加了数据吞吐量 and 计算开销，但在 Android MediaCodec 硬编和底层队列的配合下，发送时延统计表现正常。WebRTC 播放端的总体延迟表现相对平稳，比 720P 方案微增了约 34ms，画质清晰度有了一定提升。

🟡 场景 C：Android 屏幕共享采集（H.264录屏）传输测试

• 配置：基于 AndroidMediaProjection屏幕录制采集，H.264 硬编码。支持系统音频播放采集（内录 Submix）与麦克风采集。同步进行 WHIP 推流、RTMP 推流、RTSP 服务发布及本地 MP4 录制。

📊 场景 C 实测效果图：

⏱️ 场景 C 效果复盘：

• 效果反馈：由于屏幕共享对文字的边缘细节清晰度、高对比度画面瞬变有一定要求，我们在底层对高动态码率波动进行了合理的限流整流。测试结果显示，WebRTC 播放端解码稳定，文字和数字跳变没有出现明显的马赛克和错位，延迟表现符合预期。

🔴 场景 D：2K RTSP 网络安防流多路转发 WHIP 实现测试

• 配置：系统剥离本地摄像头采集，转为从局域网内拉取外部摄像头的2560*1440 (2K)25fps H.264 RTSP 超清安防流，输入音频为PCMU (G.711U)。SDK 异步拉流解复用后，采用视频零拷贝透传方案，并将音频在本地实时转码为标准的 Opus，最后同时多路转发 WHIP、转推 RTMP 并重新发布 RTSP 协议流。

📊 场景 D 实测效果图：

⏱️ 场景 D 效果复盘：

• 效果反馈：在面对 2K (2560*1440) 较大吞吐量的工业流多路转发场景时，也可以考虑直接推送G711(不转码OPUS). PC 端 WebRTC 解码正常，为低延迟安防网关或机载设备转发提供了基本的参考。

五、 总结与交流探讨

通过对相机采集（Camera1/Camera2）、屏幕共享录制以及外部 RTSP 多路转发 WHIP的复合测试，验证了 WHIP 协议在移动端和边缘侧各种应用场景下的可行性。

实测结果表明，在合理的底层整流（NACK/Pacing）和硬编硬解的优化下，该方案能够将全链路延迟稳定控制在300ms 左右的合理物理范围内，整体推流效果和转发表现良好，基本能够满足超低延迟流媒体场景的落地要求。

欢迎交流！

音视频和流媒体底层开发涉及较多的工程细节，很多深入的优化工作由于篇幅所限，无法在一篇文章中完全展开。

如果您对本项目中的 C++ 流控引擎设计、接口交互或者生产环境下的特定场景优化有更好的建议，欢迎交流！