rtp rtcp h264相关

最新推荐文章于 2023-08-17 17:46:32 发布

sun007700

最新推荐文章于 2023-08-17 17:46:32 发布

阅读量201

点赞数

分类专栏：视频

本文链接：https://blog.csdn.net/sun007700/article/details/108256687

版权

视频专栏收录该内容

126 篇文章 3 订阅

订阅专栏

H.26L中的Access unit结构分析

https://www.xuebuyuan.com/1722276.html

RTCP协议详解

https://blog.csdn.net/wanglf1986/article/details/52674378

H264的I/P/B帧类型判断(一)

https://blog.csdn.net/zhuweigangzwg/article/details/44152239

https://tools.ietf.org/html/rfc8285

RTP封装h264

https://www.jianshu.com/p/a19f3e63b433

H264 ES PS TS 流的区别

https://zhuanlan.zhihu.com/p/25701746

H264分层编码SVC

https://www.cnblogs.com/1234abcdttttjy001/p/11711953.html

RTP协议全解析（H264码流和PS流）

https://www.cnblogs.com/review/articles/6201988.html

https://www.cnblogs.com/lidabo/p/6553297.html

H264的start code是什么？

https://www.cnblogs.com/ranson7zop/p/7603588.html

H.264编码时，在每个NAL前添加起始码（一帧的开始则用4位字节表示，ox00000001,否则用3位字节表示ox000001），解码器在码流中检测到起始码，当前NAL结束。为了防止NAL内部出现0x000001的数据，h.264又提出'防止竞争 emulation prevention"机制，在编码完一个NAL时，如果检测出有连续两个0x00字节，就在后面插入一个0x03。当解码器在NAL内部检测到0x000003的数据，就把0x03抛弃，恢复原始数据。

0x000000 >>>>>> 0x00000300

0x000001 >>>>>> 0x00000301

0x000002 >>>>>> 0x00000302

0x000003 >>>>>> 0x00000303

h264 丢包花屏处理的一个想法

https://blog.csdn.net/freejs/article/details/84375715?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase

H264 数据帧理解（转载总结）

https://blog.csdn.net/sjin_1314/article/details/40989173?utm_medium=distribute.pc_aggpage_search_result.none-task-blog-2~all~first_rank_v2~rank_v25-1-40989173.nonecase&utm_term=h264%20%E4%B8%80%E5%B8%A7%20%E6%95%B0%E6%8D%AE%E9%87%8F

https://www.csdn.net/gather_22/MtjaEgzsNjIzOTgtYmxvZwO0O0OO0O0O.html

参考

https://github.com/gezzjsc/Wheel/blob/ac21512f720f028178fefb00b469949fbc719605/rtpH264.h

rtcp头

  uint32_t blockcount :5;
  uint32_t padding :1;
  uint32_t version :2;
  uint32_t packettype :8;
  uint32_t length :16;
  uint32_t ssrc;

inline bool isRtcp(void) {
    return (packettype >= RTCP_MIN_PT && packettype <= RTCP_MAX_PT);
  }

#define RTCP_MIN_PT         194  // per https://tools.ietf.org/html/rfc5761
#define RTCP_MAX_PT         223

#define RTCP_Sender_PT       200  // RTCP Sender Report
#define RTCP_Receiver_PT     201  // RTCP Receiver Report
#define RTCP_SDES_PT         202
#define RTCP_BYE             203
#define RTCP_APP             204
#define RTCP_RTP_Feedback_PT 205  // RTCP Transport Layer Feedback Packet
#define RTCP_PS_Feedback_PT  206  // RTCP Payload Specific Feedback Packet

#define RTCP_PLI_FMT           1
#define RTCP_SLI_FMT           2
#define RTCP_FIR_FMT           4
#define RTCP_AFB              15

rtt_stats

https://www.csdn.net/gather_22/MtjaEgzsNjIzOTgtYmxvZwO0O0OO0O0O.html

H264 数据帧理解（转载总结）

根据H.264的不同类别，编码器会使用不同类型的帧，例如I帧、P帧和B帧。

I帧（帧内编码帧）是一种自带全部信息的独立帧，无需参考其它图像便可独立进行解码。视频序列中的第一个帧始终都是I帧。如果所传输的比特流遭到破坏，则需要将I帧用作新查看器的起始点或重新同步点。I帧可以用来实现快进、快退以及其它随机访问功能。如果新的客户端将参与查看视频流，编码器将以相同的时间间隔或者根据要求自动插入I帧。I帧的缺点在于它们会占用更多的数据位，但从另一方面看，I帧不会产生可觉察的模糊现象。I帧是P帧和B帧的参考帧；I帧是组GOP的参考帧，在一组中只有一个I帧；不考虑运动矢量，数据量比较大；

P帧（帧间预测编码帧）需要参考前面的I帧和/或P帧的不同部分才能进行编码。与I帧相比，P帧通常占用更少的数据位，但其缺点是，由于P帧对前面的P和I参考帧有着复杂的依赖性，因此对传输错误非常敏感。P帧属于前向预测的帧间编码，它只参考前面最靠近它的I帧或者P帧。

H.264编解码器中，量化参数QP和量化步长Qstep的关系：

量化步长Qstep共有52个值。（对于亮度编码而言）

量化参数QP是量化步长Qstep的序号，取值0~51。

QP取最小值0 时，表示量化最精细；相反，QP取最大值51时，表示量化是最粗糙的。

Qstep随着QP的增加而增加，QP每增加6，Qstep增加一倍。

对于色度编码，QP的最大值是39。