H.265视频编码与技术全析

这篇具有很好参考价值的文章主要介绍了H.265视频编码与技术全析。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

一. 概述

作为新一代视频编解码格式,H.265得到越来越广泛的应用。不久之前,苹果公司在翘首期盼中发布了iPhone6,该款手机较之以往的iPhone,不仅仅只是简单地增大了屏幕,其采用了H.265视频编码解码技术,可达到在有限带宽下传输更高质量的网络视频。虽然对于大部分人来讲,H.265还有点陌生,然而早在两年前,爱立信就已经推出了首款H.265编解码器。使用H.265编解码的一个巨大优势是仅需目前主流编码视频H.264一半的比特率,就可提供同等质量的视频。

接下来,为大家详细介绍H.265视频编码技术究竟有什么样的优势。

新一代视频压缩标准:H.265

视频编解码标准主要来源于国际电联ITU-T和国际标准化组织ISO,ITU的H.26×系列视频压缩标准经过了H.261、H.263,H.263+这样一个演进过程。而ISO的视频压缩标准是MPEG系列,从MPEG1、MEPG2到MPEG4,之后两个标准化组合走向合作,成立了JVT,推出了在当前最有效的视频压缩标准:H.264/AVC。

随后,H.264的应用范围不断扩展,成熟度也不断提高,于2013年定稿发布了下一代视频压缩标准,命名为HEVC(High EfficiencyVideoCoding),分别被ITU-T和ISO/IEC采纳成为国际标准,即H.265视频压缩标准。H.265在现有的视频编码标准H.264基础上,进一步提高压缩效率、提高鲁棒性(Robustness抗变换性)和错误恢复能力、减少实时的时延、减少信道获取时间和随机接入时延、降低复杂度,以达到最优化设置。

高清晰,低码率

如今,4K超高清技术大行其道,传统的H.264已面临瓶颈限制。以编码单位来说,H.264中每个宏块(marcoblock,MB)大小都是固定的16x16像素。然而,在更高分辨率下,单个宏块所表示的图像内容信息大大减少,H.264所采用的宏块经过整数变换后,低频系数相似程度也大大提高,出现大量冗余,导致H.264编码对高清视频的压缩效率明显降低;其次,H.264算法宏块个数的爆发式增长,会导致每个编码宏块的预测模式、运动矢量、参考帧索引和量化级等宏块级参数信息占用更多码流资源,也降低了编码压缩率。

相比H.264,H.265提供了更多不同的工具来降低码率。H.265的编码单位可以选择从最小的8x8到最大的64x64。信息量不多的区域划分的宏块较大,编码后的码字较少,而细节多的地方划分的宏块就相应的小和多一些,编码后的码字较多,这样就相当于对图像进行了有重点的编码,针对重要的更多关键细节的部分进行增强划块,从而降低了整体的码率,编码效率就相应得到了提高。这个过程在H.265上,可以通过系统自行适应识别实现。

最新H.265标准基本继承了H.264的框架,H264由于算法优化,只能低于1Mbps的速度实现标清数字图像传送;H265则可以实现利用1~2Mbps的传输速度传送720P(分辨率1280*720)普通高清音视频传送。这意味着,旨在有限带宽下H.265能够传输更高质量的网络视频,同时,仅需原先的一半带宽即可播放相同质量的视频。

本文福利, 免费领取C++音视频学习资料包、技术视频/代码,内容包括(音视频开发,面试题,FFmpeg ,webRTC ,rtmp ,hls ,rtsp ,ffplay ,编解码,推拉流,srs)↓↓↓↓↓↓见下面↓↓文章底部点击免费领取↓↓文章来源地址https://www.toymoban.com/news/detail-843586.html

H.265技术的应用

编码技术主要运用于视频播放设备、软件应用以及拍摄、录制视频的设备。人们最熟悉的莫过于PPS网络视频播放器。在PC屏客户端产品上面,PPS已经于2013年初推出了基于H.265标准的高清视频,并命名“臻高清”为自己的高清品牌。同时 PPS不断加大了在H.265技术应用方面的研究,把H.265推向手机客户端,且在性能上不断优化提升。

在视频播放设备上,4K超清电视的推出,也与H.265编码技术息息相关。索尼于今年9月份发布的国内首台提供高品质4K内容的媒体播放器新品FMP-X10以及索尼在国外已发布的S900B系列和S990B系列,它们都采用了H.265编码格式,在编码技术上更胜从前。对于蓝光来说,H.265的HEVC编码技术足以将巨大的4K电影压缩进一张蓝光光盘,节省更大的内存空间。

在摄像设备上,索尼、海康威视、中兴等厂商陆续发布了该类摄像设备,不仅用于日常的拍照摄影,更用于区域监控安防上。采用了H.265编码技术的超高清监控所能监控的区域更大,不仅减少了安装数量,最主要的是提高了监控的画面质量。避免了一个路口安装多台摄像机而造成庞大的冗余数据的情况。

当然,H.265的应用不仅仅局限于此,据悉,马上入华的索尼PS4也将支持H.265编解码技术。另外,伴随着4G网络的到来,H.265将可能逐渐大规模投入移动客户端,让高清无处不在,使得更多的人们感受并享受这一技术所带来的影响。

这里需要指出的是,虽然H.265带来了远高于H.264的压缩效率,但同时也带来了高于H.264数倍的解码难度,运算量飙升到400~500GOPS,目前还没有广泛的H.265硬解支持。而且,在面对硬件支持度欠缺、标准确立太晚等问题的同时,谷歌VP9也是H.265摆在面前的挑战,毕竟和需要缴纳授权费的H.265相比,VP9使用自由的BSD版权协议对业界的吸引力无疑是巨大的。

二、名词

CTU: 编码树单元
CU: 编码单元
PU: 以CU为根,对CU进行划分,一个预测单元PU包含一个亮度预测块PB和两个色度预测块PB.
TU: 以CU为根,变换单元TU是在CU的基础上划分的,跟PU没有关系,采用四叉树划分方式,具体划分有率失真代价决定,下图给出了某个CU划分成TU的结构。

1. H265-NALU-Type介绍

NAL_TRAIL_N = 0, NAL_TRAIL_R = 1, NAL_TSA_N = 2, NAL_TSA_R = 3, NAL_STSA_N = 4, NAL_STSA_R = 5, NAL_RADL_N = 6, NAL_RADL_R = 7, NAL_RASL_N = 8, NAL_RASL_R = 9, NAL_BLA_W_LP = 16, NAL_BLA_W_RADL = 17, NAL_BLA_N_LP = 18, NAL_IDR_W_RADL = 19, NAL_IDR_N_LP = 20, NAL_CRA_NUT = 21, NAL_VPS = 32, NAL_SPS = 33, NAL_PPS = 34, NAL_AUD = 35, NAL_EOS_NUT = 36, NAL_EOB_NUT = 37, NAL_FD_NUT = 38, NAL_SEI_PREFIX = 39, NAL_SEI_SUFFIX = 40,

2. H264和H265获取帧类型/NALU类型的区别

H264获取方式为 code&0x1f 取低5位,如00 00 00 01 65 则65&0x1f=5表示IDR帧

H265获取方式为 (code & 0x7E)>>1 , 如00 00 00 01 40 则(40&0x7e)>>1 = 32--vps

3. H265中帧类型的介绍GOP等

H265和H264的不同有H265引入了多种方式的帧编码方式,其次H265的GOP不像H264那种为封闭式,H265是封闭和开放式都支持;H264封闭式GOP: H264中单个GOP内部帧解码不会依赖其它GOP,即每个GOP都可独立解码,关键点就是IDR帧的强制刷新起了阻隔作用,避免错误帧相互影响,所以H264中GOP开始的第一帧必须为IDR关键帧,IDR为I帧的一种采用帧内编码无参考方式,但I帧不一定是IDR帧,普通I帧会参考前边的IDR,在RTC中,用的最多的就是IDR关键帧。

关于GOP。

这是图像组(Group of Pictures)的意思,表示编码的视频序列分成了一组一组的有序的帧的集合进行编码。每个GOP一定是以一个I帧开始的,但是却不一定指代的是两个I帧之间的距离。因为一个GOP内可能包含几个I帧,只有第一个I帧(也就是第一帧)才是关键帧。在程序cfg中,GOP的长度和两个I帧的距离也是两个不同参数指定的(如IntraPeriod和GOP Size或者类似的参数)。所以,两个I帧的间距不可能大于GOP的长度,一般情况是更小的。

关于IDR。

这个词儿的全称是Instantaneous Decoding Refresh,是在H.264中定义的结构。在H.264中,IDR帧一定是I帧,而且一定是GOP的开始,也是H.264 GOP的关键帧。但是反过来却不成立,I帧不一定是IDR帧。GOP的长度不是定死不变的,在H.264的编码器中,如果判定场景发生变化,那么及时不到原定GOP的末尾,也会在这个位置加入一个IDR,作为新一个GOP的开始。此时这个GOP的长度就被缩小了。

闭合GOP和开放GOP(closed GOP/open GOP),CRA

闭合GOP是H.264中GOP的格式。在H.264的GOP中,所有的GOP都是独立解码的,与其他GOP无关,即它们都是“封闭”的。但是在HEVC中,GOP的结构发生了变化,采用了“开放”的结构,在解码过程过可能会参考其他GOP的数据。这时,一个GOP的起始帧命名为CRA, clean random access,同样采用帧内编码,但是这个GOP内的帧间编码帧可以越过CRA参考前一个GOP的数据,这便是GOP的open。

关于BLA

BLA只是CRA在视频流切换情况下的一种特例。视频流在某个RAP上要求切换到另一个视频流继续解码,则直接将该CRA同另一个视频流中的接入CRA连接,后者便是BLA。由于BLA之前解码到缓存的视频流与当前视频流无关,因此其特性类似于直接从该点进行随机存取后的CRA。

RASL和RADL

这是两种GOP间的图像类型。如果解码器从某个CRA随机接入,则按照显示顺序的后面几帧数据由于缺少参考帧而不能解码,这些图像将被解码器抛弃,即skip leading。而对于没有从当前CRA接入的数据,这些图像可以被正常解码显示,因此称为decodable leading。由于这些数据是有可能舍弃的,因此其他图像(trailing pictures)不能参考这些数据,否则万一这些图像被舍弃,将会有更多的图像受其影响而不能正常解码。

三、基础结构

HEVC Encoder整体框架:

h265,音视频开发进阶,音视频,h.264,h.265,音视频编解码,音视频开发

CU是用作帧间和帧内编码的基础模块,它的特点是方块,它的大小从8×8到最小64×64,LCU是64x64,可以使用递归分割的四分树的方法来得到,大的CU适用于图像中比较平滑部分,而小的部分则适用于边缘和纹理较丰富的区域。CU采用四叉树的分割方式,具体的分割过程通过两个变量来标记:分割深度(Depth)和分割标记符(Split_flag)。

在设置CTU大小为64X64的情况下,一个亮度CB最大为64X64即一个CTB直接作为一个CB,最小为8X8,则色度CB最大为32X32,最小为4X4。每个CU包含着与之相关联的预测单元(PU)和我变换单元(TU).

h265,音视频开发进阶,音视频,h.264,h.265,音视频编解码,音视频开发

Z扫描顺序:

h265,音视频开发进阶,音视频,h.264,h.265,音视频编解码,音视频开发

Z扫描

PU是预测的最基本的单元,是从CU中分割出来的,HEVC中对于skip模式、帧内模式和帧间模式。
帧内预测有2种划分模式,只有在CU尺寸为8x8时,才能用PART_NxN。
帧间有8种划分模式,PU可以使方形也可以使矩形,但是其分割不是递归的,与CU的分割还是有区别的。尺寸最大为64×64到最小4×4。

h265,音视频开发进阶,音视频,h.264,h.265,音视频编解码,音视频开发

TU也是采用四叉树划分,以CU为根,TU可以大于PU,但是却不可以大于CU的大小。
在帧内编码过程中,TU 的尺寸严格小于 PU 的尺寸;
在帧间编码过程中,TU 的尺寸不一定小于PU 的尺寸,但一定小于其对应 CU 的尺寸。

h265,音视频开发进阶,音视频,h.264,h.265,音视频编解码,音视频开发

Slice可以包含一个独立的Slice Segment(SS)和多个非独立的SS,一个Slice中的SS可以互相依赖,但不能依赖其它Slice。图中,虚线是SS分隔线,实线是Slice分隔线。

h265,音视频开发进阶,音视频,h.264,h.265,音视频编解码,音视频开发

本文福利, 免费领取C++音视频学习资料包、技术视频/代码,内容包括(音视频开发,面试题,FFmpeg ,webRTC ,rtmp ,hls ,rtsp ,ffplay ,编解码,推拉流,srs)↓↓↓↓↓↓见下面↓↓文章底部点击免费领取↓↓

Tile是一个矩形块,Slice是一个条带。
Tile、Slice需要满足以下两个条件之一:

1. 任一Slice中的所有CTU属于同一个Tile:

h265,音视频开发进阶,音视频,h.264,h.265,音视频编解码,音视频开发

2. 任一Tile中的所有CTU属于同一个Slice:

h265,音视频开发进阶,音视频,h.264,h.265,音视频编解码,音视频开发

举例说明:

假设视频序列的显示顺序为①,这是一个完整的GOP,解码顺序为②

①I B B P B B P B B P

②I P B B P B B P B B

在H.264中,第一个I帧为IDR,GOP为闭合结构,因此两个GOP组成视频的结构为

I B B P B B P B B PI B B P B B P B B P(显示顺序)

I P B B P B B P B BI P B B P B B P B B(解码顺序)

而在HEVC中,两个I帧为CRA,GOP为开放结构,因此GOP的结构为:

I B B P B B P B B PB B I B B P B B P B(显示顺序)

I P B B P B B P B B I B B P B B P B B...(解码顺序)

两个红色的B帧表示的是按照解码顺序在CRA之后,该GOP内参考的前一个GOP进行编码的图像。这样便很容易得知,如果选择在第二个CRA进行随机接入,这两个红色的B帧将会由于没有参考帧无法解码而被舍弃。这两个红色的B帧即RASP。如果没有选择这个CRA进行随机接入,这两个红色B帧将可以顺利解码,即成为RADP。

对于BLA,情况也是类似的。由于出现码流拼接,第二段码流的CRA之后的B也会因为没有参考帧无法解码而丢弃。很容易理解,此时缓存中的参考帧数据还来自上一段码流,跟当前码流没关系,当然不能用作B的参考了。

至于HEVC这么设计的目的,应该是为了编码效率考虑的。因为B帧的压缩比相对是最高的,引入这种设计可以在不影响随机存取性能的前提下,尽可能增大B帧的比重,提高整体压缩编码的性能。

H265中引入的新结构:

Random access point picture

IDR(instantaneous decoder refresh)

BLA(broken link access)

CRA(clean random access)

Leading picture RASL和RADL的总称

RADL(random access decodable leading)在随机接入点后,可以按顺序解码的图像

RASL(random access skipped leading)因为包含帧间信息而不能解码的图像--会被丢弃

Temporal sub-layer access picture随机接入点后按解码和输出顺序的图像。

TSA(temporal sublayer access)

STSA(stepwise temporal sublayer access)

因此可以说随机接入点的图像一定是I帧,则H265中I帧的类型有以下几种IDR/BLA/CRA,也就是NALU中的16~21均为I帧,代码可参考ffmpeg相关判断代码:

switch (type) {

case NAL_VPS:

vps++;

break;

case NAL_SPS:

sps++;

break;

case NAL_PPS:

pps++;

break;

case NAL_BLA_N_LP:

case NAL_BLA_W_LP:

case NAL_BLA_W_RADL:

case NAL_CRA_NUT:

case NAL_IDR_N_LP:

case NAL_IDR_W_RADL: irap++; break;

}

四.帧内预测模式

共35个(h264有9个),包括Planar,DC,33个方向模式:

h265,音视频开发进阶,音视频,h.264,h.265,音视频编解码,音视频开发

除了Intra_Angular预测外,HEVC还和H.264/MPEG-4 AVC一样,支持Intra_Planar, Intra_DC预测模式;
. Intra_DC 使用参考像素的均值进行预测;
. Intra_Planar 使用四个角的参考像素得到的两个线性预测的均值;

划分模式:帧内只能使用PART_2Nx2N、PART_NxN两种

五、帧间预测

Skipped模式:无MV差异和残差信息的帧间预测模式

针对运动向量预测,H.265有两个参考表:L0和L1。每一个都拥有16个参照项,但是唯一图片的最大数量是8。H.265运动估计要比H.264更加复杂。它使用列表索引,有两个主要的预测模式:合并和高级运动向量(Merge and Advanced MV.)。

1. 运动估计准则

最小均方误差(Mean Square Error,MSE)
最小平均绝对误差(Mean Absolute Difference,MAD)
最大匹配像素数(Matching-Pixel Count,MPC)
绝对误差和(Sum Of Absolute Difference,SAD)
最小变换域绝对误差和(Sum Of Absolute Transformed Difference,SATD)

一般用SAD或者SATD。SAD不含乘除法,且便于硬件实现,因而使用最广泛。实际中,在SAD基础上还进行了别的运算来保证失真率。

2. 搜索算法

· dia 菱形

· hex (default) 六边形

· umh 可变半径六边形搜索(非对称十字六边形网络搜索)

· star 星型

· full 全搜索

全搜索: 所有可能的位置都计算两个块的匹配误差,相当于原块在搜索窗口内一个像素一个像素点的移动匹配
菱形搜索: 在x265中实际是十字搜索,仅对菱形对角线十字上的块进行搜索
HM的则是全搜索和TZSearch以及对TZSearch的优化的搜索。

3. MV预测

HEVC在预测方面提出了两种新的技术–Merge && AMVP (Advanced Motion Vector Prediction)都使用了空域和时域MV预测的思想,通过建立候选MV列表,选取性能最优的一个作为当前PU的预测MV,二者的区别:

· Merge可以看成一种编码模式,在该模式下,当前PU的MV直接由空域或时域上临近的PU预测得到,不存在MVD;而AMVP可以看成一种MV预测技术,编码器只需要对实际MV与预测MV的差值进行编码,因此是存在MVD的

· 二者候选MV列表长度不同,构建候选MV列表的方式也有所区别

Merge
当前块的运动信息可以通过相邻块的PUs运动信息推导出来,只需要传输合并索引,合并标记,不需要传输运动信息。

空间合并候选:从5个不同位置候选中选择4个合并候选

h265,音视频开发进阶,音视频,h.264,h.265,音视频编解码,音视频开发

图中便是5个PU,但是标准规定最多四个,则列表按照A1–>B1–>B0–>A0–>(B2)的顺序建立,B2为替补,即当其他有一个或者多个不存在时,需要使用B2的运动信息。

时间合并候选:从2个候选中选择1个合并候选
从C3、H中选择一个:

h265,音视频开发进阶,音视频,h.264,h.265,音视频编解码,音视频开发

AMVP
构造一个时空PUs的运动矢量候选列表,当前PU遍历候选列表,通过SAD选择最优预测运动矢量。

空间运动矢量候选:从5个位置中左侧、上侧分别选1个共2个候选

而AMVP的选择顺序,左侧为A0–>A1–>scaled A0–>scaledA1,其中scaled A0表示将A0的MV进行比例伸缩。
上方为B0–>B1–B2–>(scaled B0–>scaled B1–>scaled B2)。

然而,x265并不在乎标准,我们要的就是速度,所以在x265的代码中,只能看到它使用AMVP且对应的变量是

h265,音视频开发进阶,音视频,h.264,h.265,音视频编解码,音视频开发

且对左侧和上侧分别if-else,选出两个。

时间运动矢量候选:从2个不同位置候选中选择1个候选

C0(右下) represents the bottom right neighbor and C1(中心) represents the center block.

h265,音视频开发进阶,音视频,h.264,h.265,音视频编解码,音视频开发

Skip vs Merge:

h265,音视频开发进阶,音视频,h.264,h.265,音视频编解码,音视频开发

分数像素内插:
用于产生非整数采样位置像素值的预测样本。

六、量化变换

七、其它

熵编码
目前HEVC规定只使用CABAC算术编码。

去块效应滤波器
消除反量化和反变换后由于预测误差产生的块效应,即块边缘处的像素值跳变。

h265,音视频开发进阶,音视频,h.264,h.265,音视频编解码,音视频开发

自适应样点补偿
通过对重建图像进行分类,对每一类图像像素值进行加减1,从而达到减少失真,提高压缩率,减少码流的作用。

目前自适应样点补偿分为带状补偿,边缘补偿:

1. 带状补偿,按像素值强度划分为不同的等级,一共32个等级,按像素值排序,位于中间的16个等级进行补偿,将补偿信息写进码流,其余16个等级不进行补偿,减少码流。

2. 边缘补偿,选择不同的模板,确定当前像素类型,如局部最大,局部最小,或者图像边缘。

Wavefront Parallel Processing (WPP)
WPP的并行技术是以一行LCU块为单位进行的,但是不完全截断LCU行之间的关系,如下图,Thread1的第二个块的CABAC状态保存下来,用于Thread2的起始CABAC状态,依次类推进行并行编码或解码,因此行与行之间存在很大的依赖关系。通常该方法的压缩性高于tiles。

本文福利, 免费领取C++音视频学习资料包、技术视频/代码,内容包括(音视频开发,面试题,FFmpeg ,webRTC ,rtmp ,hls ,rtsp ,ffplay ,编解码,推拉流,srs)↓↓↓↓↓↓见下面↓↓文章底部点击免费领取↓↓

到了这里,关于H.265视频编码与技术全析的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 音视频开发 RTMP协议发送H.264编码及AAC编码的音视频(C++实现)

    RTMP(Real Time Messaging Protocol)是专门用来传输音视频数据的流媒体协议,最初由Macromedia 公司创建,后来归Adobe公司所有,是一种私有协议,主要用来联系Flash Player和RtmpServer,如 FMS , Red5 , crtmpserver 等。RTMP协议可用于实现直播、点播应用,通过 FMLE(Flash Media Live Encoder) 推送音

    2023年04月08日
    浏览(45)
  • 【秒懂音视频开发】15_AAC编码实战

    本文将分别通过命令行、编程2种方式进行AAC编码实战,使用的编码库是libfdk_aac。 fdk-aac对输入的PCM数据是有参数要求的,如果参数不对,就会出现以下错误: 采样格式 必须是16位整数PCM。 采样率 支持的采样率有(Hz): 8000、11025、12000、16000、22050、24000、32000 44100、48000、

    2024年02月03日
    浏览(71)
  • 音视频处理 ffmpeg中级开发 H264编码

    libavcodec/avcodec.h 常用的数据结构 AVCodec 编码器结构体 AVCodecContext 编码器上下文 AVFrame 解码后的帧 结构体内存的分配和释放 av_frame_alloc 申请 av_frame_free() 释放 avcodec_alloc_context3() 创建编码器上下文 avcodec_free_context() 释放编码器上下文 解码步骤 avcodec_find_decoder 查找解码器 avcod

    2024年02月01日
    浏览(57)
  • RK3568平台开发系列讲解(音视频篇)H264 的编码结构

    🚀返回专栏总目录 沉淀、分享、成长,让自己和他人都能有所收获!😄 📢视频编码的码流结构其实就是指视频经过编码之后得到的二进制数据是怎么组织的,换句话说,就是编码后的码流我们怎么将一帧帧编码后的图像数据分离出来,以及在二进制码流数据中,哪一块数

    2024年02月09日
    浏览(37)
  • Qt/C++音视频开发69-保存监控pcm音频数据到mp4文件/监控录像/录像存储和回放/264/265/aac/pcm等

    用ffmpeg做音视频保存到mp4文件,都会遇到一个问题,尤其是在视频监控行业,就是监控摄像头设置的音频是PCM/G711A/G711U,解码后对应的格式是pcm_s16be/pcm_alaw/pcm_mulaw,将这个原始的音频流保存到mp4文件是会报错的,在调用avformat_write_header写文件头的时候提示(-22) Invalid argument,

    2024年04月11日
    浏览(39)
  • 音视频数据处理-H265/HEVC视频码流分析

    一、H265概述 H265/HEVC(Hight Efficiency Video Coding)是由ITU-T和ISO/IEC两大组织在H264/AVC的基础之上推出的新一代高效视频编码标准,主要为应对高清和超高清视频在网络传输和数据存储方面带来的挑战。上一篇文章对H264/AVC视频码流进行了详细的分析,本文继续从数据处理的角度对

    2024年02月11日
    浏览(36)
  • 音视频技术开发周刊 | 305

    每周一期,纵览音视频技术领域的干货。 新闻投稿:contribute@livevideostack.com。 大神回归学界:何恺明宣布加入 MIT 「作为一位 FAIR 研究科学家,我将于 2024 年加入麻省理工学院(MIT)电气工程与计算机科学系 EECS 担任教职。」 AI 领域的著名学者,ResNet 发明人何恺明,最近在

    2024年02月14日
    浏览(39)
  • 音视频技术开发周刊 | 273

    每周一期,纵览音视频技术领域的干货。 新闻投稿:contribute@livevideostack.com。 「紧急通知」LiveVideoStackCon 2022 音视频技术大会北京站改期 各位LVSer们: 因疫情影响,北京近期不再允许举办大型线下活动,我们无奈且抱歉的通知大家LiveVideoStackCon 2022音视频技术大会北京站大会

    2023年04月22日
    浏览(34)
  • 音视频技术开发周刊 | 297

    每周一期,纵览音视频技术领域的干货。 新闻投稿:contribute@livevideostack.com。 Geenee AR为品牌商和零售商提供虚拟试穿应用 这意味着Geenee AR的虚拟试穿解决方案能够与品牌商现有的销售渠道无缝集成。 谁说苹果掉队了?WWDC上只字未提AI,却已低调入场大模型 尽管苹果没有在

    2024年02月08日
    浏览(37)
  • 音视频技术开发周刊 | 298

    每周一期,纵览音视频技术领域的干货。 新闻投稿:contribute@livevideostack.com。 AI艺术在北京798,展望人工智能与环境的未来 本文很有意思的提出了个假设,通过人工智能和艺术家协作与实践产生环绕地球的叙事,去开启置身于AI时代与生态之中的想象。在这种协作中,如何重

    2024年02月09日
    浏览(34)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包