音视频问题汇总–SDP和编码参数

问题背景

研发端小伙伴提报一个问题，在RTSP监控一台IPC时候，无法正常显示视频，一直处于黑屏中，需要协助一下。

为了快速确认问题所在，我们尝试了多个平台进行交叉验证，包括Android app，iOS app， PC端VLC，FFMPEG拉流等。验证过程汇中发现，PC端VLC可以支持，但是也需要10S左右才能出来画面。和FFMPEG设定RTSP Over TCP也可以显示，这时同步进行了抓包分析，IPC的信息如下：

音视频问题汇总--SDP和编码参数

问题分析

依据上面信息，团队小伙伴尝试分析原因，列举了几个怀疑点，逐一排查

（1）HEVC格式不兼容；

（2）服务器转发流异常；

（3）显示端异常；

经过多轮验证以及和服务端小伙伴一起确认，基本上可以逐步排除HEVC格式，服务端转发和显示问题。

然后又重新查看抓包，发现一个问题点：

音视频问题汇总--SDP和编码参数

原来HEVC的VPS，SPS，PPS等参数集竟然在SDP中描述的，而不是正常流程中在IDR帧之前发送。

理论支撑

经过网上资源查阅，最后发现原来这种方式是标准中规定的，我们自己不兼容而已。惭愧，惭愧，理论基础不到家。

在RFC 3984明确规定sprop-parameter-sets的参数

https://www.rfc-editor.org/rfc/pdfrfc/rfc3984.txt.pdf

大概意思：“sprop-parameter-sets”参数对 H.264 序列参数集 (SPS) 和图片参数集 (PPS) 网络适配层 NAL 单元进行编码。这些参数集提供解码 H.264 比特流所需的基本信息；在 SDP 中对它们进行编码可确保它们可靠地交付。

“sprop-parameter-sets”参数可以编码为源参数。但是，如果 sprop-parameter-sets 参数也作为媒体参数存在，则为每个源描述的 H.264 参数集必须包括为媒体描述的所有 H.264 参数集。

在 SDP answer中，呼叫端的“sprop-parameter-sets”必须遵循与媒体相同保持一致。即，answer中描述的源参数集必须是协商中媒体参数集的超集，如果协商指示媒体的“parameter-add=0”（false），则相应的answer中必须不要为任何源添加额外的参数集。

音视频问题汇总--SDP和编码参数

在8.3中给出实例，如下

音视频问题汇总--SDP和编码参数

解决方案

既然查到问题所在了，那就是做一下兼容即可。将VPS，SPS，PPS等数据做一下解析送解码前做一下初始化就可以，具体方法同步给研发端。

参考代码

HEVC/H265解析：

hevc_sdp_parse_fmtp_config() 函数用于解析 HEVC 视频流的 SDP（会话描述协议）FTMP（格式/有效负载类型/编码参数）配置。该函数将一个 AVFormatContext 指针、一个 AVStream 指针、一个 PayloadContext 指针、一个指向 SDP 属性名称的指针和一个指向 SDP 属性值的指针作为其参数。

音视频问题汇总--SDP和编码参数

AVC/H264解析

sdp_parse_fmtp_config_h264() 函数用于解析 H.264 视频流的 SDP（会话描述协议）FTMP（格式/负载类型/编码参数）配置。该函数将一个 AVFormatContext 指针、一个 AVStream 指针、一个 PayloadContext 指针、一个指向 SDP 属性名称的指针和一个指向 SDP 属性值的指针作为其参数。

音视频问题汇总--SDP和编码参数

ff_h264_parse_sprop_parameter_sets

ff_h264_parse_sprop_parameter_sets() 函数用于从字符串中解析 H.264 SPROP（序列参数集和图片参数集）参数集。该函数采用一个 AVFormatContext 指针，一个指向将存储解码参数集的缓冲区的指针，一个指向将存储缓冲区大小的整数的指针，以及一个指向包含参数集的字符串的指针争论。

特殊说明

Base64 是一种二进制到文本的编码方案，通过将二进制数据转换为 64 个字符的字母表来以文本形式表示二进制数据。它通常用于对需要通过不支持二进制数据的介质传输的数据进行编码，例如电子邮件或 HTTP。

Base64 编码使用由以下字符组成的 64 个字符的字母表：

音视频问题汇总--SDP和编码参数

为了对二进制数据进行编码，每个 8 位字节被转换为 3 个 Base64 字符。每个字节的前 6 位用于从 Base64 字母表中选择一个字符，最后 2 位用于从 Base64 字母表的子集中选择一个字符。

例如，二进制字节 10101010 被转换为 Base64 字符“RTQ”。

Base64解码是Base64编码的逆过程。它将 Base64 编码的字符串转换回其原始二进制形式。更多内容可以参考其他博主文章，本文不再赘述。

总结

Request for Comments (RFC) 文档不仅是关于 Internet 标准的文档，而且不限于 TCP/IP 的范围。它几乎囊括了与计算机通信相关的所有内容，充分反映了互联网研究发展的过程。RFC 文档不具有法律约束力，但它们被认为是有关 Internet 的权威信息来源。工程师、研究人员和其他技术专业人员使用 RFC 文档来了解 Internet 的工作原理并开发可用于改进 Internet 的新技术。

参考资料

https://stackoverflow.com/questions/10606072/syntax-of-h-264-sps-pps-in-sip-sdp-offer

https://www.ietf.org/rfc/rfc3984.txt

https://www.cnblogs.com/lidabo/p/6553305.html

作者信息：我是一枚爱跑步的程序猿，维护公众号和知乎专栏《MediaStack》，有兴趣可以关注，一起学习音视频知识，时不时分享实战经验。