FUA 的 h264 打包模式
我们遇到了几个互操作问题，其中，市场上的几个端点所需的视频模式略有不同，并且仅理解 H.264 分组模式（FUA 类型）（即 FU -A NAL 单元类型）。（而其他接收到 fu-a nal 类型有效负载时不播放视频）
有谁知道这种 FUA 类型的打包模式是什么？它与 RFC3984 中定义的打包模式 0、1、2 有什么不同？视频编码器/解码器是否支持它，如何在 SIP SDP 会话中正确地发出信号，其中即使遍历 SIP B2BUA 属性也不会改变？
We have got into couple of interop issues where, The video mode that is required by couple of endpoints in market are little different and only understands H.264 packetization modes (FUA type) (i.e) FU -A NAL unit type.(while others do not play the video on receiving a fu-a nal type payload)
Does anyone know what is this FUA type of packetization mode? How is it different from packetization modes 0,1,2 as defined in RFC3984? Is the video encoder/decoder supports it, how can it be appropriately signalled in SIP SDP session wherein the attributes do not get changed even when traversing through SIP B2BUAs?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
FUA 用于分组模式 1 和 2。 2. packetization-mode默认为0（单NAL模式）；如果双方都同意模式 1 或 2，当 NAL 超过 UDP MTU 或配置的最大数据包大小时，您通常会看到 FU-A。
打包/解包层应在需要时获取 NAL 并生成 FU-A，并在接收时获取一系列 FU-A 并重新组装 NAL 以馈送到解码器。
请参阅 RFC 3984 和 RFC 3984bis（我是作者）。
B2BUA 不应接受或提供它尚未准备好处理的打包模式，尽管它可能只是简单地传递来自其他 UA 的提供/应答。
另请注意（如果符合 RFC 3984）UA 必须支持打包模式 0，尽管不需要在 INVITE 上提供它。
FUA is used in packetization modes 1 & 2. packetization-mode defaults to 0 (single-NAL mode); if both sides agree to modes 1 or 2 you will typically see an FU-A when a NAL exceeds the UDP MTU or configured maximum packet size.
The packetization/de-packetization layer should take NALs and generate FU-A's when needed, and on reception take a series of FU-A's and reassemble a NAL to feed to the decoder.
See RFC 3984 and RFC 3984bis (of which I'm an author).
A B2BUA should not accept or offer a packetization-mode it's not ready to process, though it may be simply passing through the offer/answer from the other UA.
Also note that (if compliant with RFC 3984) a UA must support packetization-mode 0, though it's not required to offer it on an INVITE.
我不确定我是否正确理解你的问题，但 FU-A 不是打包模式，它只是表示 NAL 单元是分段 Nal 单元，即 NAL 单元被分段为多个 RTP 数据包。 RFC3984 表 3 显示 NAL FU-A 只能用于交错和非交错打包模式（模式 1 和 2），即不能用于单 Nal 单元模式（模式 0）。
至于编码器/解码器支持：如果SDP信号打包模式1或2，则意味着RTP流中可能存在FU-As。这不会影响解码器，尽管 RFC3894 第 7.1 节：“如果解封装的数据包是 FU-A，则分段 NAL 单元的所有片段都会连接起来并传递给解码器。”
我不知道。不理解与 SIP B2BUA、SDP 信号分组模式相关的问题的最后部分，并且基于 RTP 接收器必须能够处理 RFC3984 中指定的不同 NAL 单元类型。
I'm not sure if I understand your question correctly, but FU-A is not a packetization mode, it just signals that the NAL unit is a Fragmentation Nal Unit i.e. a NAL unit is fragmented over several RTP packets. RFC3984 table 3 shows that NAL FU-A can only be used in the interleaved and non-interleaved packetization modes (modes 1 and 2) i.e. not in single Nal Unit mode (mode 0).
As for encoder/decoder support: if the SDP signals packetization mode 1 or 2, it means that there might be FU-As in the RTP stream. This won't affect the decoder though RFC3894 section 7.1: "If a decapsulated packet is an FU-A, all the fragments of the fragmented NAL unit are concatenated and passed to the decoder."
I don't understand the last part of your question relating to the SIP B2BUAs, the SDP signals packetization modes and based on that the RTP receiver must be able to handle the different NAL unit types that are specified in RFC3984.