rtp封装h264的问题
GB28181的TCP码流遵循的标准是RFC4571（RTP OVER TCP）：2字节长度+rtp或者rtcp packet
RTSP中tcp码流是遵循的RFC2326标准 ：1字节的$符号+1字节的channel number + 2字节长度+rtp或者rtcp packet
udp直接通过一个端口发送rtp packet，国标ps流就是采用的音频视频流一个端口发送的
或者通过rtsp中的音频、视频两个端口分开发送的方式。
rfc3984中对于大于mtu的报文采用分片的方式发送h264, h265数据，这些都有rfc文档说明的
我的问题是：我看到有的报文采用的是直接h264原始数据切分成多个1400自己的数据，然后直接udp rtp packet发送，例如：h264基本数据为0x00 00 00 01 27 33 44 55 66 77 88 99 10，直接切分rtp header + 0x00 00 00 01 27 33 44； rtp header + 55 66 77 88 99 10；没有进行fu-a的分片，直接发送基本流，请问采用的那个rfc文档？并给出解释？
引用chatgpt内容作答：
根据您的描述，您提到了两个不同的方式来封装 H.264 数据并发送 RTP 包，一个是将 H.264 数据直接切分成多个 1400 字节的数据，另一个是使用 Fragmentation Units Type A (FU-A) 进行分片。让我为您解释一下这两种方式。
1、直接切分数据： 这种方式没有使用 FU-A 分片，而是将 H.264 数据直接切分成多个 1400 字节的数据块，然后将这些数据块放入 RTP 包中发送。这种方式没有使用特定的 RFC 文档，而是可能是一种特定应用场景下的自定义方式。不同的应用可能会根据自身需求和传输环境来采用这种方式。
2、FU-A 分片： 采用 H.264 视频帧的分片方式是根据 RFC 3984 中的建议进行的。FU-A 是 Fragmentation Units Type A 的简写，它是一种将大的 H.264 帧切分成多个较小的分片进行传输的方法。每个 FU-A 分片都有一个特定的头部，其中包含了一些关键信息，如分片的开始标志、结束标志、NAL 单元类型等。这种方式的优点在于它能够适应网络状况的变化，并能够更灵活地进行传输和重组。这个方式在实时传输协议（RTP）中被广泛使用。
从您的描述来看，第一种方式可能是一种特定场景下的自定义实现，而第二种方式则更符合标准的 RTP 和 H.264 分片协议。您可以根据您的应用需求和网络环境选择适合的方式来进行数据封装和传输。
对于大于MTU大小的H.264视频数据在RTP over UDP中进行封装传输,RFC 3984提供了Fragmentation Units (FUs)的分片机制。
RFC 3984 中规定,如果RTP payload大小大于MTU,则发送端需要将其拆分为多个FUs进行传送。每个FU都需要加上FU indicator和FU header。
FU indicator有两种:
- FU-A - 用于非起始FU,表示后续FU段。
- FU-B - 用于起始FU,表示后续FU的开始。
FU header包含FU payload的信息,如起始位和结束位等。
所以正确的做法应该是:
将大块H.264数据拆分成多个FU payloads,每个在MTU以下。
对起始FU payload加上FU-B indicator 和 FU header。
对后续非起始FU payload加上FU-A indicator 和 FU header。
每个FU payload都作为RTP payload发送。
直接切割H.264数据,不加FU indicator和header,然后打包成RTP发送是不符合RFC 3984要求的。这种方式接收端无法区分FU的边界,无法还原原始H.264数据。
所以您看到的直接切分H.264并RTP发送的方案,是不规范的实现,不建议使用。应该按RFC 3984实现FU的细粒度分片,以便接收端能够正确解析和还原H.264视频流。
援引GPT回答：
根据您提供的信息，您描述的是将H.264原始数据切分成多个1400字节的数据，然后直接通过UDP发送RTP包。这种方式不符合任何RFC文档中的规范。
根据RFC 6184中的定义，当H.264数据包大小超过MTU（最大传输单元）时，应使用H.264的分片单元（NALU）的FU-A分片模式进行传输。FU-A分片模式将大的NALU分割为多个较小的RTP包，并使用特定的头部信息指示分片的顺序和完整性。
而根据RFC 3550中的定义，RTP协议是用于实时传输的，它提供了有序、时间戳和完整性检查等特性。因此，直接将H.264原始数据切分成多个1400字节的数据，并通过UDP发送RTP包，会导致丢失这些特性，可能会影响数据的正确性和时序性。
因此，如果您需要符合标准的传输H.264数据，建议使用RFC 6184中定义的FU-A分片模式，并将RTP包封装在UDP中进行传输。
每一次解答都是一次用心理解的过程，期望对你有所帮助。
参考结合AI智能库，如有帮助，恭请采纳。
这种直接将H.264原始数据切分并使用RTP发送的方式并不是遵循RFC3984或RFC2326等文档的标准方式。这种方式可能是基于特定的应用或设备实现，而不是通用的网络协议。
在RFC3984中，对于大于MTU的H.264数据，需要采用分片的方式发送，以避免分片和重组带来的开销和复杂性。而这种方式没有进行分片，可能导致传输过程中分片和重组的问题。
在RTSP协议中，音频和视频数据通常通过不同的端口发送，并且使用RTP或RTCP协议进行传输。这种方式直接将H.264原始数据切分并使用RTP发送，可能不是标准的RTSP协议实现。
因此，这种直接将H.264原始数据切分并使用RTP发送的方式可能不是遵循通用的网络协议标准，而是基于特定的应用或设备实现。具体的实现细节和规范应该参考相关的设备或应用文档。
这种直接将H.264原始数据切分并使用RTP发送的方式并不是遵循RFC3984或RFC2326等文档的标准方式。这种方式可能是基于特定的应用或设备实现，而不是通用的网络协议。
RTP（Real-time Transport Protocol）是一种网络传输协议，主要用于实时传输音视频数据。H.264是一种广泛采用的视频编码标准，具有高压缩率和高质量的特点。在实时视频传输过程中，通常需要将H.264视频流封装为RTP数据包，以便在网络上进行传输和接收。
RTP封装H.264视频流的过程可以分为以下几个步骤：
- 分解H.264视频帧
首先，将H.264视频流分解为一系列视频帧。通常，H.264视频流包括I帧、P帧和B帧。其中I帧为关键帧，具有完整的图像信息；P帧和B帧为非关键帧，只包含变化的信息。
- 将视频帧封装为NALU（网络抽象层单元）
将视频帧封装为NALU单元。NALU单元是H.264编码标准中的一个基本单元，包括一个头部和一个载荷。头部包括一些描述NALU内容和类型的信息，载荷则包括实际的视频数据。
- 将NALU单元封装为RTP数据包
将NALU单元封装为RTP数据包。RTP数据包包括一个头部和一个载荷。头部包含一些描述RTP数据包的信息，如序列号、时间戳等；载荷则是NALU单元。此外，RTP数据包还包括一个RTP包头扩展，用于传输一些额外的信息，如帧类型、QP值等。
- 在RTP数据包中添加RTP和RTCP协议
在封装好的RTP数据包中，需要添加RTP和RTCP协议。RTP协议用于实时传输音视频数据，提供序列号、时间戳等信息，以保证传输的可靠性和时效性；RTCP协议用于监控和控制RTP传输过程，提供丢包率、延迟等信息。
总体来说，RTP封装H.264视频流的过程比较复杂，需要对视频流进行分解、封装和添加协议等多个步骤。但是，采用RTP协议可以保证视频传输的可靠性和时效性，适合于实时视频传输场景。
您提到的情况可能是在使用自定义的方案来传输H.264视频流，没有遵循RFC文档的规定。在这种情况下，可能没有特定的RFC文档可以解释这种行为。
根据RFC3984，H.264视频流需要进行分片才能通过UDP传输，这是因为H.264的基本数据单元是NAL单元（Network Abstraction Layer），其长度可能超过UDP数据报的最大传输单元（MTU）。因此，RFC3984规定了一种称为"Fragmented Unit (FU)"的机制，用于将NAL单元分片传输。
在RFC3984中，H.264的基本数据需要被封装在FU-A（Fragmentation Unit for Adaptation）或FU-B（Fragmentation Unit for non-Adaptation）中，然后才能通过UDP传输。FU-A适用于需要插入填充字节才能适应MTU的情况，而FU-B适用于不需要填充字节的情况。
如果您的系统没有按照RFC3984规定进行分片传输，而是直接将H.264基本数据切分成多个1400字节的数据并发送，这可能会导致数据传输过程中的分片和重组问题。因此，建议您在实现UDP传输方案时遵循RFC3984规定。
另外，RFC 4571也规定了RTP over TCP的传输方式，其中要求在RTP包头之后添加一个2字节的长度字段。根据您提供的信息，GB28181的TCP码流遵循RFC 4571标准，因此在这种情况下，如果直接将H.264基本数据切分并发送，可能会违反RFC的规定。
另外，需要指出的是，虽然遵循RFC文档的规定是很重要的，但在某些情况下，可能需要根据实际需求进行自定义方案的调整。在这种情况下，需要仔细评估自定义方案对数据传输的影响，并确保方案的可靠性和稳定性。
如果您是在特定的环境下开发或使用系统，建议参考相关的技术规范或文档，以了解所需的传输方式和数据格式。如果您有任何关于具体技术实现的疑问，我将尽力提供帮助。
参考GPT回答 ： 根据您的描述，您提到的报文直接将H.264原始数据切分成多个1400字节大小的数据，并通过UDP发送。这种方式不遵循RFC 3984中关于H.264的分片传输规范，也不是标准的RTP传输方式。
RFC 3984定义的H.264传输使用了基于RTP的分片（Fragmentation Units, FU），它将大于MTU（最大传输单元）的H.264帧进行分片并使用特定的RTP扩展包头来指示分片的顺序和类型。这样做的目的是为了确保在UDP传输过程中能够正确地重组H.264帧。
相较于直接将原始H.264数据切割成自定义的数据包进行UDP传输，使用基于RTP的分片传输有以下优势：
确保数据的完整性：RTP分片传输提供了机制来确保大型H.264帧的完整性，并防止数据的丢失或损坏。
兼容性：RFC 3984定义的H.264分片传输遵循了一套标准化的协议规范，以确保兼容性和互操作性。
码流控制：RTP分片传输允许对码流进行灵活的控制，例如调整分片大小、带宽管理和优先级控制。
对于RTP封装H264的问题，每个RTP数据包包含一个H.264 NAL单元。H.264 NAL单元之间有一个特殊的起始码，称为"0x00000001"或"0x000001"。在使用TCP传输RTP数据流时，RFC4571规定了每个RTP或RTCP数据包的前面必须是2个字节的长度字段。
而针对RTSP中TCP码流采用的RFC2326标准，每个RTP数据包之前是由一个字节的$符号和一个字节的长度组成的。
因此，在实际的应用中，需要根据不同的传输协议选择不同的RTP封装方式。
这种直接将H.264原始数据切分成多个1400字节的数据，然后使用UDP RTP packet发送的方式并不遵循RFC3984中关于RTP负载格式的规定。根据RFC3984的规定，当H.264数据超过MTU大小时，应该使用FU-A机制进行分片传输。
安装规范传输才需要遵循文档要求
数据超过MTU大小时需要分片传输