FUA的h264打包模式 [英] h264 packetization mode for FUA

问题描述

我们已经遇到了一些互操作性问题，其中，市场上两个端点所要求的视频模式几乎没有什么不同，并且仅了解H.264打包模式(FUA类型)(即FU -A NAL单元类型). (而其他人在接收到最终类型的有效载荷时不会播放视频)

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)

有人知道这种FUA类型的打包模式吗?它与RFC3984中定义的打包模式0,1,2有何不同?视频编码器/解码器是否支持它，如何在SIP SDP会话中适当地发送信号，即使通过SIP B2BUA遍历属性也不会更改?

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?

推荐答案

FUA用于打包模式1& 2.打包模式默认为0(单NAL模式)；如果双方都同意模式1或2，则当NAL超过UDP MTU或配置的最大数据包大小时，通常会看到FU-A.

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.

打包/解包层应采用NAL并在需要时生成FU-A，并在接收时采用一系列FU-A并重组NAL以馈入解码器.

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.

请参阅RFC 3984和 RFC 3984bis (我是作者).

See RFC 3984 and RFC 3984bis (of which I'm an author).

B2BUA不应接受或提供尚未准备好处理的打包模式，尽管它可能只是传递了另一个UA的要约/答案.

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.

还请注意，UA(如果符合RFC 3984)必须支持分组模式0，尽管不需要在INVITE上提供它.

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.

这篇关于FUA的h264打包模式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！