qq_41681715的博客

由于网上写rtmp协议建立过程的文章比较多，这里就不再赘述，直接从发送发送音频包和视频包写起。 如果rtmp在推流链路或者拉流链路上要发送音频包和视频包数据，在发送音视频包前需要先发送onMetaData元数据包，告诉接收方发送视频的宽高信息，以及声明音频和视频的CodecID，如下图：根据flv_v10_1.pdf的描述，aac音频的SoundFormat为10，即上图中的audiocodecid的值，flv文档部分截图如下：H264视频的CodecID为10，即rtm...

H265 NALU类型简单介绍：F:必须为0，表示有效；为1的话表示无效。Type:6-bits NALType 确定NAL的类型，其中VCL NAL和non-VCL NAL各有32类。0-31是vcl nal单元；32-63，是非vcl nal单元。VCL是指携带编码数据的数据流，而non-VCL则是控制数据流。LayerID：表示NAL所在的Access unit所属的层，该字段是为了HEVC的继续扩展设置。也就是目前都是0，以后的扩展可能会用到。TID：3 bits通常情况下，F

做音视频的同学应该都知道，基于RTP/RTCP传输流媒体，难点在于怎么把Qos做好。比较常用的基于RTCP反馈机制的Qos策略有NACK、PLI和FIR，再网络比较拥塞的情况下，使用NACK、PLI或FIR机制，可能不会改善网络拥塞情况，反而可能会增加网络拥塞的程度，这时根据网络带宽的具体情况，适当调整发送码流可能会达到更好的效果，这里我们主要说下RTCP的REMB，根据REMB文档的规范https://tools.ietf.org/pdf/draft-alvestrand-rmcat-remb-03.pd

学过TCP通信原理的同学都知道，TCP没法送一个TCP报文，TCP协议栈都要等对端的ACK确认，才能确定是否进行报文重传或者发送下一包数据；然而RTCP的NACK重传机制与TCP的确认机制整好相反，当RTP接收端发现某一包数据或者N包数据确实没有收到，即在经过中间网络设备时丢掉了，接收端才会向发送端发送RTCP的NACK报文，向发送端要求重传相应的RTP包，NACK报文如下：特别注意，使用NACK重传机制的收发双发，RTP都有一个发送缓冲区和接收缓冲区，缓冲区有缓冲区大小，发送太迟的NACK申请报文

NAL的英文全称为Network Abstract Layer，即网络抽象层，在H264/AVC视频编解码标准中，整个系统框架分为两个层面，视频编解码层面(VCL)和网络抽象层面(NAL)。VCL负责有效表示视频数据内容，NAL负责格式化数据并加上相应的头信息，以保证数据适合各种信道和存储介质上的传输。NAL单元NALU是NAL的基本语法结构，它包含一个字节的头信息和一系列来自VCL的原始字节载序列载荷(RBSP)的字节流。H264使用RTP传输时，以SPS和PPS开头，如下图：H264帧由N.