妮妮：今天我们聊聊Web RTC做直播推流。
小新：好的，WHIP推流协议实现已经合入FFMPEG，OBS。推进了web rtc推流的方案。
妮妮：那什么是WHIP协议呢？
小新：WHIP的全称是：Web RTC HTTP Ingestion Protocol，是一种基于 HTTP 的协议，专为简化 Web RTC 推流流程而设计。它通过标准化的 HTTP 接口，替代传统 Web RTC 中复杂的 SDP 信令交换和 ICE 协商，广泛应用于低延迟直播、视频会议和远程控制等场景。
妮妮：哪些客户端和服务端支持呢？
小新：WHIP 的核心功能是将客户端（如浏览器或 OBS，FFMPEG8.0）生成的媒体流推送到媒体服务器（如 SRS、Janus、LiveKit）。它的主要优势包括简化信令流程、标准化接口以及基于 WebRTC 的低延迟传输。
妮妮：这么多的应用，是不是意味WHIP协议是未来更好的直播推流协议了？
小新：个人认为并不会是这样。
妮妮：详细说说。
小新：先说说视频直播的技术要求和特点：首先，直播要求平稳，流畅，不卡顿，不花屏；其次，能容忍网络抖动，短时间的网络阻塞不会影响流畅性；再者，运动直播，游戏直播要求高帧率，保证其高分辨率，高帧率；
妮妮：直播对质量和体验的要求很高呀，之前的直播技术推流是怎么处理的？
小新：传统的推流采用RTMP协议，客户端推流的时候，如果遇到TCP发送阻塞，会有一个本地缓存队列把暂时要发送的音视频缓存起来，这个队列可以有2到6秒；而拉流播放端也有个2~4秒的播放缓存，也就是即使出现几秒的抖动，卡顿，是不影响用户流畅观看的。
妮妮：哦，理解了，也就是用缓存队列换流畅，或者说用延时换流畅。那么WebRTC推流的技术特点呢？
小新：Web RTC的传输，是低延时的传输方式。它的流控方式有：丢包重传，动态码率，流量整形。
妮妮：听着好高大上，能详细说说吗？
小新：传输基于不可靠的UDP网络，也就是视频传输可能出现丢包，所以有自己的丢包重传机制，但是丢包重传的重传队列只有几百毫秒，也就是达不到秒级。
妮妮：听着是有点悬，那遇到网络短暂的抖动，假如短暂的阻塞了，怎么处理？
小新：遇到网络阻塞时，其没有阻塞缓存队列，是通过带宽预测算法估计出口速率，采用降低视频速率，降低视频编码质量的方式，有时候预测算法不及时，就可能出现少量的丢包情况。
妮妮：也就是观看者可能看见花屏，或抖动的画面。
小新：是的。而且Web RTC对编码也有限制，H264编码仅仅支持baseline profile和最低main的profile，也就是压缩率最低的方式。
妮妮：但是直播不是应该提供高清，且压缩比高的视频吗？
小新：你说的对，所以这方面Web RTC是满足不了的。
妮妮：虽然有这么多缺点，那Web RTC的直播推流有哪些实际的应用场景呢？
小新：如一些会议过程，主播需要用OBS推流加入某个会议，并直播出去，这种情况就需要Web RTC；或者某些平台仅支持WHIP的接入方式；再就就是工业界，一些设备推流用Web RTC技术，实现高实时性观看的需求。
妮妮：理解了，传统的直播协议RTMP暂时还不能被替代，Web RTC的直播推流仅仅在某些场景才会使用。
小新：是的，不过使用者要想要抗弱网的能力，可以考虑基于QUIC协议的WebTransport，当前已经有讨论在其上面承载媒体流的想法和协议设计了。
妮妮：技术真是在飞速的发展。如果大家觉得感兴趣，欢迎大家点赞，关注我们。
