最近在研究NMSv3 接入WebRTC协议，以实现浏览器跨平台无插件高清推流，服务端转http-flv，rtmp等。首选视频编码当然是H264了，这样服务端只需做音频实时转码OPUS->AAC即可。

在解析RTP包内H264负载时遇到各种坑，这里记录一下。

环境：

• OS：MacOS 10.14.6
• Chrome : 80.0.3987.106

一、查看默认编码器参数，浏览器访问 chrome://gpu/

Video Acceleration Information

Decode h264 baseline	16×16 to 4096×2160 pixels
Decode h264 extended	16×16 to 4096×2160 pixels
Decode h264 main	16×16 to 4096×2160 pixels
Decode h264 high	16×16 to 4096×2160 pixels
Encode h264 baseline	0x0 to 4096×2160 pixels, and/or 30.000 fps
Encode h264 main	0x0 to 4096×2160 pixels, and/or 30.000 fps
Encode h264 high	0x0 to 4096×2160 pixels, and/or 30.000 fps

此刻，RTP包的负载，I包和P包使用FU-A，SPS、PPS采用STAP-A打包。

二、通过访问chrome://flags/ ，将Hardware-accelerated video encode 选项设置为Disable，关闭硬件编码，模拟无硬件加速的环境。

此刻，WebRTC采用软件编码，RTP包的负载全部采用SingleNalUnit打包。但是，在解析时发现，每一帧数据过大时会被拆分。

通过打开Chrome调试日志，可以看到采用的版本是OpenH264 1.9

[44343:19715:0216/100558.325043:INFO:h264_encoder_impl.cc(576)] OpenH264 version is 1.9
[44343:19715:0216/100558.325058:INFO:h264_encoder_impl.cc(586)] Encoder is configured with NALU constraint: 1188 bytes

定位WebRTC源码 modules/video_coding/codecs/h264/h264_encoder_impl.cc

可以看到，在编码时便设置了OpenH264的编码参数

encoder_params.sSpatialLayers[0].sSliceArgument.uiSliceSizeConstraint =
static_cast(max_payload_size_);