H265(HEVC) nal 单元头介绍及rtp发送中的fu分组发送详解

2023-10-12 03:10

本文主要是介绍H265(HEVC) nal 单元头介绍及rtp发送中的fu分组发送详解,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

        首先来介绍下h265(HEVC)nal单元头,与h264的nal层相比,h265的nal unit header有两个字节构成,如下图所示:

从图中可以看出hHEVC的nal包结构与h264有明显的不同,hevc加入了nal所在的时间层的ID,取去除了nal_ref_idc,此信息合并到了naltype中,通常情况下F为0,layerid为0,TID为1。

        nal单元的类型有如下几种:

     

 enum NalUnitType
{NAL_UNIT_CODED_SLICE_TRAIL_N = 0,   // 0NAL_UNIT_CODED_SLICE_TRAIL_R,   // 1NAL_UNIT_CODED_SLICE_TSA_N,     // 2NAL_UNIT_CODED_SLICE_TLA,       // 3   // Current name in the spec: TSA_RNAL_UNIT_CODED_SLICE_STSA_N,    // 4NAL_UNIT_CODED_SLICE_STSA_R,    // 5NAL_UNIT_CODED_SLICE_RADL_N,    // 6NAL_UNIT_CODED_SLICE_DLP,       // 7 // Current name in the spec: RADL_RNAL_UNIT_CODED_SLICE_RASL_N,    // 8NAL_UNIT_CODED_SLICE_TFD,       // 9 // Current name in the spec: RASL_RNAL_UNIT_RESERVED_10,NAL_UNIT_RESERVED_11,NAL_UNIT_RESERVED_12,NAL_UNIT_RESERVED_13,NAL_UNIT_RESERVED_14,NAL_UNIT_RESERVED_15, NAL_UNIT_CODED_SLICE_BLA,       // 16   // Current name in the spec: BLA_W_LP
NAL_UNIT_CODED_SLICE_BLA,       // 16   // Current name in the spec: BLA_W_LPNAL_UNIT_CODED_SLICE_BLANT,     // 17   // Current name in the spec: BLA_W_DLPNAL_UNIT_CODED_SLICE_BLA_N_LP,  // 18NAL_UNIT_CODED_SLICE_IDR,       // 19  // Current name in the spec: IDR_W_DLPNAL_UNIT_CODED_SLICE_IDR_N_LP,  // 20NAL_UNIT_CODED_SLICE_CRA,       // 21NAL_UNIT_RESERVED_22,NAL_UNIT_RESERVED_23,NAL_UNIT_RESERVED_24,NAL_UNIT_RESERVED_25,NAL_UNIT_RESERVED_26,NAL_UNIT_RESERVED_27,NAL_UNIT_RESERVED_28,NAL_UNIT_RESERVED_29,NAL_UNIT_RESERVED_30,NAL_UNIT_RESERVED_31,NAL_UNIT_VPS,                   // 32NAL_UNIT_SPS,                   // 33NAL_UNIT_PPS,                   // 34NAL_UNIT_ACCESS_UNIT_DELIMITER, // 35NAL_UNIT_EOS,                   // 36NAL_UNIT_EOB,                   // 37NAL_UNIT_FILLER_DATA,           // 38NAL_UNIT_SEI,                   // 39 Prefix SEINAL_UNIT_SEI_SUFFIX,            // 40 Suffix SEINAL_UNIT_RESERVED_41,NAL_UNIT_RESERVED_42,NAL_UNIT_RESERVED_43,NAL_UNIT_RESERVED_44,NAL_UNIT_RESERVED_45,NAL_UNIT_RESERVED_46,NAL_UNIT_RESERVED_47,NAL_UNIT_UNSPECIFIED_48,NAL_UNIT_UNSPECIFIED_49,NAL_UNIT_UNSPECIFIED_50,NAL_UNIT_UNSPECIFIED_51,NAL_UNIT_UNSPECIFIED_52,NAL_UNIT_UNSPECIFIED_53,NAL_UNIT_UNSPECIFIED_54,NAL_UNIT_UNSPECIFIED_55,NAL_UNIT_UNSPECIFIED_56,NAL_UNIT_UNSPECIFIED_57,NAL_UNIT_UNSPECIFIED_58,NAL_UNIT_UNSPECIFIED_59,NAL_UNIT_UNSPECIFIED_60,NAL_UNIT_UNSPECIFIED_61,NAL_UNIT_UNSPECIFIED_62,NAL_UNIT_UNSPECIFIED_63,NAL_UNIT_INVALID,
};

下面接收下fu分组打包方式,fu分组包头格式如下:

fus包头包含了两个字节的payloadhdr,一个字节的fu header,fu header与h264一样,结构如下图,包含开始位(1b)、停止位(1b)、futype(6b)

paylodhdr两个自己的赋值,其实就是把hevc帧数据的nal unit header的naltype替换为49即可,下面是从ffmpeg源码中截取出来的fu打包方式代码片段:

static void nal_send(AVFormatContext *ctx, const uint8_t *buf, int len, int last_packet_of_frame)
{RTPMuxContext *rtp_ctx = ctx->priv_data;int rtp_payload_size = rtp_ctx->max_payload_size - RTP_HEVC_HEADERS_SIZE;int nal_type = (buf[0] >> 1) & 0x3F;/* send it as one single NAL unit? */if (len <= rtp_ctx->max_payload_size) //小于对定的最大值时,直接发送(最大值一般小于mtu){/* use the original NAL unit buffer and transmit it as RTP payload */ff_rtp_send_data(ctx, buf, len, last_packet_of_frame);}else //大于最大值时进行fu分组发送{/*create the HEVC payload header and transmit the buffer as fragmentation units (FU)0                   10 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|F|   Type    |  LayerId  | TID |+-------------+-----------------+F       = 0Type    = 49 (fragmentation unit (FU))LayerId = 0TID     = 1*/rtp_ctx->buf[0] = 49 << 1;rtp_ctx->buf[1] = 1;//此处为paylaodhdr,规范赋值应该是替换hevc数据nal 的payloadhdr的type//rtp_ctx->buf[0] = (buf[0] &0x81) | (49<<1);//rtp_ctx->buf[1] = buf[1]/*create the FU header0 1 2 3 4 5 6 7+-+-+-+-+-+-+-+-+|S|E|  FuType   |+---------------+S       = variableE       = variableFuType  = NAL unit type*/rtp_ctx->buf[2] = nal_type;/* set the S bit: mark as start fragment */rtp_ctx->buf[2] |= 1 << 7;		/* pass the original NAL header *///此处要注意,当是分组的第一报数据时,应该覆盖掉前两个字节的数据,h264要覆盖前一个字节的数据,即是第一包要去除hevc帧数据的paylaodhdrbuf += 2;len -= 2;	while (len > rtp_payload_size) {/* complete and send current RTP packet */memcpy(&rtp_ctx->buf[RTP_HEVC_HEADERS_SIZE], buf, rtp_payload_size);ff_rtp_send_data(ctx, rtp_ctx->buf, rtp_ctx->max_payload_size, 0);buf += rtp_payload_size;len -= rtp_payload_size;/* reset the S bit */rtp_ctx->buf[2] &= ~(1 << 7);}/* set the E bit: mark as last fragment */rtp_ctx->buf[2] |= 1 << 6;/* complete and send last RTP packet */memcpy(&rtp_ctx->buf[RTP_HEVC_HEADERS_SIZE], buf, len);ff_rtp_send_data(ctx, rtp_ctx->buf, len + 2, last_packet_of_frame);}
}

通过rtp发送hevc视频数据,当hevc帧数据大于mtu时,应该进行fu分组发送,从上面代码流程就是对超过max_payload_size数据进行fu分组的流程,这个h264 fu-A很类似,很容易理解。

参考规范:

https://tools.ietf.org/html/draft-ietf-payload-rtp-h265-14

ffmpeg相关代码

https://www.ffmpeg.org/doxygen/2.5/rtpenc__hevc_8c_source.html

这篇关于H265(HEVC) nal 单元头介绍及rtp发送中的fu分组发送详解的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/192808

相关文章

揭秘未来艺术:AI绘画工具全面介绍

📑前言 随着科技的飞速发展,人工智能(AI)已经逐渐渗透到我们生活的方方面面。在艺术创作领域,AI技术同样展现出了其独特的魅力。今天,我们就来一起探索这个神秘而引人入胜的领域,深入了解AI绘画工具的奥秘及其为艺术创作带来的革命性变革。 一、AI绘画工具的崛起 1.1 颠覆传统绘画模式 在过去,绘画是艺术家们通过手中的画笔,蘸取颜料,在画布上自由挥洒的创造性过程。然而,随着AI绘画工

hevc和H.264格式的区别

HEVC(High Efficiency Video Coding)和H.264(也称为Advanced Video Coding,AVC)都是视频压缩标准,但它们之间存在一些显著的区别,主要集中在压缩效率、资源需求和兼容性方面。 压缩效率 HEVC,也被称为H.265,提供了比H.264更高的压缩效率。这意味着在相同的视频质量下,HEVC能够以大约一半的比特率进行编码,从而减少存储空间需求和

20.Spring5注解介绍

1.配置组件 Configure Components 注解名称说明@Configuration把一个类作为一个loC容 器 ,它的某个方法头上如果注册7@Bean , 就会作为这个Spring容器中的Bean@ComponentScan在配置类上添加@ComponentScan注解。该注解默认会扫描该类所在的包下所有的配置类,相当于之前的 <context:component-scan>@Sc

十四、观察者模式与访问者模式详解

21.观察者模式 21.1.课程目标 1、 掌握观察者模式和访问者模式的应用场景。 2、 掌握观察者模式在具体业务场景中的应用。 3、 了解访问者模式的双分派。 4、 观察者模式和访问者模式的优、缺点。 21.2.内容定位 1、 有 Swing开发经验的人群更容易理解观察者模式。 2、 访问者模式被称为最复杂的设计模式。 21.3.观察者模式 观 察 者 模 式 ( Obser

【操作系统】信号Signal超详解|捕捉函数

🔥博客主页: 我要成为C++领域大神🎥系列专栏:【C++核心编程】 【计算机网络】 【Linux编程】 【操作系统】 ❤️感谢大家点赞👍收藏⭐评论✍️ 本博客致力于知识分享,与更多的人进行学习交流 ​ 如何触发信号 信号是Linux下的经典技术,一般操作系统利用信号杀死违规进程,典型进程干预手段,信号除了杀死进程外也可以挂起进程 kill -l 查看系统支持的信号

Jitter Injection详解

一、定义与作用 Jitter Injection,即抖动注入,是一种在通信系统中人为地添加抖动的技术。该技术通过在发送端对数据包进行延迟和抖动调整,以实现对整个通信系统的时延和抖动的控制。其主要作用包括: 改善传输质量:通过调整数据包的时延和抖动,可以有效地降低误码率,提高数据传输的可靠性。均衡网络负载:通过对不同的数据流进行不同程度的抖动注入,可以实现网络资源的合理分配,提高整体传输效率。增

Steam邮件推送内容有哪些?配置教程详解!

Steam邮件推送功能是否安全?如何个性化邮件推送内容? Steam作为全球最大的数字游戏分发平台之一,不仅提供了海量的游戏资源,还通过邮件推送为用户提供最新的游戏信息、促销活动和个性化推荐。AokSend将详细介绍Steam邮件推送的主要内容。 Steam邮件推送:促销优惠 每当平台举办大型促销活动,如夏季促销、冬季促销、黑色星期五等,用户都会收到邮件通知。这些邮件详细列出了打折游戏、

探索Elastic Search:强大的开源搜索引擎,详解及使用

🎬 鸽芷咕:个人主页  🔥 个人专栏: 《C++干货基地》《粉丝福利》 ⛺️生活的理想,就是为了理想的生活! 引入 全文搜索属于最常见的需求,开源的 Elasticsearch (以下简称 Elastic)是目前全文搜索引擎的首选,相信大家多多少少的都听说过它。它可以快速地储存、搜索和分析海量数据。就连维基百科、Stack Overflow、

Python利用qq邮箱发送通知邮件(已封装成model)

因为经常喜欢写一些脚本、爬虫之类的东西,有需要通知的时候,总是苦于没有太好的通知方式,虽然邮件相对于微信、短信来说,接收性差了一些,但毕竟免费,而且支持html直接渲染,所以,折腾了一个可以直接使用的sendemail模块。这里主要应用的是QQ发邮件,微信关注QQ邮箱后,也可以实时的接收到消息,肾好! 好了,废话不多说,直接上代码。 # encoding: utf-8import lo

常用MQ消息中间件Kafka、ZeroMQ和RabbitMQ对比及RabbitMQ详解

1、概述   在现代的分布式系统和实时数据处理领域,消息中间件扮演着关键的角色,用于解决应用程序之间的通信和数据传递的挑战。在众多的消息中间件解决方案中,Kafka、ZeroMQ和RabbitMQ 是备受关注和广泛应用的代表性系统。它们各自具有独特的特点和优势,适用于不同的应用场景和需求。   Kafka 是一个高性能、可扩展的分布式消息队列系统,被设计用于处理大规模的数据流和实时数据传输。它