Android 端 WHIP 协议推流技术实践：相机/录屏/多路转发WHIP实现测试

一、技术背景与 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 等）。

java 复制代码

/*
 * Copyright (C) 1130758427@qq.com. All rights reserved. 
 * WeChat: ldxevt
 */

/**
 * 设置音频编码类型
 * @param type: 1:AAC, 2:SPEEX, 3:PCMA, 5:Opus
 * @return {0} if successful
 */
public native int SmartPublisherSetAudioCodecType(long handle, int type);

/**
 * 设置 Opus 编码器 application 类型
 * 如果输入的音频是语音，可以尝试 VOIP 模式
 * @param application_type: 2048: VOIP, 2049: Audio, SDK 默认是 Audio(2049)
 */
public native int SetOpusEncoderApplicationType(long handle, int application_type);

/**
 * 设置 WHIP 推流的 HTTP 入口服务地址 (Endpoint URL).
 * @param endpoint_url WHIP 服务器的标准 HTTP/HTTPS 接入地址字符串。不能为空。
 */
public native int SetWhipEndpointURL(long handle, String endpoint_url);

/**
 * 设置 WHIP 推流请求的 Bearer 鉴权令牌 (Token).
 * @param bearer_token 用于鉴权的令牌字符串, 如果无需鉴权则传空字符串.
 */
public native int SetWhipBearerToken(long handle, String bearer_token);

/**
 * WHIP 推送时, 如果音频是 G711 编码, 是否要转为 Opus.
 * @param value 1: 开启转码，0: 关闭转码(默认).
 */
public native int SetWhipG711ToOpus(long handle, int value);

/**
 * 设置用于验证 WHIP HTTPS 信令请求服务器证书的 CA 证书集文件路径 (.pem).
 */
public native int SetWhipHttpCaBundlePath(long handle, String path);

/**
 * 设置 WHIP HTTP 信令请求时是否验证服务器的 SSL/TLS 证书。
 * @param value 1: 开启验证（默认）; 0: 关闭验证.
 */
public native int SetWhipHttpSslVerifyPeer(long handle, int value);

/**
 * 设置 WHIP HTTP 信令请求时是否验证服务器证书中的域名与请求的 URL 域名是否匹配。
 */
public native int SetWhipHttpSslVerifyHost(long handle, int value);

/**
 * 设置 WHIP HTTP 信令请求的连接超时与整体超时时间（单位：毫秒）。
 */
public native int SetWhipHttpConnectTimeoutMs(long handle, int timeout_ms);
public native int SetWhipHttpTimeoutMs(long handle, int timeout_ms);

/**
 * [抗弱网配置] 设置 WHIP 是否启用 RTP 的 NACK（丢包重传响应）功能, 仅用于视频包.
 * @param value 1: 开启视频 RTP 层的 NACK 响应（默认开启），0: 关闭机制.
 */
public native int SetWhipRtpNackEnabled(long handle, int value);

/**
 * [抗弱网配置] 设置 WHIP 是否启用视频 RTP 协议层的 Pacing（平滑匀速发送）功能。
 * 能够有效防止突发大码率导致路由器队列丢包。
 */
public native int SetWhipRtpPacingEnabled(long handle, int value);

/**
 * 设置转发视频流（如 RTSP/RTMP 转 WHIP）的真实编码平均千比特率 (kbps)。RTP Pacing 使用。
 */
public native int SetWhipEncodedVideoKbitrate(long handle, int kbitrate);

/**
 * 启动 / 停止 WHIP 推流.
 */
public native int StartWhipStream(long handle, int reserve);
public native int StopWhipStream(long handle, int reserve);

核心设计考虑：

音频本地自适应转码（AAC/G711 → Opus） ：WebRTC 规范强制要求音频使用 Opus 编码。如果 Android 采集端输入的是传统安防的 G.711(PCMU/PCMA) 或常用的 AAC，SDK 支持在底层直接进行本地重采样并转码为 Opus，从而降低流媒体服务器后端的实时转码压力。
平滑整流与重传（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录屏）传输测试

配置：基于 Android MediaProjection 屏幕录制采集，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++ 流控引擎设计、接口交互或者生产环境下的特定场景优化有更好的建议，欢迎交流！

Android 端 WHIP 协议推流技术实践：相机/录屏/多路转发WHIP实现测试

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

二、 Android WHIP 推流接口

核心设计考虑：

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

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

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

📊 场景 A 实测效果图：

⏱️ 延迟与效果复盘：

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

📊 场景 B 实测效果图：

⏱️ 延迟与效果复盘：

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

📊 场景 C 实测效果图：

⏱️ 场景 C 效果复盘：

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

📊 场景 D 实测效果图：

⏱️ 场景 D 效果复盘：

五、 总结与交流探讨

欢迎交流！

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

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

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

五、总结与交流探讨