跳到主要内容

8.2.2. Usage with the SDP Offer/Answer Model (与 SDP Offer/Answer 模型一起使用)

8.2.2. Usage with the SDP Offer/Answer Model (与 SDP Offer/Answer 模型一起使用)​

当为单播用途在 Offer/Answer 模型 [8] 中通过 SDP 以 RTP 提供 H.264 时, 适用下列限制与规则:

  • 标识 H.264 媒体格式配置的参数是 profile-level-id 与 packetization-mode. 这些媒体格式配置参数 (profile-level-id 的 level 部分除外) 必须对称使用, 即应答方 (answerer) 必须要么保留全部配置参数, 要么在有一个或多个参数值不受支持时完全删除该媒体格式 (载荷类型). 注意 profile-level-id 的 level 部分包含 level_idc, 以及当 profile_idc 等于 66, 77 或 88 时用于指示 Level 1b 的 profile-iop 的第 4 位 (constraint_set3_flag). profile-level-id 的 level 部分可以变更.

资料性说明: 对称使用的要求不适用于 profile-level-id 的 level 部分, 也不适用于其他流属性与能力参数.

资料性说明: 在 H.264 [1] 中, 除 Level 1b 外, 所有 level 均等于 level_idc 除以 10. Level 1b 高于 Level 1.0 但低于 Level 1.1, 以特别方式信令, 因为该 level 是在 Level 1.0 与 Level 1.1 之后才规定的. 对 Baseline, Main 与 Extended profile (profile_idc 分别为 66, 77, 88), Level 1b 由 level_idc 等于 11 (即与 Level 1.1 相同) 且 constraint_set3_flag 等于 1 指示. 对其他 profile, Level 1b 由 level_idc 等于 9 指示 (但注意这些 profile 的 Level 1b 仍高于 Level 1, Level 1 的 level_idc 等于 10, 且低于 Level 1.1). 在 SDP Offer/Answer 中, 对报价 (offer) 的应答可以指示不高于报价中所示 level 的 level. 由于 Level 1b 的特别指示方式, 当 profile_idc 等于 66, 77 或 88 且 level_idc 等于 11 时, 报价方与应答方必须检查参数 profile-level-id 中间字节的第 4 位 (constraint_set3_flag).

为简化这些配置的处理与匹配, 报价中使用的同一 RTP 载荷类型编号在应答中也应使用, 见 [8]. 除非配置与报价中完全相同, 否则应答不得包含报价中已使用的载荷类型编号.

资料性说明: 当报价方收到应答时, 必须根据媒体类型 (即 video/H264) 以及上述媒体配置参数, 将未在报价中声明的载荷类型与其已声明的载荷类型比较. 从而判断有关配置是新的还是与已报价配置等价, 因为应答中可能使用不同的载荷类型编号.

  • 当出现时, 参数 max-recv-level 声明接收所支持的最高 level. 若未出现 max-recv-level, 接收所支持的最高 level 等于 profile-level-id 的 level 部分所指示的默认 level. 当出现时, max-recv-level 必须高于默认 level.

  • 参数 level-asymmetry-allowed 指示是否允许 level 不对称.

若在报价或应答任一侧 level-asymmetry-allowed 等于 0 (或未出现), 则不允许 level 不对称. 此时, 从报价方到应答方方向使用的 level 必须与相反方向相同, 共同使用的 level 等于报价与应答中默认 level 的较低者.

否则, 报价与应答中 level-asymmetry-allowed 均等于 1, 允许 level 不对称. 此时, 报价方到应答方方向使用的 level 必须等于应答方接收所支持的最高 level, 应答方到报价方方向使用的 level 必须等于报价方接收所支持的最高 level.

当不允许 level 不对称时, 不允许 level 升级, 即应答中的默认 level 必须小于或等于报价中的默认 level.

  • 参数 sprop-deint-buf-req, sprop-interleaving-depth, sprop-max-don-diff 与 sprop-init-buf-time 描述报价方或应答方就某一媒体格式配置所发送的 RTP 分组流的属性. 这与 Offer/Answer 参数的通常用法不同: 通常此类参数声明报价方或应答方能够接收的流的属性. 对 H.264, 报价方假定应答方能够接收使用所报价配置编码的媒体.

资料性说明: 上述参数适用于声明实体以相同配置发送的任意流, 即它们依赖于源. 取值绑定于配置而非载荷类型, 在发送时可能需要应用到另一载荷类型.

  • 能力参数 max-mbps, max-smbps, max-fs, max-cpb, max-dpb, max-br, redundant-pic-cap, max-rcmd-nalu-size, sar-understood 与 sar-supported 可用于进一步声明报价方或应答方的接收能力. 当方向属性为 sendonly 且这些参数描述报价方或应答方对接收流可接受限制时, 不得出现这些参数.

  • 对交错 H.264 流, 报价方必须在报价中包含去交错缓存大小 sprop-deint-buf-req. 为使报价方与应答方能够相互告知接收流的去交错缓存能力, 建议双方均包含 deint-buf-cap. 对交错流, 在接收方能力未知时, 还建议考虑提供具有不同缓存需求的多个载荷类型.

  • 当出现时 (包含在 SDP 的 a=fmtp 行中, 或按 [9] 第 6.3 节通过 fmtp 源属性传送), sprop-parameter-sets 或 sprop-level-parameter-sets 参数用于参数集的带外传送. 但是, 在使用参数集带外传送时, 仍可以额外带内传送参数集.

应答方对其发送的流可以使用带外或带内参数集传送, 无论报价方到应答方方向是否已使用带外参数集传送. 应答中包含的参数集与报价中的参数集相互独立, 因为它们用于解码两路不同的视频流, 一路从应答方到报价方, 另一路相反.

下列规则适用于报价方到应答方方向的参数集传送.

  • 报价可以包含 sprop-parameter-sets 与 sprop-level-parameter-sets 之一或两者. 若报价中两者皆无, 则仅使用参数集带内传送.

  • 若应答中 in-band-parameter-sets 等于 1, 则报价方必须带内传送参数集. 否则适用下列规则.

  • 若报价方到应答方方向使用的 level 等于报价中的默认 level, 则:

    • 当报价的 a=fmtp 行中包含 sprop-parameter-sets 时, 应答方必须准备好使用其中包含的参数集解码入局 NAL 单元流.

    • 当报价通过 fmtp 源属性传送 sprop-parameter-sets 时: 若应答包含 use-level-src-parameter-sets 等于 1 或包含 fmtp 源属性, 应答方必须准备好使用其中的参数集解码入局 NAL 单元流, 否则报价方必须带内传送参数集.

    • 当报价中无 sprop-parameter-sets 时, 报价方必须带内传送参数集.

    • 应答方必须忽略报价中出现的 sprop-level-parameter-sets (无论在 a=fmtp 行还是 fmtp 源属性中).

  • 否则, 报价方到应答方方向使用的 level 不等于报价中的默认 level, 则:

    • 应答方必须忽略报价中出现的 sprop-parameter-sets (无论在 a=fmtp 行还是 fmtp 源属性中).

    • 当应答中既无 use-level-src-parameter-sets 等于 1 也无 fmtp 源属性时, 应答方必须忽略报价中的 sprop-level-parameter-sets, 且报价方必须带内传送参数集.

    • 当应答中有 use-level-src-parameter-sets 等于 1 或有 fmtp 源属性时, 应答方必须准备好使用报价中 sprop-level-parameter-sets 内与所接受 level (即应答中的默认 level) 对应的参数集解码入局 NAL 单元流, 并忽略其中其余参数集.

    • 当报价的 sprop-level-parameter-sets 中不存在报价方到应答方方向所用 level 的参数集时, 报价方必须带内传送参数集.

下列规则适用于应答方到报价方方向的参数集传送.

  • 应答可以包含 sprop-parameter-sets 或 sprop-level-parameter-sets 之一, 不得同时包含两者. 若应答中两者皆无, 则仅使用带内传送.

  • 若报价中 in-band-parameter-sets 等于 1, 应答方不得在应答中包含 sprop-parameter-sets 或 sprop-level-parameter-sets, 且必须带内传送参数集. 否则适用下列规则.

  • 若应答方到报价方方向使用的 level 等于应答中的默认 level, 则:

    • 当应答的 a=fmtp 行中包含 sprop-parameter-sets 时, 报价方必须准备好使用其中的参数集解码入局 NAL 单元流.

    • 当应答通过 fmtp 源属性传送 sprop-parameter-sets 时: 若报价包含 use-level-src-parameter-sets 等于 1 或包含 fmtp 源属性, 报价方必须准备好使用其中的参数集解码入局 NAL 单元流, 否则应答方必须带内传送参数集.

    • 当应答中无 sprop-parameter-sets 时, 应答方必须带内传送参数集.

    • 报价方必须忽略应答中出现的 sprop-level-parameter-sets.

  • 否则, 应答方到报价方方向使用的 level 不等于应答中的默认 level, 则:

    • 报价方必须忽略应答中出现的 sprop-parameter-sets (无论在 SDP 的 a=fmtp 行还是 fmtp 源属性中).

    • 当报价中既无 use-level-src-parameter-sets 等于 1 也无 fmtp 源属性时, 报价方必须忽略应答中的 sprop-level-parameter-sets, 且应答方必须带内传送参数集.

    • 当报价中有 use-level-src-parameter-sets 等于 1 或有 fmtp 源属性时, 报价方必须准备好使用应答中 sprop-level-parameter-sets 内与应答方到报价方方向所用 level 对应的参数集解码入局 NAL 单元流, 并忽略其中其余参数集.

    • 当应答的 sprop-level-parameter-sets 中不存在该方向所用 level 的参数集时, 应答方必须带内传送参数集.

当按 [9] 第 6.3 节通过 fmtp 源属性传送 sprop-parameter-sets 或 sprop-level-parameter-sets 时, 参数的接收方必须存储其中与所接受 level 对应的参数集, 并将其与 fmtp 源属性所给出的源关联. 与某一源关联的参数集只能用于解码来自同一源的 RTP 分组中的 NAL 单元. 使用本机制时, 必须按 [9] 执行 SSRC 冲突检测与解决.

资料性说明: 通过 fmtp 源属性传送 sprop-parameter-sets 与 sprop-level-parameter-sets 可用于 Topo-Video-switch-MCU [29] 等拓扑以实现参数集带外传送.

对多播传送的流, 适用下列规则:

  • 媒体格式配置由 profile-level-id (含 level 部分) 与 packetization-mode 标识. 这些媒体格式配置参数 (含 profile-level-id 的 level 部分) 必须对称使用, 即应答方必须要么保留全部配置参数, 要么完全删除该媒体格式 (载荷类型). 这意味着多播下 Offer/Answer 中 profile-level-id 的 level 部分不可变更.

  • 为简化处理与匹配, 报价中使用的 RTP 载荷类型编号在应答中也应使用, 见 [8]. 除非配置与报价相同, 否则应答不得包含报价中已使用的载荷类型编号.

  • 收到的参数集必须与发起源关联, 且只能用于解码来自同一源的入局 NAL 单元流.

  • 其他参数的规则与单播相同, 只要遵守上述规则.

表 6 列出对不同方向属性必须如何解释各媒体类型参数.

表 6. 不同方向属性下参数的含义

参数sendrecvrecvonlysendonly
profile-level-idCCP
max-recv-levelRR-
packetization-modeCCP
sprop-deint-buf-reqP-P
sprop-interleaving-depthP-P
sprop-max-don-diffP-P
sprop-init-buf-timeP-P
max-mbpsRR-
max-smbpsRR-
max-fsRR-
max-cpbRR-
max-dpbRR-
max-brRR-
redundant-pic-capRR-
deint-buf-capRR-
max-rcmd-nalu-sizeRR-
sar-understoodRR-
sar-supportedRR-
in-band-parameter-setsRR-
use-level-src-parameter-setsRR-
level-asymmetry-allowedO--
sprop-parameter-setsS-S
sprop-level-parameter-setsS-S

图例:

  • C: 发送与接收流的配置
  • O: offer/answer 模式
  • P: 待发送流的属性
  • R: 接收方能力
  • S: 带外参数集
  • -: 不可用 (若出现, 应忽略)

用于声明接收方能力的参数一般可降级, 即它们表示发送方可能行为的上限. 因此, 发送方可以选择仅使用这些参数中较低或相等的值来设置其编码器.

声明配置点的参数不可变更, 单播时 profile-level-id 的 level 部分除外.

当声明发送方能力且声明中使用了不可降级参数时, 这些参数表示发送方愿意接收的流的可接受配置. 为获得高互操作性, 通常建议提供多种可选配置, 例如不同的分组化模式. 单一载荷类型无法提供多种配置. 因此, 当提供多种配置报价时, 每种报价需要关联各自的 RTP 载荷类型.

接收方应理解所有媒体类型参数, 即使仅支持载荷格式功能的一部分. 这确保接收方能理解对接收媒体的报价何时可降级为其所支持的范围.

应答方可以用额外媒体格式配置扩展报价. 但是, 为使其可用, 多数情况下需要报价方再次发出报价以提供媒体发送方将使用的流属性参数. 这也意味着报价方必须能够接收该媒体格式配置, 而不仅仅是发送.

若报价方希望发送与接收能力非对称, 可令 level-asymmetry-allowed 等于 1 以允许 level 不对称. 或者, 报价方可提供不同的 RTP 会话, 即分别声明为 recvonly 与 sendonly 的不同媒体行. 这可能对系统产生进一步影响, 并可能需要额外的外部语义来关联两条媒体行.

最后于 更新