腾讯云V265/TXAV1直播场景下的编码优化和应用

  //  

编者按:随着视频直播不断向着超高清、低延时、高码率的方向发展, Apple Vision的出现又进一步拓展了对3D, 8K 120FPS的视频编码需求,视频的编码优化也变得越来越具有挑战性。LiveVideoStackCon 2023上海站邀请到腾讯云的姜骜杰老师分享腾讯云V265/TXAV1直播场景下的编码优化和应用,带领我们探索音视频技术的无限可能性。

文/姜骜杰

编辑/LiveVideoStack

大家好,我是姜骜杰,来自腾讯云,主要负责编解码开发和优化。今天分享的主题是腾讯云V265/TXAV1直播场景下的编码优化和应用。

983426010853c0a53e083300dabbdb44.png

共有三个部分:1、V265/TXAV1直播能力介绍;2、V265/TXAV1典型直播业务实践;3、腾讯云在直播场景下的编码优化技术要点。

-Part 1-

V265/TXAV1直播能力介绍

当今互联网时代,视频直播由于可以更直接的连接服务商和消费者,已经成为了一种受欢迎且广泛应用的传媒形式。人们可以通过直播平台实时观看各种内容,第一时间表达或获得最真实的见解和体验。从在线教育到体育赛事直播,从游戏直播到带货直播,直播应用正不断扩大其影响力,直播行业的发展呈现出多样化和快速增长的趋势。随着用户对高质量视频的需求不断增加,视频编码技术在直播领域的应用变得尤为重要。

当前,AV1/265编码器以其高效的压缩性能和健全的生态,已经在直播领域得到广泛应用。首先,它们能够以更高的压缩效率传输高质量的视频内容。这意味着在相同的带宽下,直播平台可以提供更清晰、更细腻的图像,让观众享受更逼真的观看体验。其次,AV1/265编码器具有较低的码率需求,可以减少网络传输的负担,提高直播的稳定性和可靠性。

为了进一步优化直播编码器的性能、提升腾讯云的直播服务能力,腾讯云架构平台部香农实验室近一年多专门针对AV1/265编码器进行了直播优化,致力于解决直播领域的挑战, 例如针对超高清视、高分辨率、高码率下视频编码的速度和质量的平衡,低延迟直播以及3D直播的压缩性能等,为腾讯云提供更高质量、更稳定、更具互动性的直播体验。

525f625c8c7820ef75a98fdd80cefb39.png

在刚刚结束的MSU2022比赛中, 我们的TXAV1/V265编码器,在相应的AV1/265赛道中,均取得了非常优秀的成绩,拿到了绝大部分指标的第一。尤其是在直播相关的30fp比赛项目中,V265平均比X265节省30%以上的码率,TXAV1平均码率能够节省40%。同时,在云转码(480p,720p,1080p)的比赛中V265/TXAV1也均包揽了比赛前两名。

858ee47d83db4ef26e9678e5695f554e.png

这是我们内部迭代测试,在直播场景下,V265/TXAV1的性能表现:

V265相比X265 medium:在加速20%的情况下,码率节省大于36%;加速6倍下仍然有比较大的码率节省。

TXAV1相比X265 medium:在速度相当的情况下,码率节省大于40%;加速1.5倍下码率仍然有35%以上的节省。

TXAV1相比V265:在相近速度下,仍有10%左右的压缩率提升。

-Part 2-

V265/TXAV1典型直播业务实践

2.1 8K直播

fbb17e5a390eb00f4eca83b3feb8c514.png

在8K直播方面,我们的业务能力总结为三点:全功能、低延时、高性能。

全功能:能够最大支持8K、60fps、10bit、150Mbps、422、HDR 、ABR直播,基本满足目前市面上所有的功能需求。

低延时:能够采用单一设备,最高支持到8K,60fps,无需分布式,将编码延时控制到最低。

高性能:即使在8K 60pfs下, 压缩性能仍然明显高于X265 medium档,并有近9倍的加速。

2.2 快直播

08b6727dd18832d71916c365145bbd18.png

为什么需要快直播?

快直播主要应用在电商直播、秀场直播及在线教育等场景,需要与观众进行实时互动和交流。实时互动对延时的要求非常高,快直播延时要求在500-1000ms以内,比标准直播的延时要求严格很多。

但是低延时会对编码器的性能造成很大挑战,主要体现在预分析更短(可以提前获得的有效信息更少)、GOP更小(对压缩性能产生比较大的压力)、帧级并行更少(会影响多线程下的编码速度)。因此优化的重点是在保证速度的前提下提升性能。经过针对性的优化,目前快直播场景相较于优化前有5%-7%的码率节省。

2.3 MV-HEVC

a9e19734bc9b82d47fb6c8b955d3cbe6.png

苹果全球开发者大会(WWDC)上正式发布Apple Vision Pro 时,提到它通过支持MV-HEVC 编码标准的硬件编解码显著提升了 3D 视频主客观体验。而在这之前,腾讯就已经完成了对MV-HEVC 编码的支持以帮助压缩3D视频,获得更好的3D视频主观质量。左边是常见的3D视频压缩方式:把左右视点图像进行拼接后用通用编码器进行压缩,解码后再重新拆分成左右2个视频。这也是为什么下载的3D视频如果不是用3D方式打开的时候,出现的图像是左右分开的。

右边是MV-HEVC 3D视频压缩方式,并没有把两个视点拼接,而是将多个视点组成一组相同时间下的图像组进行编码。这样的好处是视频的左右眼不再是相互独立的,而是具有参考关系,这样便 能很好的提升压缩效率。

9d25158c24bca8304878a7b1059febe9.png

MV-HEVC的原理:利用了左右视点图像间的冗余信息,进一步提高图像的压缩效率。例如,如果按照常用左右拼接的方式,第一帧的左右视点都是I帧,压缩性能比较差。但是如果按照多视点编码方式编码,那么左视点是I帧,而右视点是P帧, 因此右眼可以充分参考左眼的信息,压缩效果就能明显提升。当左右眼视差较小的时候,压缩效果提升会更加明显。

我们目前的测试结果包括8个JCT3V测试序列和5个3D电影,最后平均压缩收益能超20%。如结果所示,3D电影的收益更大些,因为3D电影中有很多的远景视频,故左右眼视差较小,而MV-HEVC对于图像运动越剧烈或左右眼视差越小,得到的压缩收益也会越大。

-Part 3-

腾讯云在直播场景下的编码优化技术要点

9cb90527b6991048248ebe5a7ad0f335.png

3.1.1 工程优化:数据结构

d23fdfb3ccefb3bd98f1acc8744a6f78.png

对于大分辨率、高码率、高帧率的视频编码而言,由于其对速度的要求更高,因此更需要精简的核心数据结构及优化的流程,因为每一次重复计算或拷贝都可能带来明显的降速。基于这种要求,对于从零开始做的V265以及TXAV1编码器,我们从设计伊始就明确了目标:将核心数据结构尽量设计高效、精简:

1、TreeNode:方便获取节点属性信息,避免重复计算。比如图像节点能否再划分,有哪些可用模式,宽高位置等基本属性都可以通过提前计算得到。

2、CoreUnit:核心储存结构,能够存储核心编码信息,既能节省算法频繁访问耗时,还能帮助高效获得周边块的信息。

3、IdenticalCu:利用相同Cu计算结果,减少计算量。鉴于有些块的划分方式在不同节点下其实是一样的,IdenticalCu能够避免继续划分,提前存储信息,实现重复使用。

4、SwapBuffer:通过内存交替使用,减少拷贝和重算。对比SwapBuffer使用前后的性能发现,使用后通测能够提升5%的速度,而在8K方面能有20%以上的提速。也就是说,对于8K,重复计算、拷贝和大内存的访问都可能会带来更大程度的降速。

3.1.2 工程优化:流程优化

b5220d38786dd0949f0397e5fc987f67.png

针对超高清、高码率、高帧率的视频编码特性,进一步优化流程。以AV1为例,原流程中,同一CTU的分析、滤波、编码不同时完成,这是由于滤波依赖帧级的参数,而我们无法在当前块操作结束之后就得到帧级参数,进行滤波,只能通过一些算法尽早获得整帧滤波参数,提高并行度。但这样的做法会增加数据拷贝,影响速度和cache命中率。

经过分析后发现,滤波对超高清、高码率、高帧率的视频压缩性能影响变小,但对整体速度影响较大,性价比变差,因此可以适当地减少一些滤波操作。此外,在高帧率下,帧间滤波参数相似度更高,高层帧更倾向不滤波。所以,是否有可能跳过或者复用其它帧滤波参数?因此我们设计了一套自适应滤波算法,减少滤波使用或参数推导。

这样整个流程就有了很大的优化空间:对于不需要做参数推导的帧,当前CTU做完了分析之后就可以立即进行滤波、编码,免去了拷贝和加载的操作,明显提升了编码速度。其实V265一直采用这个编码流程,但由于AV1滤波参数导出的原因在最开始的设计中没有办法实施。

最终修改之后在8K序列上的测试能够提升5%以上,在通测序列下由于滤波跳过得比较少,因此速度影响相对比较小。

3.1.3 工程优化:多线程

3c7a0ca3032a18ee9733960a09be5eb8.png

这是多线程总流程图。我们将多线程分了很多部分,包括预分析、帧级、SLICE/TILE级、宏块级、后处理等,针对每一部分都设计了可以提升并行度的算法。

比如帧级中无参考帧间并行、高并发的参考帧优化、帧级优先级调整;宏块级中WPP分析并行、类WPP并行;后处理中滤波错位参考导出、滤波宏块级并行、多滤波并行等。

同时我们也有一套自适应并行控制。很多时候并行并不是无损的,因此需要考虑怎么在提升速度的前提下,减少损失。比如当知道线程数、设备核数、图像宽高、图像复杂度的情况下,就可以去自适应调节WPP并行、CTU大小、GOP长度等等。

a8c60e58cc55866b70e5a6b995232bca.png

虽然我们已经有了很完整的一套并行方案,但是在8K场景下又会出现很多新的问题:

第一个问题,首帧延时高,CPU使用率低。正常帧内并行都是以WPP为主,但它会依赖它的左块和右上块,导致它们之间必须有错位关系才能并行。也就是说,在左图上最多并行的也只有4个块。为了更好的计算并行度,我们总结出一个公式:w,h代表宽高CTU的个数,但这只是最大并行度,因为WPP并度有个逐渐上升和逐渐下降的过程,所以这只是理想中最好的并行效果。

因此,为了减少首帧延时,就需要增加最大并行度,而TILE并行时,多个TILE间无依赖关系,因此TILE并行就是一个可行的方案。以4K为例,WPP最大并行度是16.2。因此只要TILE个数大于16个,理论上就会有速度收益。实际的计算结果验证了这一点,TILE划分4×4已经能够提速2.2%,4×8能够提速25.59%,运行效果比WPP更好。

但如何减少或者避免过程中的性能损失呢?如果目标是降低首帧延时的话,那么没有必要对所有图像进行多TILE编码,可以使用自适应的方法。这里自适应有2个方向,首先可以自适应计算加多少TILE合适;其次可以自适应只针对关键帧多TILE编码,其他帧仍旧使用原先的编码方式。这样的组合能够做到控制性能损失的前提下,有效地降低延迟。

53952dd2b67320202661aa03aecd110c.png

第二个问题,在超多核设备上,8K视频速度无法提升。通过整体分析对比发现,预分析成为整个编码过程的瓶颈,限制了编码速度。这里有多种优化手段,从输入到预分析编码都进行了优化。比如CUTREE并行优化、多SLICE并行输入、SLICE&BATCH并行优化、多SLICE负载均衡,避免其由于负载不均衡导致延时过大的问题。多SLICE负载均衡是根据图像划分条带,避免有些条带比较大。但由于编码过程中涉及复杂的内容问题,我们会记录实际运用中每个条带的时间,通过不断调整最终达到比较优的效果。

右图是SLICE&BATCH并行。BATCH模式其实就是多帧并行,SLICE模式是帧内条带并行。我们发现在8K场景二者单独的效果都不够,二者结合才能达到比较好的效果,并行度提升得非常明显。

在一系列加速措施之后,综合效果能达到加速101%,压缩性能损失0.1%,加速比1001:1。

3.2 算法优化

c654f2d0ed8856921ecfc25683a8b5b2.png

8K场景下一些加速算法的优化同样会出现的新问题。比如,在8K中,变换过程占比更加突出,影响编码速度。因此尝试了使用非标准DCT来简化DCT过程进行加速。比如针对64x64的块,只对前16行进行DCT的列变换,转置后,也仅针对16行再次进行列变换,这样就仅对较少的位置变换,其他位置用0填充。通过这样的处理,能够减少50%-60%DCT正变换的时间。由于DCT变换在8K场景中占比较大,所以这个节省的时间也是非常明显的。

但实现时发现,这个加速算法会对一些边界清晰的块造成比较大的性能损失,比如纹理比较复杂的图像、字的边缘、人的眼睛等。所以这里尝试进行了CTU级的场景检测,使用预分析得到的图像复杂度信息,检测当前块是否属于平滑块,同时避免了额外的计算量。通过这种方式,就完成了只针对平滑块的64x64/32x32TU采用非标准DCT变换。最终效果能够加速6%,压缩性能损失0.5%。

9283442131005dd3e26c22f21ce95bff.png

在低延时直播场景下,为了避免压缩性能损失较大,也需要进行优化。上图为低延时场景下常用的IPPP结构,分析这种结构的性能时发现,由于在低延时场景下单纯使用前一帧作为参考,导致每一帧得到的QP偏移量是相似的,也就是说每一帧的重要性是相同的,属于同一层,没有做到分层状态。所有帧都处在同一层很多时候对编码器来说是不好的,比如常用的分层结构,对于越低层的帧就会有越小的QP,这样能够更好地提高压缩性能。

因此提出的优化方案是,引入以4帧为一组的miniGOP结构,调整参考关系,针对这种低延迟miniGOP,优化cutree传播, 强化低level帧参考性,这样便自然而然地进行了分层,同时增强了整体的容错能力。进一步的,为了保证在lookahead长度较短时的,低层帧的性能, 通过调整输出为单帧推入推出的结构,保证了低层帧推出时能最大限度利用后向的时域依赖性完成帧间的QP计算。利用结构和算法的改动,让QP在不同层进行更好地分布,达到最终的优化效果,在低延时直播场景下,性能提升十分明显。

3.3 主观优化

c44360506a47b9fbf01ad17dc760f16e.png

为了进一步提升在直播场景下的主观质量,我们加入了对ROI(关注区域)编码的支持,以提高人眼关注区域的质量。但同时ROI功能的添加也产生了2个问题:

问题1:码率波动大。因为ROI调整了图像的QP分布,使得实际码率和目标码率相比产生了比较大的码率波动。为了解决这个问题, 我们从帧内和帧间两方面进行了优化:首先,对于帧内,为了更好地找到ROI和ROU区域的QP偏移,通过对ROI和ROU区域的强度、面积及复杂度进行函数拟合,调整了QP的计算公式:

QP_roi=QP−func1(QP_frame, roi_cplx∗roi_area,rou_cplx∗rou_area,roi_strengtℎ,rou_strengtℎ);

QP_rou=QP+func2(QP_frame, roi_cplx∗roi_area,rou_cplx∗rou_area,roi_strengtℎ,rou_strengtℎ)。

这里的复杂度延伸了编码器本身对块的复杂度评估,所以没有额外的计算量。这时码率波动由32%减小到15%。

其次,对于帧间,为了进一步减少帧间图像间的码率波动,我们调整了码率的蓄水池模型,使其能够通过调整ROI强度,进一步优化码率波动。当码率上升的时候,就增大ROU的强度,降低码率;但当码率持续上升到一定阈值,就要减少ROI的强度,进一步降低码率, 反之亦然。通过这一系列手段,将码率从15%降低到了5%,达到了我们码率控制的预期。

31a8c136a8eafb0b64ab6d70ff4c0ed3.png

问题2:速度下降明显。我们同样从两方面进行了优化:首先是编码划分决策的快速算法优化,因为关注区域更容易划分小块,而非关注区域更容易划分大块。既然已经划分出ROI和ROU,我们就可以根据不同区域,调整它的划分决策算法。通过这样的方式能够在编码方面提升速度。

同时我们也进行了相应的工程优化,比如推理框架工程化加速、模型升级和剪枝、动态调节输入图像下采样的算法和参数等等。

最终效果达到平均耗时仅增加5%,人工评测主观画质提升32.3%,比较显著地提升了主观效果。

3.4 其它

0afc89538334156ed910f30c86fc326d.png

前面仅是其中的一部分优化,除此之外还有很多。

算法上:例如自适应Intra跳过算法、预分析MVP跳过算法、预分析分像素ME跳过算法、预分析Intra 模式搜索优化、Inter search模式跳过算法优化、Intra 色度模式RD搜索优化、Inter compound 模式跳过算法、参考帧选择算法优化、滤波分层跳过算法、基于参考块信息的滤波快速算法等。

工程上:例如CTU编码优化、CTU参考模式信息拷贝优化、Intra 参考像素拷贝优化、Tile syntax 更新优化、CTU残差信息拷贝优化、编码信息统计优化、Cost表计算优化、扩边优化、重建拷贝优化等。

8b003daa2603f8da38b9164055364aca.png

最后补充一点,我们团队不仅有服务器端编码能力,还通过腾讯云对外输出R265终端直播的实时编码能力,目前已经在腾讯云终端上广泛使用。其能够支持在X86平台和ARM平台上实现更好的零延迟压缩。R265在与X264@veryfast相似的速度下,可以节省30%的比特率。

我的分享到此结束。


5b5d196363a6eef775d0a25652ad94b3.jpeg

LiveVideoStackCon是每个多媒体技术人的舞台,如果您在团队、公司中独当一面,在某一领域或技术拥有多年实践,并热衷于技术交流,欢迎申请成为LiveVideoStackCon的出品人/讲师。

扫描下方二维码,可查看讲师申请条件、讲师福利等信息。提交页面中的表单完成讲师申请。大会组委会将尽快对您的信息进行审核,并与符合条件的优秀候选人进行沟通。

984f2e4340c924c92ab7ab68b43dabf5.jpeg

扫描上方二维码 

填写讲师申请表单

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.rhkb.cn/news/106689.html

如若内容造成侵权/违法违规/事实不符,请联系长河编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

结合源码拆解Handler机制

作者:Pingred 前言 当初在讲App启动流程的时候,它的整个流程涉及到的类可以汇总成下面这张图: 那时着重讲了AMS、PMS、Binder这些知识点,有一个是没有对它进行详细讲解的,那就是常见的Handler,它不仅在这个…

k8s之工作负载、Deployment、DaemonSet、StatefulSet、Job、CronJob及GC

文章目录 1、工作负载1.1、定义1.2、分类 2、Deployment2.1、定义2.2、Deployment创建2.3、Deployment 更新机制2.3.1、比例缩放(Proportional Scaling)2.3.2、HPA(动态扩缩容)2.3.2.1、需要先安装metrics-server2.3.2.2、配置hpa…

STM32--SPI通信与W25Q64(1)

文章目录 前言SPI通信硬件电路移位过程 SPI时序起始与终止条件交换一个字节 W25Q64硬件电路框图 FLASH操作注意事项软件SPI读写W25Q64 前言 USART串口链接入口 I2C通信链接入口 SPI通信 SPI(Serial Peripheral Interface)是一种高速的、全双工、同步的串…

实战:大数据Spark简介与docker-compose搭建独立集群

文章目录 前言技术积累Spark简介Spark核心功能及优势Spark运行架构 Spark独立集群搭建安装docker和docker-composedocker-compose编排docker-compose编排并运行容器 Spark集群官方案例测试写在最后 前言 很多同学都使用过经典的大数据分布式计算框架hadoop,其分布式…

c++11 标准模板(STL)(std::basic_istringstream)(五)

定义于头文件 <sstream> template< class CharT, class Traits std::char_traits<CharT> > class basic_istringstream;(C11 前)template< class CharT, class Traits std::char_traits<CharT>, class Allocator std::allo…

小程序中的全局配置以及常用的配置项(window,tabBar)

全局配置文件和常用的配置项 app.json: pages:是一个数组&#xff0c;用于记录当前小程序所有页面的存放路径&#xff0c;可以通过它来创建页面 window:全局设置小程序窗口的外观(导航栏&#xff0c;背景&#xff0c;页面的主体) tabBar:设置小程序底部的 tabBar效果 style:是否…

C#-集合小例子

目录 背景&#xff1a; 过程: 1.添加1-100数: 2.求和: 3.平均值: 4.代码:​ 总结: 背景&#xff1a; 往集合里面添加100个数&#xff0c;首先得有ArrayList导入命名空间&#xff0c;这个例子分为3步&#xff0c;1.添加1-100个数2.进行1-100之间的总和3.求总和的平均值&…

数据结构(5)

堆 堆可以看作一颗完全二叉树的数组对象。 特性&#xff1a; 1.堆是完全二叉树&#xff0c;除了树最后一层不需要满&#xff0c;其余层次都需要满&#xff0c;如果最后一层不是满的&#xff0c;那么要求左满右不满 2.通常使用数组实现&#xff0c;将二叉树结点依次放入数组中…

Redis 重写 AOF 日志期间,主进程可以正常处理命令吗?

重写 AOF 日志的过程是怎样的&#xff1f; Redis 的重写 AOF 过程是由后台子进程 bgrewriteaof 来完成的&#xff0c;这么做有以下两个好处。 子进程进行 AOF 重写期间&#xff0c;主进程可以继续处理命令请求&#xff0c;从而避免阻塞主进程子进程带有主进程的数据副本。这里…

远程控制:用了向日葵控控A2后,我买了BliKVM v4

远程控制电脑的场景很多&#xff0c;比如把办公室电脑的文件发到家里电脑上&#xff0c;但是办公室电脑旁边没人。比如当生产力用的电脑一般都比较重&#xff0c;不可能随时带在身边&#xff0c;偶尔远程操作一下也是很有必要的。比如你的设备在工况恶劣的环境中&#xff0c;你…

基础论文学习(2)——DETR

目标检测 DETR&#xff1a;End-to-End Detection with Transformer detr是facebook提出的引入transformer到目标检测领域的算法&#xff0c;效果很好&#xff0c;做法也很简单&#xff0c;相较于RCNN和YOLO系列算法&#xff0c;避免了Proposal/AnchorNMS的复杂流程。 1. detr…

jvm开启远程调试功能;idea远程debug

概述 有时候一些问题本地调试无法复现&#xff0c;这个时候可以开启jvm的远程调试功能 jar包启动 jdk8 java -agentlib:jdwptransportdt_socket,address8787,servery,suspendn -jar xxx.jarjdk11/17 java -agentlib:jdwptransportdt_socket,address*:8787,servery,suspe…

STM32F103 4G Cat.1模块EC200S使用

一、简介 EC200S-CN 是移远通信最近推出的 LTE Cat 1 无线通信模块&#xff0c;支持最大下行速率 10Mbps 和最大上行速率 5Mbps&#xff0c;具有超高的性价比&#xff1b;同时在封装上兼容移远通信多网络制式 LTE Standard EC2x&#xff08;EC25、EC21、EC20 R2.0、EC20 R2.1&a…

Linux--进程地址空间

1.线程地址空间 所谓进程地址空间&#xff08;process address space&#xff09;&#xff0c;就是从进程的视角看到的地址空间&#xff0c;是进程运行时所用到的虚拟地址的集合。 简单地说&#xff0c;进程就是内核数据结构和代码和本身的代码和数据&#xff0c;进程本身不能…

代码随想录第29天|491.递增子序列,46.全排列,47.全排列II

491.递增子序列 491. 递增子序列 这道题的特点是有序的子序列(不能对原数组排序)&#xff0c;最终结果集res不能有重复子集。所以这道题又是子集又是去重 回溯三部曲 1.递归函数参数 本题求子序列&#xff0c;很明显一个元素不能重复使用&#xff0c;所以需要startIndex&a…

【C++练习】普通方法+利用this 设置一个矩形类(Rectangle), 包含私有成员长(length)、 宽(width), 定义一下成员函数

题目 设置一个矩形类(Rectangle), 包含私有成员长(length)、 宽(width), 定义成员函数: void set_ len(int l); //设置长度 设置宽度void set_ wid(int w); 获取长度: int get len(); 获取宽度: int get _wid); 显示周长和面积: v…

汽车电子笔记之:AUTOSAR方法论及基础概念

目录 1、AUTOSAR方法论 2、AUTOSAR的BSW 2.1、MCAL 2.2、ECU抽象层 2.3、服务层 2.4、复杂驱动 3、AUTOSAR的RTE 4、AUTOSAR的应用层 4.1、SWC 4.2、AUTOSAR的通信 4.3、AUTOSAR软件接口 1、AUTOSAR方法论 AUTOSAR为汽车电子软件系统开发过程定义了一套通用的技术方法…

分布式事务篇-2.4 Spring-Boot整合Seata

文章目录 前言一、pom jar导入:二、项目配置&#xff1a;2.1 配置 说明&#xff1a;2.1 .1 seata server 端:2.1 .2 seata client 端: 2.2 开启seata 对于数据源的代理:2.3 seata-client 的注册中心&#xff1a;2.4 seata-client 的配置中心&#xff1a;2.5 去掉手写的数据源代…

二叉树链式结构的实现

文章目录 1.前置说明 2.二叉树的遍历 文章内容 1.前置说明 学习二叉树的基本操作前&#xff0c;需先要创建一棵二叉树&#xff0c;然后才能学习其相关的基本操作。由于现在我们对于二叉树的了解还处于初级阶段&#xff0c;所以我们手动创建一棵简单的二叉树&#xff0c;以便…

javeee eclipse项目导入idea中

步骤一 复制项目到idea工作空间 步骤二 在idea中导入项目 步骤三 配置classes目录 步骤四 配置lib目录 步骤五 添加tomcat依赖 步骤六 添加artifacts 步骤七 部署到tomcat