EDN首页   博客首页 用户登陆  |  注册
aaa
发表于 2006/9/11 8:46:50

3

关于投票

基于IP的H.264关键技术

http://www.upsdn.net/html/2004-12/195.html

一、 引言

H.264是ITU-T最新的视频编码标准,被称作ISO/IEC14496-10或MPEG-4 AVC,是由运动图像专家组(MPEG)和ITU的视频编码专家组共同开发的新产品。H.264分两层结构,包括视频编码层和网络适配层。视频编码层处理的是块、宏块和片的数据,并尽量做到与网络层独立,这是视频编码的核心,其中包含许多实现错误恢复的工具;网络适配层处理的是片结构以上的数据,使 H.264能够在基于RTP/UDP/IP、H.323/M、MPEG-2传输和H.320协议的网络中使用。

二、 IP网络对视频压缩的限制

1. H.264的应用场合

在讨论基于IP的H.264之前,有必要先阐述一下H.264与IP网络有关的应用场合及其对传输和编解码器的要求。下面介绍对话应用、下载服务和流媒体应用三种场合。

对话应用,比如像视频电话和视频会议,有严格的时延限制,要求端到端时延小于1s,最好小于 100ms。编解码器的参数能实时调整,错误恢复机制要根据实际网络变化而改变。编解码的复杂度不能很高,比如双向预测的模式就不能被采用。

下载服务,可使用可靠的传输协议如FTP和HTTP将数据全部传输。由于这种应用的非实时性,编码器可以通过优化进行高效编码,而且对时延和错误恢复机制没有要求。

流媒体服务应用,对时延要求介于上面两者之间,初始化时延是10s以内。与实时编码相比对时延要求降低,编码器可以进行优化实现高效编码(比如双向预测)。然而通常流媒体服务使用不可靠的传输协议,所以编码时要进行差错控制并进行信道纠错编码。

本文主要讨论对话应用和流媒体应用,这两种应用基于IP网络。IP网络又可分为三种类型:不可控 IP网络(如 Internet)、可控IP网络(广域网)和无线IP网络(如3G网络)。这三种IP网络有不同的最大传输单元尺寸(MTUsize)、比特出错概率和 TCP使用标记。最大传输单元尺寸是网络层最大的分组长度,H.264编码时要使片的长度小于MTU尺寸,这样可避免在网络层再进行一次数据的分割。两个 IP节点之间的MTU尺寸是动态变化的,通常假定有线IP网络的MTU尺寸是1.5千字节,无线网络的MTU尺寸是100字节。可见要适用于无线网络的 H.264必须采用数据分割技术使得片的长度小于MTU尺寸。TCP传输控制协议能够解决网络拥塞引起的分组丢失问题,而在无线网络中,分组丢失是由于链路层错误引起的,TCP并非很好的解决办法,要采用差错控制协议。

2. H.264使用的协议环境

对话应用和流媒体应用使用同一协议组,下面进行讨论。

网络层协议:使用IP(网际协议)。每个IP分组单独从发方出发,经过一系列的路由器到达收方。 IP将大于 MTU尺寸的分组进行数据分割、重组。每个分组的传输时间都有所不同。IP头20个字节由校验码来保证,但数据没有保护。IP分组最大值为64千字节,但由于MTU尺寸的限制,一般没有这么大。

传输层协议:主要有两个协议,TCP和UDP。TCP提供面向字节的可靠传输服务,以重传和超时等机制作为差错控制的基础。由于对时延的不可预测,并不适用于实时通信传输。UDP提供不可靠的数据报传输业务。UDP头包含的校验数(8字节)可以发现和去掉含有比特错误的分组。UDP允许分组传输过程中出现丢失、复制、改序等。使用UDP协议时,高层必须使用错误恢复协议。

应用层传输协议:使用RTP(实时传输协议)。该协议和IP/UDP结合使用,是面向会话的协议。每个RTP分组包含RTP头标,载荷头标(可选)和载荷本身。RTP头标的内容见图1,基本选项占用12字节,标记位标记有同一时间戳的一组分组的结束。RTP协议使发送方将数据分为大小合理的分组,并将解码方观察到的网络特征反馈给发送方,使发送方可以动态调整比特率和抗误码机制。RTP分组和RTP载荷规范在第四部分讨论。

应用层控制协议:有H.245协议、SIP和SDP,或RTSP。这些协议可以实现流媒体的控制,收发方的协商和控制动态会话层。

三、H.264的错误恢复工具

错误恢复的工具随着视频压缩编码技术的提高在不断改进。旧的标准(H.261、H263、MPEG -2的第二部分)中,使用片和宏块组的划分、帧内编码宏块、帧内编码片和帧内编码图像来防止错误的扩散。之后改进的标准(H.263+、MPEG-4)中,使用多帧参考和数据分割技术来恢复错误。H.264标准在以前的基础上提出了三种关键技术:(1)参数集合,(2)灵活的宏块次序(FMO),(3)冗余片(RS)来进行错误的恢复。

1. 帧内编码

H.264中帧内编码的技术和以前标准一样,值得注意的是:

(1)H.264中的帧内预测编码宏块的参考宏块可以是帧间编码宏块,帧内预测宏块并不像 H.263中的帧内编码一样,而采用预测的帧内编码比非预测的帧内编码有更好的编码效率,但减少了帧内编码的重同步性能,可以通过设置限制帧内预测标记来恢复这一性能。

(2)只包含帧内宏块的片有两种,一种是帧内片(Islice),一种是立即刷新片(IDRslice),立即刷新片必存在于立即刷新图像(IDRpicture)中。与短期参考图像相比,立即刷新图像有更强壮的重同步性能。

在无线IP网络环境下,为了提高帧内图像的重同步性能,要采用率失真优化编码和设置限制帧内预测标记。

2. 图像的分割

H.264支持一幅图像划分成片,片中宏块的数目是任意的。在非FMO模式下,片中的宏块次序是同光栅扫描顺序,FMO模式下比较特殊。片的划分可以适配不同的MTU尺寸,也可以用来交织分组打包。

3. 参考图像选择

参考图像数据选择,不论是基于宏块、基于片,还是基于帧,都是错误恢复的有效工具。对于有反馈的系统,编码器获得传输中丢失图像区域的信息后,参考图像可以选择解码已经正确接收的图像对应的原图像区域作参考。在没有反馈的系统中,将会使用冗余的编码来增加错误恢复性能。

4. 数据的划分

通常情况下,一个宏块的数据是存放在一起而组成片的,数据划分使得一个片中的宏块数据重新组合,把宏块语义相关的数据组成一个划分,由划分来组装片。在H.264中有三种不同的数据划分。

(1)头信息划分:包含片中宏块的类型,量化参数和运动矢量,是片中最重要的信息。

(2)帧内信息划分:包含帧内CBPs和帧内系数,帧内信息可以阻止错误的蔓延。

(3)帧间信息划分:包含帧间CBPs和帧间系数,通常比前两个划分要大得多。

帧内信息划分结合头信息解出帧内宏块,帧间信息划分结合头信息解出帧间宏块。帧间信息划分的重要性最低,对重同步没有贡献。当使用数据划分时,片中的数据根据其类型被保存到不同的缓存,同时片的大小也要调整,使得片中最大的划分小于MTU尺寸。

解码端若获得所有的划分,就可以完整重构片;解码端若发现帧内信息或帧间信息划分丢失,可用的头信息仍然有很好的错误恢复性能。这是因为宏块类型和宏块的运动矢量含有宏块的基本特征。

5. 参数集的使用

序列的参数集(SPS)包括了一个图像序列的所有信息,图像的参数集(PPS)包括了一个图像所有片的信息。多个不同的序列和图像参数集经排序存放在解码器。编码器参考序列参数集设置图像参数集,依据每一个已编码片的片头的存储地址选择合适的图像参数集来使用。对序列的参数和图像的参数进行重点保护才能很好地增强H.264错误恢复性能。

在差错信道中使用参数集的关键是保证参数集及时、可靠地到达解码端。例如,在实时信道中,编码器用可靠控制协议及早将他们以带外传输的方式发送,使控制协议能够在引用新参数的第一个片到达之前把它们发给解码器;另外一个办法就是使用应用层保护,重发多个备份文件,确保至少有一个备份数据到达解码端;第三个办法就是在编解码器的硬件中固化参数集设置。

6. 灵活的宏块次序(FMO)

灵活的宏块次序是H.264的一大特色,通过设置宏块次序映射表(MBAmap)来任意地指配宏块到不同的片组,FMO模式打乱了原宏块顺序,降低了编码效率,增加了时延,但增强了抗误码性能。FMO模式划分图像的模式各种各样,重要的有棋盘模式、矩形模式等。当然FMO模式也可以使一帧中的宏块顺序分割,使得分割后的片的大小小于无线网络的MTU尺寸。经过FMO模式分割后的图像数据分开进行传输,以棋盘模式为例,当一个片组的数据丢失时可用另一个片组的数据(包含丢失宏块的相邻宏块信息)进行错误掩盖。实验数据显示,当丢失率为(视频会议应用时)10%时,经错误掩盖后的图像仍然有很高的质量。

7. 冗余片方法

前边提到了当使用无反馈的系统时,就不能使用参考帧选择的方法来进行错误恢复,应该在编码时增加冗余的片来增强抗误码性能。要注意的是这些冗余片的编码参数与非冗余片的编码参数不同,也就是用一个模糊的冗余片附加在一个清晰的片之后。在解码时先解清晰的片,如果其可用就丢弃冗余片;否则使用冗余模糊片来重构图像。

四、H.264中实时传输协议(RTP)

1. RTP载荷规范

在第二部分已经对H.264的网络协议环境作了阐述,这里要详细讨论RTP的载荷规范和抗误码性能。RTP通过发送冗余信息来减少接收端的丢包率,会增加时延,与冗余片不同的是它增加的冗余信息是个别重点信息的备份,适合于应用层的非等重保护。下边阐述与多媒体传输有关的3个规范。

(1)分组复制多次重发,发送端对最重要的比特信息分组进行复制重发,使得保证接收端能至少正确接收到一次,同时接收端要丢弃已经正确接收的分组的多余备份。

(2)基于分组的前向纠错,对被保护的分组进行异或运算,将运算结果作为冗余信息发送到接收方。由于时延,不用于对话型应用,可用于流媒体。

(3)音频冗余编码,可保护包括视频在内的任何数据流。每个分组由头标、载荷以及前一分组的载荷组成,H.264中可与数据分割一起使用。

2. H.264 NAL单元的概念

H.264 NAL单元对编码数据进行打包,NAL单元由1字节的头,3个定长的字段和一个字节数不定的编码段组成。

头标的语法:NALU类型(5bit)、重要性指示位(2bit)、禁止位(1bit)。

NALU类型:1~12由H.264使用,24~31由H.264以外的应用使用。

重要性指示:标志该NAL单元用于重建时的重要性,值越大,越重要。

禁止位:网络发现NAL单元有比特错误时可设置该比特为1,以便接收方丢掉该单元。

3. 分组打包的规则

(1)额外开销要少,使MTU尺寸在100~64k字节范围都可以;

(2)不用对分组内的数据解码就可以判别该分组的重要性;

(3)载荷规范应当保证不用解码就可识别由于其他的比特丢失而造成的分组不可解码;

(4)支持将NALU分割成多个RTP分组;

(5)支持将多个NALU汇集在一个RTP分组中。

RTP的头标可以是NALU的头标,并可以实现以上的打包规则。

4. 简单打包

一个RTP分组里放入一个NALU,将NALU(包括同时作为载荷头标的NALU头)放入RTP的载荷中,设置 RTP头标值。为了避免IP层对大分组的再一次分割,片分组的大小一般都要小于MTU尺寸。由于包传送的路径不同,解码端要重新对片分组排序,RTP包含的次序信息可以用来解决这一问题。

5. NALU分割

对于预先已经编码的内容,NALU可能大于MTU尺寸的限制。虽然IP层的分割可以使数据块小于 64千字节,但无法在应用层实现保护,从而降低了非等重保护方案的效果。由于UDP数据包小于64千字节,而且一个片的长度对某些应用场合来说太小,所以应用层打包是 RTP打包方案的一部分。

新的讨论方案(IETF)应当符合以下特征:

(1)NALU的分块以按RTP次序号升序传输;

(2)能够标记第一个和最后一个NALU分块;

(3)可以检测丢失的分块。

6. NALU合并

一些NALU如SEI、参数集等非常小,将它们合并在一起有利于减少头标开销。已有两种集合分组:

(1)单一时间集合分组(STAP),按时间戳进行组合;

(2)多时间集合分组(MTAP),不同时间戳也可以组合。

五、结束语

本文重点讲述了在IP网络的限制条件下H.264进行错误恢复的几种有力工具,但在不同的IP网络中要组合使用各种工具才能实现高效率编码和传输。因为目前无线网络对MTU尺寸和时延的限制,所以错误恢复工具可以结合使用图像的分割、数据的划分和RTP分组技术,避免使用冗余信息和反馈来提高错误恢复性能;另外高效率的FMO编码模式可以大大提高编码的抗分组丢失性能。

系统分类: 消费电子  |  用户分类: h.264编解码  |  标签: 无标签  |  来源: 无分类  | 

点击查看原文

发表评论 阅读全文(3217) | 回复(3)

发表于 2006/8/12 19:42:27

1

关于投票

H.264详解

为什么叫H.264

    H.264是一种视频高压缩技术,全称是MPEG-4 AVC,用中文说是“活动图像专家组-4的高等视频编码”,或称为MPEG-4 Part10。它是由国际电信标准化部门ITU-T和规定MPEG的国际标准化组织ISO/国际电工协会IEC共同制订的一种活动图像编码方式的国际标准格式,这是我们叫惯了的MPEG中的一种,那为什么叫H.264呢?

    原来国际电信标准化部门从1998年就H.26L的H.26S两个分组,前者研制节目时间较长的高压缩编码技术,后者则指短节目标准制订部门。H.26S 的标准化技术的名称为H.263,听起来很耳生,但实质上却早在用了,还被骂得很激烈。因为,H.263先入为大,一直以MPEG-4大内涵的名字在用。 H.263的全称为MPEG-4 Visual或MPEG-4 Pall Ⅱ,即MPEG-4视频简单层面的基础编码方式。2001年后,国际电信标准化部门ITU-T和MPEG的上级组织国际标准化组织ISO/国际电气标准会议IEC成立了联合视频组JVT,在H.26L基础进行H.264的标准化。

    2002年12月9日~13日,在日本香川县淡路岛举行的MPEG聚会上确定了相关技术的规格。规格书定稿后,2003年3月17日,H.364的技术格式最终稿国际标准规格(FDIS)被确立。目前软件和LSI芯片,服务及设备也都进入了使用阶段。格式书中,列出了比特流规定,解码必要格式,和可供参考的编码记载。

    为了不引起误解,ITU-T推荐使用H.264作为这一标准的正式名称。实际上,MPEG-4里还有MPEG-4 Audio和MPEG-4 System的不同规格。

    MPEG-4挨骂是因为MPEG-4 Visual许可收费离谱引起的。别以为有了专利就可以随意向人要钱了,专利的最终目的的是使全社会的智力资料更合理地使用,防止重复劳动,并不是犒赏最先发明者。按唯美史观,当社会技术发展到某一阶段时,新技术必然会出现。不是你、就是他总会发明出来,只是细节、时间、成本上的微小差别。历史上,这样不约而同的发明很多,无线电的发明者是马可尼还是波波夫,一直在西方和东方技术史界争论。

    而当专利技术成为国际标准的一部份后,问题就更加复杂了。国标标准是强制的,向其中的专利付费是否有垄断之嫌?标准中的技术专利请求,是否合理?如何区分正当的请求和不正当的请求?等等一系列的理论、法律和道德问题都出来了。要尊重专利法,也要遵守反垄断法。这两年国际上围绕MPEG-4收费问题的大争论就是由此而起。
在标准化进程中,专利的争端正在增加,任何黑白两极的判断都无法令人满意。但奇怪的是标准中的专利争端发展到要求判决的案例几乎没有,都是当事者幕后交易解决,这使得不明确的法理更陷入恶性循环之中。同时也助长了用户对盗版的宽容,一边是抢我的剪径强资,另一边是偷你的小贼,怎么讲道德?!
 
MPEG-4的收费问题主要是从向传输环节收费引起的。MPEG-4对解码器和编码器的收费已经比MPEG-2低了很多,这是各种压缩技术竞争的结果。但MPEG-2不对传输MPEG-2压缩图像的服务环节收费,而MPEG-4则要对内容配送者收取每分钟0.0333美分的许可费。钱数听起来不大,但伦理上却有很大的差别。打个比方,你买了台彩电,必要的专利费用已经通过彩电厂转交到专利技术持有者的手中。而当你打的把这台彩电运回家的时候,出租车主也要向专利持有者交费!能不引起轩然大波吗。

    现在的专利收费结构已经相当商业化。一种产品、一个系统或一套技术标准中,包含有许许多多公司的专利技术,使用企业很难与一个个技术的发明者直接交涉签约,这样就出现了一种专利管理公司的企业。它把某一产品的一个个技术从专利持有者手中买下来,约定好收益的分配方案,再由它人使用技术的企业中收取许可费。需要用这一产品技术的企业就只需与专利管理公司打交道,操作方便多了。但专利管理公司和著作权保护企业一样,实际上是一个中间商,两头赚钱,未必把社会效益放在最高地位。

    现在的MPEG-4,也即MPEG-4 Visual是由美国MPEG LA公司进行专利许可管理的,他同时也在管理MPEG-2的专利,目前还在争取H.264的专利许可权。MPEG LA公司于2002年9月就开始募集H.264的主要专利,想采取先入为主的手段取得管理权。由于大量企业对MPEG-4收费制度不满,2003年6月, MPEG-4的支持团体M4IF(MPEG-4工业论坛),决定数据流标准格式的美国ISMA(国际数据流媒体协会)和多媒体通信有关业界团体IMTC (国际多媒体通信协会)发起召开H.264的许可制度说明会。总共有专利持有者和使用者团队45个,56人参加,对有关H.264许可问题进行早期意见交换,希望协调各方面的要求和利益。关于方面其它信息,我们稍后再细述,先看看H.264的特色吧。
 
H.264用大运算量来换取高压缩率、高画质

    H.264受人追捧有三大原因:高性能、国际标准和公正的无差别许可制度。

    首先是超高压缩率,其压缩率为MPEG-2的2倍以上,MPEG-4的1.5至2倍。这样的高压缩率是以编码的大运算量来换取的,H.264的编码处理计算量有MPEG-2的十多倍。不过其解码的运算量并没有上升很多,故对用户接收播放来说没有什么难度。

    从另一角度,编码的大运算量现在也不是什么大问题。MPEG2是1994年推出的,当时微处理器的工作频率才100MHz,主存储器容量也不满10MB。 MPEG-2那样的压缩运算适应了当时的技术水平。而现在CPU的工作频率可上升到3GMz,DRAM用到256MB,提升了30倍上下,运算量也不怕。实验表明在奔腾4处理器的3GHz电脑上,可用软件实现D1(720×80)格式图像的H.264实时编码。

    而且H.264才标准化,运算顺序还有改善的空间。当作为国际标准确立后,还能结集起全世界的精英来优化处理。这也反应出技术发展的必然性,唯物史观。

    高压缩率使图像的数据量减少,给存储和传输带来了方便。加上基本规格公开的国际标准和公正的许可制度,所以,电视广播、家电和通信三大行业都进入到H.264的实际运用研发中心,见图1。
 
H264的应用领域H.264又一项减少运算量的方法是在很多地方引入层次化运算,把在矩阵数据块变成小块运算,使计算式变得更加简单,见图5。
 
层次话提高运算效率
 
    在DCT中采用时,8×8像素块层次化到2×2像素块,变换就变得快捷。运动补偿中也可利用。检出运动矢量时,最初的模块大,运动矢量的检出范围大,搜索快捷。当检出到有动作的部分再调入小模块细分析。H.264进行运动预测的模板多,一旦先进全面检索,需要的时间就很长,运算量也大。用层次化处理,先进行模板的收缩,接着小范围检索,就能减少计算量。在帧内预测中利用层次化后,残差计算的范围就能变小,同样有利于减少计算量。

    H.264与MPEG-2和MPEG-4的不同还存在于纠错编码块中,H.264的纠错编码为内容自适应可变长度码(CAVLC)和内容自适应二进制算法编码(CABAC),能提高纠错能力。而MPEG-2和MPEG-4杰霍夫曼编码。另外,还加入了MPEG-2和MPEG-4没有环路滤波器,有降低噪声的效果。H.264的整数变换以4×4像素块为单位,已比原来的8×8像素块的块噪声少,再次降低,画质得到了进一步提高。

    从应用角度看,H.264有三个层面,分为主要用于电视会议等通信的基线层面,面向高画质用途和录像的主层面以及面向内容配送的扩展层面。各层面的清晰度和编码速度取值不同。

    基线层面的主要技术为图像只含有I画面,P画面,系统内有环路滤波,1/4帧间预测,4:2:0 YUV格式输入,基于VLC的纠错编码,弹性宏块指令等。主要层面则在基线层面基础上加入了CABAC运算编码技术和基于双向预测的B画面,滤波(接口)等技术,但不含弹性宏块指令。扩展层面则在基线层面里加入B画面和滤波编码等。

    H.264分有4.1种不同样式的图像水平。水平1的编码速度较小,最大只能达64kbps,像素格式为QCIF(176×144),30帧/秒和Sub QCIF(128×96),60帧/秒。适合手机、PDA等屏幕播放视频用。水平2的编码速度可达2Mbps,图像的像素格式为CIF(352× 288),30帧/秒。水平3、水平4分别对应SDTV、HDTV图像格式,编码速度为10Mbps,20Mbps。另外,还有能支持更高清晰度的水平 5,编码速度高达135Mbps。故总称为4.1水平。在各水平更细的分类中,最大编码速度也还有不同规定。
最后,把H.264与MPEG-2/MPEG-4主要的不同技术比较与下表1。
 
H.264与MPEG-4、MPEG-2比较
 
 
    针对H.264的特点,编码软件和编码LSI开发的厂家都把编码/解码运算量的减少作为方向来研究,所以,实用前景大好。大多数半导体厂认为在H.264中使用削减运算量方法后,能获得相当于MPEG-2编码LSI的2倍左右的处理能力。

    由于技术的日益成熟,半导体厂商已在进行H.264的编码/解码LSI的开发。特别是HDD录像机和DVD录像机等设备中,采用H.264的实例已很多,更引起了半导体厂商的关心。加之,H.264采用的动画编码方式和音频编码方式具有多样化特性,今后几乎将会是全部厂商的主要规格之一。

    以目前芯片将H.264实用化的研究也在进行之中。用德州仪器(TI)公司制造的DSP[TMS320C64××]对以H.264预先编码的图像已证实能进行实时解码。TI公司正在开发的C6×系列DSP LSI,将在视频编码电路和存储控制电路中,加入对应H.264和MWV等的编码/解码功能。
TI公司推出的可以对MPEG-4编码/解码的用于便携机开发的TMS320DM270,只要用上新的CPU提高处理能力,就可用于H.264的编码/解码。

    已经有MWA9的编码/解码DSP样品出厂的美国模拟设备公司也在向H.264前进。

    图6是美国InStat/MDR公司对H.264功能LSI产量的预测。预测还只基于H.264的许可制度与MPEG-2一样的前提下进行的。
 
H.264 LSI生产量
 
H.264的许可制度有望较友善

    H.264替代MPEG-4的呼声很高,除了其高性能外,作为国际标准和公正的无差别许可制度也至关重要。

    MPEG-4的许可体系引起了几大行业,特别是信息配送行业的强烈反对,使得新国际标准的许可收费不得不向更为友善的方向发展。表2是几种视频压缩技术的许可收费价格。
 
许可费用
 
    表中可见,MPEG LA公司提出的MPEG-4配送过程也要付费是空前绝后的。视频压缩产品只对终端收费合乎常情,因而招至了很大反抗,直到今日仍在遭人反对。而且对采用 MPEG-4的产品和服务还分成6种标准:用户记录视频,互联网视频,车载移动视频,特有用户视频,存储视频和企业视频。连简单的移动电视服务,如从现场到电视中心通讯时,若使用MPEG-4视频的话,也需支付移动视频的许可费。

    因此,连原定在地面数字电视的编码方式中采用MPEG-4的日本ARIB,也因许可费问题而开始研讨是否改用H.264。拥有各种内容服务业者的移动内容论坛MCF也于2003年5月23日,致涵MPEG LA公司反对内容收费,要求重新考虑许可条件。MPEG LA也已松口表示希望以能相互满意的形式交涉。

    随着掌握压缩技术的企业增加和用户巨增,H.264的许可管理收费受到二个方面的压力。一、用户要求低价格,最好免费使用;二、持有压缩技术的企业增加,供应空间大,不得不低价出售。目前具有高压缩率特征的活动图像编码技术的企业不少,如,美国数据流公司的XVD,能在一片CD-R碟片上放入2小时图像,并能实时编码。美国On2技术公司的活动图像编码技术VP5和新版本VP6,国内推出的EVD就采用这种编码技术。美国AOL(America Online)公司也有新压缩技术在进行许可操作。微软的WMV 9也在向家电产品扩展,如美国工艺家庭娱乐公司使用WMV 9压缩,将HDTV画质的“终结者2:审判日”放入DVD-ROM内。
为此,H.264的许可制度设计有两点引人之处:第一,部分格式将无偿使用,H.264的基线层面全员免费,无偿使用;其二,许可体系要比MPEG-4单纯,公正无差别对待用户和专利持有者。以及其它能促进普及的优惠政策,如早期低价格许可等。

    基线层面的免费是以ITL-T主要活动的企业为中心推动的。现得到美国苹果公司和美国Cisco系统公司、中国联想公司、芬兰诺基亚、美国On2技术公司、德国西门子、美国德州仪器公司等的支持,并有美国政府为其撑腰。

    基线层面免费的最大目的是加速H.264的普及。当基线层面普及以后,收费的主层面和扩展层面就能带动起来。尽管主要层面和扩展层面要收费,但从趋势看,许可费应较为便宜,因为各种编码技术的许可费都有不断下降的趋势,目前很热门的美国微笑WMV 9的许可费就比MPEG-2和MPEG-4要低,见表2。而且微软的契约期为10年,比MPEG-2和MPEG-4还长。

    从MPEG-2向MPEG-4的发展看,编码器(电路加软件)和解码(电路加软件)的费用就降到1/10,WMV9更低。可以预计H.264的许可费用会比WMV 9还低。

    前文提到的45个团体的联合会传出说法,如果H.264采用MPEG-4 Visual一样的许可体系,H.264就可能不被采用,态度强硬。标准中的专利收费收益已远不止收回投入的开发成本,而是在不断地获取暴利,故降低收费在所必然。

    当然,只要没有定局,变化依然存在。专利持有者的想法也各有不同,采用无差别对待原则是否行得通。专利实施充满着大量利益诱惑,追名逐利者大有人在。目前已经有两家公司申称对H.264具有许可管理权。在专利应用前就开始抢专利管理权的现象是前所未有的,两家公司还都有渊源。一家是实际持有MPEG-2和 MPEG-4 Visual许可管理的美国MPEG LA公司。另一家是进行MPEG-2 AAC和MPEG-4 Audio许可管理的美国杜比实验室的子公司美国Vialicensing公司。最终有哪一家公司管理,还是分割管理,现在都不清楚。

    但又好、又便宜,始终是技术发展的方向。

系统分类: 嵌入式  |  用户分类: h.264编解码  |  标签: 无标签  |  来源: 无分类  | 

点击查看原文

发表评论 阅读全文(2636) | 回复(0)

发表于 2006/8/11 23:09:21

1

关于投票

谈基于可编程处理器的H.264技术的实现

一、引言

  随着多媒体编码技术的发展,视频压缩标准在很多领域都得到了成功应用,如VCD(MPEG-1)、视频会议(H.263)、DVD(MPEG-2)、机顶盒(MPEG-2)等等。

  而网络带宽的不断提升(ADSL接入从以前的512kbit/s提升到现在的1Mbit/s,不久还将升到2Mbit/s,甚至更高)和高效视频压缩技术的发展使得人们逐渐把关注的焦点转移到了宽带网络数字电视(IPTV)、流媒体等基于传输的业务上来。带宽的增加为流式媒体的发展铺平了道路,而高效的视频压缩标准的出台则是流媒体技术发展的关键。

  H.264是ISO/IEC MPEG联合ITU-T VCEG成立的联合视频组(JVT)制定的一个全新的标准。相对于H.263+和MPEG-4(Simple Profile),H.264的码率平均降低了50%,以700kbit/s的码流速率提供了接近DVD的画面质量。

  H.264能面向各种应用场合(从低比特率到高比特率),其算法本身也包含了丰富的基于压缩和网络传输的各种编码选项。可编程处理器固有的灵活性决定其为H.264的理想实现平台。众所周知,H.264的高效性是建立在其实现的高复杂度基础上的,就其Baseline而言,解码器复杂度将是H.263解码器的3倍左右,而编码器的复杂度更是高达10多倍。近年来,处理器芯片性能在不断地提高,其中包括越来越高的处理器主频,强大的运算功能以及丰富的外设。但是与当今日新月异的半导体技术、工艺相比,由于片上系统(SoC)的需求不断提高,处理器的体系结构仍具有极大的发展空间。特别是H.264作为一个前景广阔而又具有挑战性的新生“事物”,必将带动新一轮处理器架构的革新。而算法和架构的互动将会成为这一轮革新的强有力的驱动。

二、应用:处理器架构革新的驱动力

  事实上,处理器架构一直是在应用的驱动下发展、进步的。

1. DSP在数字信号处理算法驱动下的产生、发展

  在过去的几十年中,随着半导体工艺与集成电路设计技术的逐渐发展,微处理器逐渐在工业控制等领域得到应用,简单的智能控制与少量计算任务的实现,都是由我们通常所谓的单片机来完成的。单片机虽然集成了CPU、RAM、ROM(EPROM或EEPROM)、时钟、定时/计数器、多种功能的串行和并行I/O口等部件,但是其面向的应用场合主要是工业控制中各种事件的管理调度等,运算处理能力不足一直是它的缺陷。

  特别是随着信息化的进程和信号处理理论与算法等的迅速发展,需要处理的数据量越来越大,对实时性和精度的要求越来越高,单片机越来越难以满足不断上升的要求,DSP应运而生。

  DSP的产生背景决定了其架构的重点更多的是对特定的数字信号处理算法的强化支持。典型的数字信号处理算法,例如在有限长冲击响应滤波器(FIR)的实现中,需要在系数和输入样本的滑动窗口间作乘法,然后将所有的乘积进行累加。类似的运算在数字信号处理过程中大量地重复发生,使得为此设计的器件必须提供专门的支持。通常DSP处理器使用专门的硬件来实现单周期乘法,并且还增加了特殊的累加器寄存器来处理多个乘积的和。为了充分体现专门的乘法累加硬件的好处,几乎所有的DSP的指令集都包含有显式的MAC指令。另外,为了提高特定算法的实现效率,一些DSP处理器有专门的硬件来实现特殊的寻址模式,例如,模块(循环)寻址(对实现数字滤波器延时线很有用)、位倒序寻址(对FFT很有用)。这些特殊的寻址模式如果用软件来实现,则会大大降低系统的性能。

  为了提高每个指令周期内数据(与指令)的吞吐量,大多数DSP采用了改进的哈佛结构,并且使用了多个片内存储器和多组总线。此外,DSP处理器几乎都不具备数据高速缓存,这是因为DSP的典型数据是数据流。也就是说,DSP处理器对每个数据样本做计算后就丢弃了,几乎不再重复使用。另外,DSP算法中,通常大多数的处理时间是在执行较小的循环上,因此,大多数DSP设有专门的硬件用于零开销循环。所谓零开销循环是指处理器在执行循环时,不需要进行循环计数器的检查、条件跳转以及修改计数器值等操作,从而大大增强了DSP的性能。

  这些结构上的改进极大地提高了DSP在运算密集型应用中的处理能力。但随着新的算法与标准的不断出现,对处理器运算能力的要求仍在不断提高。为了达到实际应用的需要,处理器的架构仍然在不断的发展中。

2. 超标量、VLIW处理器架构

  高性能DSP在应用中取得了巨大成功,其成功的基础在于半导体工艺的不断进步使其性能不断提高,从而使其应用领域越来越广泛。但其在市场上真正的活力却是其可编程特性。只要到自己购买商品的厂商网站下载更新软件就能“免费”升级消费品,还有什么事情比这更让消费者满意呢?有了消费者的支持,企业当然能长盛不衰。

  因此,人们从来没有停止过更高性能处理器的架构研究。这其中就有多发射的超标量结构(Superscalar)和将若干指令组合在一起的超长指令字结构(VLIW),共同之处都是为了开发指令级并行性(ILP,Instruction Level Parallel)。从提高处理器性能的出发点来看,其思想的先进性不容置疑。但在2004年的消费电子领域,呼声更高的似乎是另一种架构:RISC(MCU)/DSP架构。典型的是ADI的Blackfin系列处理器,其重要特色就是在结构中充分体现对媒体应用(特别是视频)算法的支持,另外在售价、功耗方面也具有很大优势。笔者认为,这些正是超标量与VLIW架构的处理器所欠缺的。

三、H.264:新一轮媒体处理器架构革新

  目前,结合视频处理算法,多项有效技术被采用。

1. SIMD技术:数据可并行处理特性

  为提高通用DSP的媒体处理能力,各大DSP厂商都在原有架构基础上进行了媒体处理指令集扩展。其中,SIMD是被人们所熟知,也是最为成功的一项技术(图1)。现已几乎被所有面向媒体处理相关领域的处理器所采用。SIMD技术通常通过内核中内置多个运算单元以及相应的控制、数据通路来实现,反映给用户的是提供了支持SIMD操作的指令集。

  SIMD技术利用了视频算法:DCT/IDCT,ME/MC(运动估计、运动补偿)等算法模块中的可并行特性。

2. 数据预取技术:数据准备、运算写回并行操作

  在这里,我们把数据处理分如下三个步骤:(1)数据准备;(2)数据处理;(3)数据写回。

  事实上,在视频处理中,(1)和(3)有两层含义。第一层指的是片内、片外的数据读写操作。理想情况是尽量减少数据读写的时间(往往把这部分看成是额外开销)。从实践上看,可以通过DMA机制实现DSP数据处理和片内外数据调度的并行处理。第二层指如何取得SIMD处理中的各个子数据,例如图中(X3,X2,X1,X0)和(Y3,Y2,Y1,Y0)的获取以及操作(具体随OP不同而异)的并行处理。实际上,DSP(区别于单片机与RISC)中基于存储器的寻址方式就是一种节省数据存储器访问时间的有效技术。真正意义上的指令中操作数装载和并行运算的功能在Blackfin系列处理器中有了很好的体现。

  而上述两层含义的思想却是相同的,那就是数据处理和数据存取的并行处理(图2):处理当前数据的同时,把下次处理的数据预取(读)进来或把上次计算结果写回存储器。

  视频处理是一个以数据处理为主的系统,结合视频处理算法,实现指令操作数装载和并行运算将大大提高数据处理效率。

3. 基于可编程处理器的H.264实现策略

  H.264在复杂度上大大高于以往标准,这就要求处理器在架构上必须找到新的突破。笔者认为,以下两点将是基于可编程处理器的H.264算法实现的有效手段。

(1)针对H.264具体算法实现进一步进行指令扩展。

  在H.264中由于增加了很多以往标准所有没有的编码技术,例如整数变换(结合量化),去方块效应滤波器,以及精度更高的运动估计和补偿等等,这就要求在指令集上必须进行扩展。

  值得一提的是,在H.264中运动估计采用了多帧参考技术,这要求处理器设计人员对处理器的数据调度机制以及片内外存储器的组织等必须有新的考虑。

(2)双核、多核架构适配H.264编码器的可并行处理特性。

  在H.264当中,和以往标准一样可以进行基于图(picture)、片(slice)和宏块级的并行处理。而且,在H.264中采用RD算法进行模式选择,所有的模式在计算时都不存在相关性,即可以并行操作。因此,双核、多核架构在单核处理能力不够的情况下,也将被人们接受。随之而来的是软件工作难度(如编译器,操作系统任务调度等)将会大大增加。

  针对以上两点,值得一提的是ADI 的Blackfin系列处理器。该系列处理器中BF531/533/535均为单核架构,均进行SIMD指令集的扩展。而其中的并行指令(运算类指令和存储器操作指令可以并行执行)有力地提高了数据处理为主的视频编解码器系统的性能。目前该款处理器正向多核架构发展(如基于双核的BF561)以适应H.264如此高复杂度的算法的实现,这将是未来几年内提升处理器性能的一个有效途径,也将为高复杂度的H.264的实现奠定基础。而Blackfin系列处理器在功耗、成本等方面的指标也是其受到人们关注的一个原因。

四、MediaSOC3201A:一种非对称结构的双核系统芯片

  浙江大学信息与通信工程研究所SoC R&D小组自2004年4月研发成功国内首款具有自主知识产权的RISC/DSP混合体系结构处理器MediaDSP3200以来,于2004年底成功研制出基于双核的音视频SOC样片(MediaSOC3201A),如图3,其样片如图4。区别于BF561的对称架构(SMP),MediaSOC3201A是一种非对称结构(AMP),主要包括:媒体扩展CPU(运行操作系统,承担音频解码、系统控制以及部分视频解码任务),多功能处理器MediaDSP3201(数字信号处理、媒体处理指令扩展处理器:浙大数芯,负责视频处理等数据处理任务),多任务DMA(负责数据调度),各种同步、异步存储控制器,视频编码器(支持NTSC、PAL等制式),IIS音频播放以及GPIO等外设接口。

  目前,课题组正在研究基于MedisSOC3201A的H.264算法实现。算法、架构协同考虑是我们的目标。课题负责人刘鹏教授正满怀信心地带领整个研发团队为中国的集成电路、媒体系统芯片事业添砖加瓦。

■ 参考文献

1] 王维东,刘鹏,史册等.浙大数芯媒体处理器.中国多媒体视讯,2004(7):96~99

[2] Wiegand,Sullivan G.Study of Final Committee Draft of Joint Video Specification (ITU-T Rec. H.264 | ISO/IEC 14496-10 AVC),Draft2 .JVT- G050d2,Pattaya,Thailand,2003(3)

[3] Preliminary Technical Data:ADSP-BF5xx,http://www.analog.com

系统分类: 嵌入式  |  用户分类: h.264编解码  |  标签: 无标签  |  来源: 无分类  | 

点击查看原文

发表评论 阅读全文(825) | 回复(0)

发表于 2006/8/11 23:03:35

0

关于投票

H.264/AVC视频压缩编码标准的新进展

    本文作者郭晓强先生,国家广播电影电视总局广播科学研究院博士;解伟先生,北京邮电大学博士研究生。

    关键词:H.264/AVC FRExt  视频压缩编码标准

  H .264/AVC是由ISO/IEC与ITU-T组成的联合视频组(JVT)制定的新一代视频压缩编码标准,于2003年5月完成制订。相对于先前的标准,H.264/AVC无论在压缩效率、还是在网络适应性方面都有明显的提高,因此,业界普遍预测其将在未来的视频应用中替代现有的视频压缩标准。

  但是,H.264/AVC标准由于对视频源的限制,仅支持娱乐级视频质量。为了进一步扩大其应用范围,使其适应高保真视频压缩的应用,JVT于2004年7月对H.264/AVC做了重要的补充扩展,称为FRExt(Fidelity Range Extensions)。

FRExt概述

  H.264/AVC标准第一版支持的源图像为每象素8b,且采样方式仅限于4∶2∶0;而新近扩展的FRExt部分则扩大了标准的应用范围,如专业级的视频应用、高分辨率/高保真的视频压缩等。FRExt对H.264/AVC的改善主要在:(1)进一步引入一些先进的编码工具,提高了压缩效率;(2)视频源的每个样值均可超过8b,最高可达12b;(3)增加了4∶2∶2与4∶4∶4的采样格式;(4)更高的比特率,更高的图像分辨率;(5)可达到图像高保真的要求,支持无损压缩;(6)支持RGB格式的压缩,同时避免了色度空间转换的舍入误差。

高保真编码

  在高类中,H.264/AVC对FRExt定义了特别的编码方案——支持无损编码和多种颜色格式。

  (1)无损编码

  为满足视频信号高保真的要求,H.264/AVC只在H444P类中引入了无损压缩编码方案。第一个是PCM方案,它没有预测、变换和量化,直接传送取样点的值以达到无损编码的目的;第二个是无变换的无损编码方案,运用预测与熵编码技术来表示图像高效无损,相对于第一个方案提高了编码效率。

  (2)支持多种颜色格式

  RGB与YCbCr相互之间的颜色转换使用的都是浮点运算,这必将引入舍入误差。为了消除在浮点运算中引入的舍入误差,H.264/AVC在支持RGB的同时引入了新的彩色空间YCgCo:

  Y=1/2(G+(R+B)/2), Cg=1/2(G-(R+B)/2),Co=(R-B)/2

  上面的公式减小了色彩空间转换的复杂度;但是,为了避免舍入误差,要求增加额外的比特以保持精确性。为了把这个额外比特降到1b,使用下面的公式:

  Co=R-B,Cg=G-(B+(Co>>1)),Y=(B+(Co>>1))+Cg>>1)

压缩效率

  从压缩效率上讲,H.264/AVC已经大大超过了以往的视频压缩标准,加入了FRExt之后,其在大尺寸、高保真等视频压缩方面更具优势。图5示出H.264/AVC FRExt与MPEG-2在HDTV图像主观评价方面的一个比较,H.264/AVC在不同的码率下压缩,而MPEG-2的压缩码率是24Mb/s,由此图可见8Mb/s的H.264/AVC FRExt与MPEG-2相当。

图5 H.264/AVC FRExt 与MPEG-2的性能比较

图5 H.264/AVC FRExt 与MPEG-2的性能比较

  由于引入了基于空域的帧内预测技术,并且经过FRExt的改善,H.264/AVC的I帧与JPEG2000的编码效率相当,非常适合高质量的视频压缩应用。

小结

  新一代视频压缩编码标准H.264/AVC的新进展——FRExt,相对于第一版标准扩展了视频源的采样格式与比特深度,加入了一些提高编码效率的工具。从而H.264/AVC进一步提高了编码效率,扩大了应用范围。

  目前,高类已经代替主类而成为广播和其他娱乐应用的首选。主要原因是,它比起先前的主类只增加了极小的算法复杂度,却大大提高了压缩性能且编码器控制的灵活性。其中,H422P类可望在演播室环境中得以应用。在补充了FRExt之后,H.264/AVC被迅速推广到各种应用中,主要包括:欧洲数字视频广播标准DVB;美国先进电视系统委员会ATSC;DVD论坛的HD-DVD规范;蓝光光碟协会(BDA)的BD-ROM规范。

图1 FRExt 编码工具

图1 FRExt 编码工具

  FRExt增加了4个新的类:(1)High Profile(HP),支持8b、4∶2∶0采样;(2)High 10 Profile(Hi10P),支持10b、4∶2∶0采样;(3)High 4∶2∶2 Profile(H422P),支持10b、4∶2∶2采样;(4)High 4∶4∶4 Profile (H444P),支持12b、4∶4∶4采样、无损编码与多种色彩空间的编码。

  H.264/AVC FRExt详细说明了一组4个新的类,它们如同性能的嵌套子集一样被创立。这4个类全都继承了主类的工具集,就像它们的公共交集;而高类(HP)还额外地包含了所有能够提高编码效率的主要的新工具。相对于主类(MP),这些工具在算法复杂度上只是稍有提高。因此,在数字视频应用中,在4∶2∶0色度采样格式中使用8b视频的高类有可能代替主类。

  增加了高类之后,H.264/AVC各类的关系如图2所示,具体所包含的编码工具如下:

图2 H.264 各个类的关系

图2 H.264 各个类的关系

  1.所有类的共同部分:I片、P片、CAVLC;

  2.基本类(Baseline):FMO、ASO、冗余片;

  3.主类(Main):B片、加权预测、CABAC、隔行编码;

  4.扩展类(Extended):包含基本类的所有部分(FMO、ASO、冗余片)、SP片、SI片、数据分割、B片、加权预测;

  5.高类(High):包含主类的所有部分(B片、加权预测、CABAC、隔行编码)、自适应变换块尺寸(4×4或8×8整数变换)、量化矩阵。

FRExt增加的关键算法

  FRExt之所以能进一步提高编码效率及保真度,是因为加入了一些有效的编码工具。其中大部分是在取样点比特深度和色度格式方面;而在提高编码效率方面,主要是利用8×8的亮度帧内预测、4×4变换及8×8变换、量化矩阵等技术。

  9种8×8的亮度帧内预测

  H.264/AVC第一版的帧内预测包括9种4×4亮度块、4种16×16亮度块和4种色度块的预测。

图3 帧内预测方向

图3 帧内预测方向

    在FRExt中增加了9种8×8亮度块的预测,其预测方向(如图3)、预测块的计算与4×4块的基本一样,如图4所示。在一个给定的8×8亮度块中,每个象素值可从相邻的参考象素值(A~X、Z)中预测得到,编码器可选择8种不同的预测方向和直流预测。

  还有一点与4×4块的不同,就是要对预测值进行低通滤波,以提高预测的精确度。新的8×8帧内预测中,给出了一个简单的二阶低通滤波器,它在预测之前被用来重建亮度的参考象素值。经过滤波的参考象素按照9种模式的预测方法进行预测。

  8×8的整数变换

  H.264/AVC第一版中,对所有的残差块采用了4×4整数变换;对16×16亮度块进行帧内预测;整数变换后的16个DC系数采用4×4哈达玛变换,色度块的DC系数采用2×2哈达码变换。

  4×4整数变换除了算法复杂度低外,还可以有效地降低块效应。但是,对于大尺寸、高保真的视频,须要很好地保存图像的细节和纹理,这就需要更大尺寸的变换。为了达到各方面的平衡,FRExt引入了8×8整数变换,且编码器可以在宏块级自适应地选择4×4或8×8变换。在制定H.264/AVC标准之前,曾提出可变块尺寸的变换,其算法复杂度要低一些。

图4 用于8×8空间亮度预测的样本

图4 用于8×8空间亮度预测的样本

  8×8正变换和逆变换都可以通过快速蝶形算法实现,对于n比特的输入视频,只需要(8+n)比特的运算动态范围。8×8变换蝶形算法的复杂度只略高于4×4变换。

  新的变换同时要求相应的量化方法。FRExt在第一版的基础上做了扩展,与MPEG-2一样可以选择量化矩阵进行量化,而量化矩阵可以提高图像的主观质量。同时,CABAC也做了改进,增加了3个内容模型,而CAVLC把8×8的系数分为4组4×4的系数。

表1 FRExt中的二维8×8变换矩阵

表1 FRExt中的二维8×8变换矩阵

  须要指出的是,编码器可以对每一个宏块选择4×4或8×8变换,但变换尺寸的选择过程受到两种约束:(1)对于帧内预测,只有在采用8×8亮度块的预测时,选择8×8整数变换;(2)对于帧间预测,宏块中包含一个或多个小于8×8的块(4×8、8×4、4×4),必须采用4×4整数变换。

系统分类: 嵌入式  |  用户分类: h.264编解码  |  标签: 无标签  |  来源: 无分类  | 

点击查看原文

发表评论 阅读全文(1748) | 回复(0)

发表于 2006/8/10 22:55:38

5

关于投票

文件格式大全

图形文件(graphics)

  名称 大小 作者

描           述

  位图文件内部初探 14K   BMP、JPG等六种常用图形文件的结构(中文)
AI ai30.pdf 260K Adobe公司 Adobe Illustrator 3.0文件格式的英文说明书,Acrobat文档
BMP Graphics File Formats 47K   Windows的.BMP .CUR .ICO文件的格式,有范例
BMP Format 38K Wim Wouters Windows的.BMP文件格式
BW BW FILE FORMATS 3K   黑白图象.BW文件格式
COL COL Format 3K Max Maischein 调色板文件格式
DWG

DWG file format

12K Frans F. J. Faase AutoCAD DWG 文件格式说明(BFF 格式)
DXF Drawing Interchange and File Formats 87K Autodesk AutoCAD DXF 10.0版文件格式说明
Drawing Interchange and File Formats Release 12 141K Autodesk AutoCAD DXF 12.0版文件格式说明
dxf13.zip 143K Autodesk AutoCAD DXF 13.0版文件格式说明
Dxf_r14.hlp 202K Autodesk AutoCAD DXF 14.0版文件格式说明 (Windows Help格式)
dxf14htm.zip 161K Autodesk AutoCAD DXF 14.0版文件格式说明
EMF emf.hlp 74K Microsoft公司 Windows 32位扩展图元文件格式(HELP文档)
GIF GIF Graphics Interchange Format 30K CompuServe 公司 GIF87图象文件.GIF的格式
LZW and GIF explained-- Steve Blackstock 18K Steve Blackstock 解释LZW 和GIF
gif89a.doc 84K CompuServe 公司 GIF89图象文件英文说明文档(写字板文档)
ICO Ico.zip 115K Microsoft公司 图标文件(.ICO)文件格式详解(ZIP文档)
JPG jpg.rtf 16K Eric Hamilton .JPG图象文件格式英文技术文档(RTF文档)
jpg.pdf 94K Gregory K. Wallace .JPG图象文件的压缩标准(Acrobat文档)
MOV QuickTim.pdf 646K Apple公司 QuickTime动画文件格式(Acrobat文档)
PNG draft-bo.rtf 241K T. Boutell et al 网络图形格式说明
PCD

A brief description of the Kodak PCD-format

6K Alex Kwak Kodak PhotoCD 格式 (RTF文档)
PCX PCX File Format 24K Zsoft 公司 .PCX图象文件格式技术手册
PIC PIC Format 5K Max Maischein Autodesk动画文件PIC文件格式
PSD psd.pdf 369K Adobe 公司 Photoshop 4.0文件.PSD文件格式的英文说明书(Acrobat文档)
ps_plug.pdf 378K Adobe 公司 Adobe Photoshop 3 插件格式(Acrobat文档)
REL rle.pdf 32K Spencer W. Thomas RLE 格式说明 (Acrobat文档)
TGA

TGA FORMAT

46K David McDuffee Targa 图像文件格式说明
tga2.zip 55K Truevision公司 TGA 文件格式说明第二版(Acrobat PDF格式)
TIF tif.pdf 366K Aldus 公司 .TIF文件6.0格式英文说明书(Acrobat文档)
LZW LZW compression 7K Bob Montgomery 一个.GIF文件的常用压缩算法
YUV YUV4:1:1 4K Angus Dorbie YUV4:1:1文件格式
WMF .WMF Metafile Format 14K Microsoft公司 Windows95的.WMF文件格式

声音和影像文件(sound)

CD CD-ROM Technical Summary 27K Andy Poggio CD数据设计详解
CDA CDA music tracks file format 3K Wojtek Kaniewski CD音轨文件格式介绍
MID Standard MIDI File Format 17K Dustin Caldwell 标准的MIDI文件.MID文件格式
MIDI 1.0 Specification 8K Greg MIDI1.0格式文件英文说明书
General MIDI Level Spec 13K Jeff Mallory MIDI文件格式综述
MIDI SAMPLE DUMP STANDARD 11K   MIDI取样转存标准格式
MPEG mpeg.zip 574K   MPEG文件格式的说明和范例,有大量C语言程序代码(ZIP文档)
mpeg1.zip 66K Fraunhofer Institute MPEG-1文件格式的范例,C语言程序代码(ZIP文档)
WAV wav.rtf 31K Robert Shuler Windows声音文件.WAV文件格式(RTF文档)
WAVE File Format 105K Microsoft公司 Windows声音文件.WAV文件格式
New WAVE Types 215K Microsoft公司 WAVE文件格式及压缩方法

动画文件(animate)

3DS 3ds.rtf 77K Autodesk公司 3D Studio文件格式(RTF文档)
AVI avi.rtf 133K AVI动画文件格式(RTF文档)
aviwav.rtf 93K E. Fleischman AVI和WAV文件格式
CODE WAVE and AVI Codec Registries 85K E. Fleischman WAVE and AVI Codec 注册说明
FLC flc.rtf 56K   Animator Pro 文件格式说明(FLC, FLI, CEL, PIC, MSK, COL, PLY, TWO, OPT) (RTF文档)
FLI Flic Files Format description 11K Mike Haaland FLI 文件格式说明
FLT FLC, FLT Format 20K Max Maischein Autodesk Animator FLC/FLT 文件格式说明
GIF gif89a.doc 84K CompuServe 公司 GIF89动画图象文件说明文档(写字板文档)
MOV QuickTim.pdf 646K Apple公司 QuickTime动画文件格式(Acrobat文档)
MPEG MPEG Video 4K Wilson Woo MPEG Video文件部分信息
mpegfaq.rtf 94K Chad Fogg MPEG-2文件技术问答集
PIC PIC Format 5K Max Maischein Autodesk动画文件PIC文件格式
YUV YUV4:1:1 4K Angus Dorbie YUV4:1:1文件格式

压缩算法(compress)

ARC ARC PAK Format 5K Max Maischein ARC/PAK 文件格式说明
ARJ ARJ TECHNICAL INFORMATION 9K Robert Jung ARJ压缩文件英文技术文档
CAB cab.zip 44K Microsoft公司 .CAB文件格式及C语言源代码(ZIP文档)
TAR TAR Format 13K Max Maischein TAR Archive 文件格式说明
LZH
LZH Format 2K Max Maischein LZH Archive 文件格式说明
RAR RAR.rtf 15K Eugene Roshal RAR2.0版压缩文件格式
ZIP General Format of a ZIP file 47K PKWARE ZIP文件格式

二进制格式(binary)

AOUT Architecture Dependent File Format 70K HP公司 Unix环境下的a.out文件格式
BGI bgi.rtf 71K Gene Lee BGI驱动程序C源代码 (不全)
BFF A grammar for Binary File Formats 8K 有关二进制文件格式的解说
COM COM Format 2K Max Maischein COM 文件格式说明
EXE DOS EXE File Structure 3K Microsoft公司 DOS环境下的.EXE文件格式
EXE Format 6K Max Maischein DOS环境下的.EXE文件格式

EXE Format

5K Max Maischein Windows和OS/2 的可执行文件(.EXE)格式
Executable File Format 27K Microsoft公司 Windows环境下的.EXE文件格式
HEX Intel Hexadecimal Object File Format Specification 18K Intel公司 Inter十六进制目标文件格式
HLP OS/2 HELP Format 2K Max Maischein OS/2操作系统的帮助文件格式
HPJ Hpj.doc 72K Microsoft公司 帮助的工程文件(.HPJ)文件格式(.DOC文档)
INF

Windows95 INF files Format

3K Robert Rapp Windows95的.INF文件格式
 

LIB

libs.zip 5K Ian/TWT Library库结构
MS Library Format 6K Microsoft公司 Microsoft的库文件(.LIB)格式
Dictionary Hashing Algorithm 6K Microsoft公司 Microsoft库的字典所用的哈希算法
MAP Borland .MAP File Format 3K Brad Kimmel Borland公司的.MAP文件格式
OBJ objlib.rtf 111K   DOS环境的EXE/COM/SYS/OBJ/LIB文件信息(RTF文档)
ssobj.zip 54K Microsoft公司 目标文件OBJ文件的说明书(ZIP文档)
PAS bpreal.zip 6K Richard Biffl Borland Pascal 实数存储格式和C代码
PE pe1.zip 65K Bernd Luevelsmeyer PE执行文件(Win 95/NT/WIN32)格式说明和查看程序(RTF文档)
winf10.pdf 392K Intel公司 PE执行文件和 STI (微软符号和类型信息) (Acrobat文档)
REG The .REG file format 13K Jeroen Mostert Windows注册表文件(.REG)格式
Windows Registry Files 24K Windows注册信息文件user.dat、system.dat 、CONFIG.POL文件格式
RES Win32 Resource File Format 18K Marco Cocco Win32的资源文件格式

Windows格式(Windows)

ANI Windows95 Animated Cursor File Format 4K R. James Houghtaling Windows95的动画鼠标文件格式
BMP BMP Format 38K Wim Wouters BMP文件格式  
CAB cab.zip 44K Microsoft公司 .CAB文件格式及C语言源代码(ZIP文档)
CAL .CAL Calendar File Format 7K Microsoft公司 Windows31日历文件格式
CLP .CLP Clipboard File Format 3K Microsoft公司 Windows31剪贴板文件格式
CRD Cardfile File Format Microsoft公司 Windows31卡片文件格式
FIND Windows 95 Find File Format Edward Blake Windows95查找文件格式
GRP Group File Format Microsoft公司 Windows程序组文件格式
HLP Windows Help File Format 61K M. Winterhoff Windows帮助文件(.HLP)文件格式
HPJ Hpj.doc 72K Microsoft公司 帮助的工程文件(.HPJ)文件格式(.DOC文档)
 

ICO

Icons in Win32 35K Microsoft公司 Win32中的图标文件
Ico.zip 115K Microsoft公司 图标文件(.ICO)文件格式详解(ZIP文档)
INF

Windows95 INF files Format

3K Robert Rapp Windows95的.INF文件格式
LNK .LNK file format 7K Donald Murray Windows95的.LNK文件格式
REG The .REG file format 13K Jeroen Mostert Windows注册表文件(.REG)格式
Windows Registry Files 24K Windows注册信息文件user.dat、system.dat 、CONFIG.POL文件格式
RES Win32 Resource File Format 18K Marco Cocco Win32的资源文件格式
REL rle.pdf 32K Spencer W. Thomas RLE 格式说明 (Acrobat)
RTF

RTF文件结构分析及其应用

9K 邱立铭 王键 Windows的一种文本格式(中文)
SCR Windows .SCR screen savers 2K Paul Oliver Windows95的屏幕保护文件格式
TTF ttfspec1.zip 753K Microsoft公司 Windows字体文件(.TTF1.0)文件资料(ZIP文档)
ttfspec2.zip 502K Microsoft公司 Windows字体文件(.TTF)格式详解(ZIP文档)
WAV wav.rtf 31K Robert Shuler Windows声音文件.WAV文件格式(RTF文档)
WAVE File Format 105K Microsoft公司 Windows声音文件.WAV文件格式
New WAVE Types 215K Microsoft公司 WAVE文件格式及压缩方法
WRI Write File Format 24K Microsoft公司 Windows31的写字板文件格式
WMF .WMF Metafile Format 14K Microsoft公司 Windows95的.WMF文件格式
How does Windows 95 stores LONG FILENAMES? 4K Jozsef Hidasi 有关Windows95长文件名的文章

文本及字体文件(Text&Font)

Acorn Font File Format 10K Acorn字体格式介绍
EPS adobe_EPSF1_2.pdf 13K Adobe 公司 Encapsulated Postscript Version 1.2 (Acrobat)
adobe_EPSF2_0.pdf 43K Adobe 公司 Encapsulated Postscript Version 2.0 (Acrobat)
adobe_EPSF3_0.pdf 128K Adobe 公司 Encapsulated Postscript Version 3.0 (Acrobat)
FONT Font-File Format 20K Microsoft公司 Windows31字体文件格式
RTF rtf.zip 148K Microsoft公司 RTF文件格式说明书和范例(ZIP文档)
rtf.rtf 159K Microsoft公司 RTF文件格式说明书补充(RTF文档)
Wordper-
fect
Wordperfect File Format 4K Max Maischein Wordperfect文件格式部分叙述
WRI Write File Format 24K Microsoft公司 Windows31的写字板文件格式
WordStar WordStar File Format Release 7.0 57K WordStar7.0版本文件格式
WORD word60.rtf 464K Microsoft公司 WORD6.0文件格式,非常详细(RTF文档)
MS Word 97 Binary File Format 464K Microsoft公司 WORD 97(8.0)文件格式
TTF ttfspec1.zip 753K Microsoft公司 Windows字体文件(.TTF1.0)文件资料(ZIP文档)
ttfspec2.zip 502K Microsoft公司 Windows字体文件(.TTF)格式详解(ZIP文档)

Internet文件(Internet)

BBS bbs.htm 14K F.W. van Wensveen

Hudson message base 文件原代码(C语言代码)

VRML VRML2.hlp 182K

VRML2.0说明书(Help文档)

Vrml.rtf 71K Anthony Parisi VRML1.0详解(RTF文档)
URL The URL format 2K Edward Blake URL文件格式说明
IDX IDX Outlook Express (IE4) Index File Format 4K Edward Blake IE4.0的索引文件.IDX文件格式
AGENT agentref.zip 11K Ray Delio Agent新闻组程序数据格式
UUENCODE UUENCODE 12K Jim Cameron UU-encoded 格式说明
Bluewave Blue Wave Mail Packet File Structures 49K George Hatchew 蓝波快信的各种文件的格式说明

数据库文件(Database)

Clarion clarion.zip 33K Jerzy Tarasiuk Clarion文件格式,包括 .DAT/.K??/.I??/.MEM/.HLP/.APP文件(ZIP文档)
DBF DBASE FLIE FORMAT 7K multisoft Dbase数据库文件.DBF文件格式
DBF FILE STRUCTURE 4K Peter Mikalajunas .DBF文件格式,适用于 dBASE III/dBASE IV/Foxbase/Foxpro
NTX NTX file format 13K Cesar A. Gil Clipper NTX 文件格式说明
PARADOX paradox.rtf 62K Kevin Mitchell PARADOX4.0文件格式(RTF文档)
WKS wks.zip 22K Lotus公司 Lotus的 .WKS文件格式(ZIP文档)
XLS xls.txt 45K EXCEL文件格式(文本文档)

其他格式(Other)

INTEL Intel.rtf 131K   有关Intel8086/80186/80286/80386/80486指令的详细解说(RTF文档)
Epson escode.rtf 50K Epson公司 Epson 9针和24针打印机控制代码(RTF文档)
joystick joystick.rtf 15K   有关游戏操作杆编程的文章(RTF文档)
keyboard keyboard.rtf 15K   有关键盘编程的文章(RTF文档)
mouse mouse.rtf 16K   有关鼠标编程的文章(RTF文档)
HP pcl5.zip 93K HP公司 HP PCL5打印机控制 (RTF文档)
speaker speaker.rtf 17K   有关PC喇叭编程的文章(RTF文档)
VGA VGA Bios layout 32K   有关VGA BIOS编程的文章(RTF文档)


系统分类: 嵌入式  |  用户分类: h.264编解码  |  标签: 无标签  |  来源: 无分类  | 

点击查看原文

发表评论 阅读全文(16157) | 回复(7)

发表于 2006/8/10 22:49:33

0

关于投票

使用 8 位 YUV 格式的视频呈现

 

发布日期: 12/9/2004 | 更新日期: 12/9/2004

Gary Sullivan 和 Stephen Estrop

Microsoft Digital Media Division

适用于:

Microsoft® Windows®, Microsoft DirectShow®

摘要:本文讲述了在 Microsoft Windows 操作系统中呈现视频时推荐使用的 8 位 YUV 格式。本文讲述了可用于在 YUV 格式和 RGB 格式之间进行转换的技术,还提供了用于对 YUV 格式进行上采样的技术。本文适用于在 Windows 中使用 YUV 视频解码或呈现的所有人员。

*
本页内容
简介 简介
在 DirectShow 中标识 YUV 格式 在 DirectShow 中标识 YUV 格式
YUV 采样 YUV 采样
表面定义 表面定义
颜色空间和色度采样率转换 颜色空间和色度采样率转换
其他信息 其他信息

简介

在整个视频行业中,定义了很多 YUV 格式。本文讲述的是在 Microsoft® Windows® 操作系统中呈现视频时推荐使用的 8 位 YUV 格式。鼓励解码器供应商和显示供应商支持本文所讲述的格式。本文不对 YUV 颜色的其他用途(如静止摄影)进行描述。

本文讲述的格式全部使用每个像素位置 8 位的方式来编码 Y 频道(也称为灯光频道),并使用每样例 8 位的方式来编码每个 U 或 V 色度样例。但是,大多数 YUV 格式平均使用的每像素位数都少于 24 位,这是因为它们包含的 U 和 V 样例比 Y 样例要少。本文不讲述带有 10 位和 12 位 Y 频道的 YUV 格式。

在本文中,U 一词相当于 Cb,V 一词相当于 Cr。

本文包括以下主题:

在 DirectShow 中标识 YUV 格式 — 讲述了如何描述 Microsoft DirectShow® YUV 格式类型。

YUV 采样 — 讲述了一些最常用的 YUV 采样技术。

表面定义 — 讲述了推荐的 YUV 格式。

颜色空间和色度采样率转换 — 提供了一些在 YUV 和 RGB 格式之间进行转换的指南,以及在不同 YUV 格式之间进行转换的指南。

其他信息提供了其他信息。

 

在 DirectShow 中标识 YUV 格式

本文讲述的每种 YUV 格式都指定了一个 FOURCC 码。FOURCC 码是一个 32 位、不带正负号的整数,它是通过串联四个 ASCII 字符创建而成的。

有很多 C/C++ 宏可使得在源代码中声明 FOURCC 值变得更加简单。例如,MAKEFOURCC 宏是在 Mmsystem.h 中声明的,FCC 宏则是在 Aviriff.h 中声明的。请按照下列方式使用这些宏:

DWORD fccYUY2 = MAKEFOURCC('Y','U','Y','2');
DWORD fccYUY2 = FCC('YUY2');

只需通过调转字符的顺序,您还可以将 FOURCC 码直接声明为字符文本。例如:

DWORD fccYUY2 = '2YUY';  // Declares the FOURCC 'YUY2'

因为 Windows 操作系统使用的是 little-endian 体系结构,所以调转顺序是必需的。“Y”= 0x59,“U”= 0x55,“2”= 0x32,所以“2YUY”为 0x32595559。

在 DirectShow 中,格式是由一个主类型全局唯一标识符 (GUID) 和一个子类型 GUID 标识的。计算机视频格式的主类型总是 MEDIATYPE_Video。子类型则可以通过将 FOURCC 码与 GUID 进行映射的方式来构造,如下所示:

XXXXXXXX-0000-0010-8000-00AA00389B71 

其中 XXXXXXXX 为 FOURCC 码。因此,YUY2 的子类型 GUID 为:

32595559-0000-0010-8000-00AA00389B71 

很多这样的 GUID 都已经在头文件 Uuids.h 中进行了定义。例如,YUY2 子类型被定义为 MEDIASUBTYPE_YUY2。DirectShow 基类库还提供了一个帮助器类 FOURCCMap,该类可用于将 FOURCC 码转换为 GUID 值。FOURCCMap 构造函数采用 FOURCC 码作为输入参数。然后,您可以将 FOURCCMap 对象强制转换为相应的 GUID:

FOURCCMap fccMap(FCC('YUY2'));
GUID g1 = (GUID)fccMap;

// Equivalent:
GUID g2 = (GUID)FOURCCMap(FCC('YUY2'));
 

YUV 采样

YUV 的优点之一是,色度频道的采样率可比 Y 频道低,同时不会明显降低视觉质量。有一种表示法可用来描述 U 和 V 与 Y 的采样频率比例,这个表示法称为 A:B:C 表示法:

4:4:4 表示色度频道没有下采样。

4:2:2 表示 2:1 的水平下采样,没有垂直下采样。对于每两个 U 样例或 V 样例,每个扫描行都包含四个 Y 样例。

4:2:0 表示 2:1 的水平下采样,2:1 的垂直下采样。

4:1:1 表示 4:1 的水平下采样,没有垂直下采样。对于每个 U 样例或 V 样例,每个扫描行都包含四个 Y 样例。与其他格式相比,4:1:1 采样不太常用,本文不对其进行详细讨论。

图 1 显示了 4:4:4 图片中使用的采样网格。灯光样例用叉来表示,色度样例则用圈表示。


图 1. YUV 4:4:4 样例位置

4:2:2 采样的这种主要形式在 ITU-R Recommendation BT.601 中进行了定义。图 2 显示了此标准定义的采样网格。


图 2. YUV 4:2:2 样例位置

4:2:0 采样有两种常见的变化形式。其中一种形式用于 MPEG-2 视频,另一种形式用于 MPEG-1 以及 ITU-T recommendations H.261 和 H.263。图 3 显示了 MPEG-1 方案中使用的采样网格,图 4 显示了 MPEG-2 方案中使用的采样网格。


图 3. YUV 4:2:0 样例位置(MPEG-1 方案)


图 4. YUV 4:2:0 样例位置(MPEG-2 方案)

与 MPEG-1 方案相比,在 MPEG-2 方案与为 4:2:2 和 4:4:4 格式定义的采样网格之间进行转换更简单一些。因此,在 Windows 中首选 MPEG-2 方案,应该考虑将其作为 4:2:0 格式的默认转换方案。

表面定义

本节讲述推荐用于视频呈现的 8 位 YUV 格式。这些格式可以分为几个类别:

4:4:4 格式,每像素 32 位

4:2:2 格式,每像素 16 位

4:2:0 格式,每像素 16 位

4:2:0 格式,每像素 12 位

首先,您应该理解下列概念,这样才能理解接下来的内容:

表面原点。对于本文讲述的 YUV 格式,原点 (0,0) 总是位于表面的左上角。

跨距。表面的跨距,有时也称为间距,指的是表面的宽度,以字节数表示。对于一个表面原点位于左上角的表面来说,跨距总是正数。

对齐。表面的对齐是根据图形显示驱动程序的不同而定的。表面始终应该 DWORD 对齐,就是说,表面中的各个行肯定都是从 32 位 (DWORD) 边界开始的。对齐可以大于 32 位,但具体取决于硬件的需求。

打包格式与平面格式。YUV 格式可以分为打包 格式和平面 格式。在打包格式中,Y、U 和 V 组件存储在一个数组中。像素被组织到了一些巨像素组中,巨像素组的布局取决于格式。在平面格式中,Y、U 和 V 组件作为三个单独的平面进行存储。

4:4:4 格式,每像素 32 位

推荐一个 4:4:4 格式,FOURCC 码为 AYUV。这是一个打包格式,其中每个像素都被编码为四个连续字节,其组织顺序如下所示。


图 5. AYUV 内存布局

标记了 A 的字节包含 alpha 的值。

4:2:2 格式,每像素 16 位

支持两个 4:2:2 格式,FOURCC 码如下:

YUY2

UYVY

两个都是打包格式,其中每个巨像素都是编码为四个连续字节的两个像素。这样会使得色度水平下采样乘以系数 2。

YUY2

在 YUY2 格式中,数据可被视为一个不带正负号的 char 值组成的数组,其中第一个字节包含第一个 Y 样例,第二个字节包含第一个 U (Cb) 样例,第三个字节包含第二个 Y 样例,第四个字节包含第一个 V (Cr) 样例,如图 6 所示。


图 6. YUY2 内存布局

如果该图像被看作由两个 little-endian WORD 值组成的数组,则第一个 WORD 在最低有效位 (LSB) 中包含 Y0,在最高有效位 (MSB) 中包含 U。第二个 WORD 在 LSB 中包含 Y1,在 MSB 中包含 V。

YUY2 是用于 Microsoft DirectX® Video Acceleration (DirectX VA) 的首选 4:2:2 像素格式。预期它会成为支持 4:2:2 视频的 DirectX VA 加速器的中期要求。

UYVY

此格式与 YUY2 相同,只是字节顺序是与之相反的 — 就是说,色度字节和灯光字节是翻转的(图 7)。如果该图像被看作由两个 little-endian WORD 值组成的数组,则第一个 WORD 在 LSB 中包含 U,在 MSB 中包含 Y0,第二个 WORD 在 LSB 中包含 V,在 MSB 中包含 Y1。


图 7. UYVY 内存布局

4:2:0 格式,每像素 16 位

推荐两个 4:2:0 每像素 16 位格式,FOURCC 码如下:

IMC1

IMC3

两个 FOURCC 码都是平面格式。色度频道在水平方向和垂直方向上都要以系数 2 来进行再次采样。

IMC1

所有 Y 样例都会作为不带正负号的 char 值组成的数组首先显示在内存中。后面跟着所有 V (Cr) 样例,然后是所有 U (Cb) 样例。V 和 U 平面与 Y 平面具有相同的跨距,从而生成如图 8 所示的内存的未使用区域。


图 8. IMC1 内存布局

IMC3

此格式与 IMC1 相同,只是 U 和 V 平面进行了交换:


图 9. IMC3 内存布局

4:2:0 格式,每像素 12 位

推荐四个 4:2:0 每像素 12 位格式,FOURCC 码如下:

IMC2

IMC4

YV12

NV12

在所有这些格式中,色度频道在水平方向和垂直方向上都要以系数 2 来进行再次采样。

IMC2

此格式与 IMC1 相同,只是 V (Cr) 和 U (Cb) 行在半跨距边界处进行了交错。换句话说,就是色度区域中的每个完整跨距行都以一行 V 样例开始,然后是一行在下一个半跨距边界处开始的 U 样例(图 10)。此布局与 IMC1 相比,能够更加高效地利用地址空间。它的色度地址空间缩小了一半,因此整体地址空间缩小了 25%。在各个 4:2:0 格式中,IMC2 是第二首选格式,排在 NV12 之后。


图 10. IMC2 内存布局

IMC4

此格式与 IMC2 相同,只是 U (Cb) 和 V (Cr) 行进行了交换:


图 11. IMC4 内存布局

YV12

所有 Y 样例都会作为不带正负号的 char 值组成的数组首先显示在内存中。此数组后面紧接着所有 V (Cr) 样例。V 平面的跨距为 Y 平面跨距的一半,V 平面包含的行为 Y 平面包含行的一半。V 平面后面紧接着所有 U (Cb) 样例,它的跨距和行数与 V 平面相同(图 12)。


图 12. YV12 内存布局

NV12

所有 Y 样例都会作为由不带正负号的 char 值组成的数组首先显示在内存中,并且行数为偶数。Y 平面后面紧接着一个由不带正负号的 char 值组成的数组,其中包含了打包的 U (Cb) 和 V (Cr) 样例,如图 13 所示。当组合的 U-V 数组被视为一个由 little-endian WORD 值组成的数组时,LSB 包含 U 值,MSB 包含 V 值。NV12 是用于 DirectX VA 的首选 4:2:0 像素格式。预期它会成为支持 4:2:0 视频的 DirectX VA 加速器的中期要求。


图 13. NV12 内存布局

 

颜色空间和色度采样率转换

本节提供了在 YUV 和 RGB 之间进行转换的指南,以及在某些不同 YUV 格式之间进行转换的指南。在本节中,我们会以两个 RGB 编码方案为例:8 位计算机 RGB 和 studio 视频 RGB,前者也称为 sRGB 或“全范围”RGB,后者也称为“带有头空间和脚空间的 RGB”。这两个方案的定义如下:

计算机 RGB 对于每个红色、绿色和蓝色样例都使用 8 位。黑色表示为 R = G = B = 0,白色则表示为 R = G = B = 255。

Studio 视频 RGB 对于每个红色、绿色和蓝色样例使用一定的位数,即 N 位,其中 N 为 8 或更大的数字。Studio 视频 RGB 使用的缩放系数与计算机 RGB 使用的缩放系数不同,它具有一个偏移量。黑色表示为 R = G = B = 16*2N-8,白色则表示为 R = G = B = 235*2N-8。但是,实际的值可能不在此范围之内。

Studio 视频 RGB 是 Windows 中视频的首选 RGB 定义,而计算机 RGB 则是非视频应用的首选 RGB 定义。在这两种形式的 RGB 中,色度座标都与在 RGB 原色定义的 ITU-R BT.709 中指定的一样。R、G 和 B 的 (x,y) 座标分别为 (0.64, 0.33)、(0.30, 0.60) 和 (0.15, 0.06)。基准白色为 D65,座标为 (0.3127, 0.3290)。标称灰度系数为 1/0.45(大约为 2.2),精确的灰度系数在 ITU-R BT.709 中进行了详细定义。

RGB 和 4:4:4 YUV 之间的转换

我们首先讲述 RGB 和 4:4:4 YUV 之间的转换。要将 4:2:0 或 4:2:2 YUV 转换为 RGB,我们建议首先将 YUV 数据转换为 4:4:4 YUV,然后再将 4:4:4 YUV 转换为 RGB。AYUV 格式是一个 4:4:4 格式,它对于每个 Y、U 和 V 样例都使用 8 位。对于某些应用,还可以使用每样例多于 8 位的位数定义 YUV。

对于数字视频,定义了从 RGB 到两个主要 YUV 的转换。这两个转换都基于称为 ITU-R Recommendation BT.709 的规范。第一个转换是 BT.709 中定义用于 50-Hz 的较早的 YUV 格式。它与在 ITU-R Recommendation BT.601 中指定的关系相同, ITU-R Recommendation BT.601 也被称为它的旧名称 CCIR 601。这种格式应该被视为用于标准定义 TV 分辨率 (720 x 576) 和更低分辨率视频的首选 YUV 格式。它的特征由下面两个常量 Kr 和 Kb 的值来定义:

Kr = 0.299
Kb = 0.114

第二个转换为 BT.709 中定义用于 60-Hz 的较新 YUV 格式,应该被视为用于高于 SDTV 的视频分辨率的首选格式。它的特征由下面两个不同的常量值来定义:

Kr = 0.2126
Kb = 0.0722

从 RGB 到 YUV 转换的定义以下列内容开始:

L = Kr * R + Kb * B + (1 – Kr – Kb) * G

然后,按照下列方式获得 YUV 值:

Y =                 floor(2^(M-8) * (219*(L–Z)/S + 16) + 0.5)
U = clip3(0, 2^M-1, floor(2^(M-8) * (112*(B-L) / ((1-Kb)*S) + 128) + 0.5))
V = clip3(0, 2^M-1, floor(2^(M-8) * (112*(R-L) / ((1-Kr)*S) + 128) + 0.5))

其中

M 为每个 YUV 样例的位数 (M >= 8)。

Z 为黑电平变量。对于计算机 RGB,Z 等于 0。对于 studio 视频 RGB,Z 等于 16*2N-8,其中 N 为每个 RGB 样例的位数 (N >= 8)。

S 为缩放变量。对于计算机 RGB,S 等于 255。对于 studio 视频 RGB,S 等于 219*2N-8

函数 floor(x) 返回大于或等于 x 的最大整数。函数 clip3(x, y, z) 的定义如下所示:

clip3(x, y, z) = ((z < x) ? x : ((z > y) ? y : z))

Y 样例表示亮度,U 和 V 样例分别表示偏向蓝色和红色的颜色偏差。Y 的标称范围为 16*2M-8 到 235*2M-8。黑色表示为 16*2M-8,白色表示为 235*2M-8。U 和 V 的标称范围为 16*2M-8 到 240*2M-8,值 128*2M-8 表示中性色度。但是,实际的值可能不在这些范围之内。

对于 studio 视频 RGB 形式的输入数据,要使得 U 和 V 值保持在 0 到 2M-1 范围之内,必需进行剪辑操作。如果输入为计算机 RGB,则不需要剪辑操作,这是因为转换公式不会生成超出此范围的值。

这些都是精确的公式,没有近似值。本文后面的所有内容均派生自这些公式。

示例:将 RGB888 转换为 YUV 4:4:4

示例:将 8 位 YUV 转换为 RGB888

将 4:2:0 YUV 转换为 4:2:2 YUV

将 4:2:2 YUV 转换为 4:4:4 YUV

将 4:2:0 YUV 转换为 4:4:4 YUV

示例:将 RGB888 转换为 YUV 4:4:4

在输入为计算机 RGB,输出为 8 位 BT.601 YUV 的情况下,我们相信前面一节中给出的公式可以按照下列公式进行合理近似计算:

Y = ( (  66 * R + 129 * G +  25 * B + 128) >> 8) +  16
U = ( ( -38 * R -  74 * G + 112 * B + 128) >> 8) + 128
V = ( ( 112 * R -  94 * G -  18 * B + 128) >> 8) + 128

这些公式使用精确度不大于 8 位(不带正负号)的系数计算出 8 位结果。中间结果需要最多 16 位的精确度。

示例:将 8 位 YUV 转换为 RGB888

从原始的 RGB 到 YUV 公式,您可以为 YUV 的 8 位 BT.601 定义派生出下列关系:

Y = round( 0.256788 * R + 0.504129 * G + 0.097906 * B) +  16 
U = round(-0.148223 * R - 0.290993 * G + 0.439216 * B) + 128
V = round( 0.439216 * R - 0.367788 * G - 0.071427 * B) + 128

因此,假设:

C = Y - 16
D = U - 128
E = V - 128

将 YUV 转换为计算机 RGB 的公式可以按照下列方式进行派生:

R = clip( round( 1.164383 * C                   + 1.596027 * E  ) )
G = clip( round( 1.164383 * C - (0.391762 * D) - (0.812968 * E) ) )
B = clip( round( 1.164383 * C +  2.017232 * D                   ) )

其中 clip() 表示剪辑为范围 [0..255]。这些公式可以由下列公式进行合理近似计算:

R = clip(( 298 * C           + 409 * E + 128) >> 8)
G = clip(( 298 * C - 100 * D - 208 * E + 128) >> 8)
B = clip(( 298 * C + 516 * D           + 128) >> 8)

这些公式使用精确度必需大于 8 位的一些系数计算出每个 8 位结果,中间结果需要多于 16 位的精确度。

4:2:0 YUV 转换为 4:2:2 YUV

将 4:2:0 YUV 转换为 4:2:2 YUV 需要系数为 2 的垂直上转换。本节讲述了一个执行上转换的方法示例。该方法假设视频图片为逐行扫描。

4:2:0 到 4:2:2 隔行扫描转换过程会出现不常见的问题,难以实现。本文不会对转换从 4:2:0 到 4:2:2 的隔行扫描时出现的问题进行解决。

让输入色度样例的每个垂直行都成为一个数组 Cin[],其范围为从 0 到 N - 1。输出图像上相应的垂直行则会成为数组 Cout[],其范围为从 0 到 2N - 1。要转换每个垂直行,请执行下列过程:

Cout[0]     = Cin[0];
Cout[1]     = clip((9 * (Cin[0] + Cin[1]) – (Cin[0] + Cin[2]) + 8) >> 4);
Cout[2]     = Cin[1];
Cout[3]     = clip((9 * (Cin[1] + Cin[2]) - (Cin[0] + Cin[3]) + 8) >> 4);
Cout[4]     = Cin[2]
Cout[5]     = clip((9 * (Cin[2] + Cin[3]) - (Cin[1] + Cin[4]) + 8) >> 4);
...
Cout[2*i]   = Cin[i]
Cout[2*i+1] = clip((9 * (Cin[i] + Cin[i+1]) - (Cin[i-1] + Cin[i+2]) + 8) >> 4);
...
Cout[2*N-3] = clip((9 * (Cin[N-2] + Cin[N-1]) - (Cin[N-3] + Cin[N-1]) + 8) >> 4);
Cout[2*N-2] = Cin[N-1];
Cout[2*N-1] = clip((9 * (Cin[N-1] + Cin[N-1]) - (Cin[N-2] + Cin[N-1]) + 8) >> 4);

其中 clip() 表示剪辑范围为 [0..255]。

用于处理边缘的等式在计算上可以进行简化。这些等式以这种形式显示,是为了说明图片边缘的附着效果。

实际上,这种方法会通过在四个相邻像素上插入曲线,并趋向两个最近的像素值进行加权,来计算每个缺少的值(图 14)。此示例中使用的这个特定插入方法使用一个众所周知的方法来计算半整数位置缺少的样例,这个方法称为 Catmull-Rom 插入,也称为立方回旋插入。


图 14. 4:2:0 到 4:2:2 上采样

对于信号处理过程,理想情况下,垂直上转换应该包括一个相移补偿,以将 4:2:0 样例行位置和每隔一个 4:2:2 样例行位置之间的半像素垂直偏移量(与输出 4:2:2 采样网格相比较)考虑在内。但是,引入此偏移量会提高生成样例所需的处理量,并且会导致无法从上采样 4:2:2 图像重新构造原始的 4:2:0 样例。引入此偏移量还会导致无法将视频直接解码到 4:2:2 表面,也就无法将这些表面用作解码流中后续图片的参考图片。因此,此处提供的这种方法不会考虑样例的精确垂直对齐。这样做在合理的高图片分辨率下可能不会影响视觉效果。

如果您首先从一个 4:2:0 视频开始,并且该视频使用在 H.261、H.263 和 MPEG-1 视频中定义的采样网格,输出 4:2:2 色度样例的相也会相对于灯光采样网格间隔而产生半个像素的水平 偏移量(相对于 4:2:2 色度采样网格间隔则为四分之一像素偏移量)。但是,4:2:0 视频的 MPEG-2 形式在 PC 上可能更经常使用,不会出现上述问题。而且,这种偏差在合理的高图片分辨率下可能不会影响视觉效果。尝试更正此问题会产生与垂直相偏移相同种类的问题。

4:2:2 YUV 转换为 4:4:4 YUV

将 4:2:2 YUV 转换为 4:4:4 YUV 需要系数为 2 的水平上转换。前面讲述的用于垂直上转换的方法也适用于水平上转换。对于 MPEG-2 和 ITU-R BT.601 视频,此方法会生成带有正确相对齐的样例。

4:2:0 YUV 转换为 4:4:4 YUV

要将 4:2:0 YUV 转换为 4:4:4 YUV,按照前面讲述的两个方法进行操作即可。首先将 4:2:0 图像转换为 4:2:2,然后将 4:2:2 图像转换为 4:4:4。您还可以切换两个上转换过程的顺序,因为操作顺序对于结果的视觉质量不会产生真正的影响。

系统分类: 嵌入式  |  用户分类: h.264编解码  |  标签: 无标签  |  来源: 无分类  | 

点击查看原文

发表评论 阅读全文(1880) | 回复(0)

发表于 2006/8/10 22:45:00

0

关于投票

RGB与YUV

RGBYUV----摘自《DirectShow实务精选》 作者:陆其明

 

计算机彩色显示器显示色彩的原理与彩色电视机一样,都是采用RRed)、GGreen)、BBlue)相加混色的原理:通过发射出三种不同强度的电子束,使屏幕内侧覆盖的红、绿、蓝磷光材料发光而产生色彩。这种色彩的表示方法称为RGB色彩空间表示(它也是多媒体计算机技术中用得最多的一种色彩空间表示方法)。

根据三基色原理,任意一种色光F都可以用不同分量的RGB三色相加混合而成。

 

F = r [ R ] + g [ G ] + b [ B ]

 

其中,rgb分别为三基色参与混合的系数。当三基色分量都为0(最弱)时混合为黑色光;而当三基色分量都为k(最强)时混合为白色光。调整rgb三个系数的值,可以混合出介于黑色光和白色光之间的各种各样的色光。

那么YUV又从何而来呢?在现代彩色电视系统中,通常采用三管彩色摄像机或彩色CCD摄像机进行摄像,然后把摄得的彩色图像信号经分色、分别放大校正后得到RGB,再经过矩阵变换电路得到亮度信号Y和两个色差信号RY(即U)、BY(即V),最后发送端将亮度和色差三个信号分别进行编码,用同一信道发送出去。这种色彩的表示方法就是所谓的YUV色彩空间表示。

采用YUV色彩空间的重要性是它的亮度信号Y和色度信号UV是分离的。如果只有Y信号分量而没有UV分量,那么这样表示的图像就是黑白灰度图像。彩色电视采用YUV空间正是为了用亮度信号Y解决彩色电视机与黑白电视机的兼容问题,使黑白电视机也能接收彩色电视信号。

YUVRGB相互转换的公式如下(RGB取值范围均为0-255):

 

Y = 0.299R + 0.587G + 0.114B

U = -0.147R - 0.289G + 0.436B

V = 0.615R - 0.515G - 0.100B

 

R = Y + 1.14V

G = Y - 0.39U - 0.58V

B = Y + 2.03U

 

DirectShow中,常见的RGB格式有RGB1RGB4RGB8RGB565RGB555RGB24RGB32ARGB32等;常见的YUV格式有YUY2YUYVYVYUUYVYAYUVY41PY411Y211IF09IYUVYV12YVU9YUV411YUV420等。作为视频媒体类型的辅助说明类型(Subtype),它们对应的GUID见表2.3

 

2.3 常见的RGBYUV格式

 

GUID

格式描述

MEDIASUBTYPE_RGB1

2色,每个像素用1位表示,需要调色板

MEDIASUBTYPE_RGB4

16色,每个像素用4位表示,需要调色板

MEDIASUBTYPE_RGB8

256色,每个像素用8位表示,需要调色板

MEDIASUBTYPE_RGB565

每个像素用16位表示,RGB分量分别使用5位、6位、5

MEDIASUBTYPE_RGB555

每个像素用16位表示,RGB分量都使用5位(剩下的1位不用)

MEDIASUBTYPE_RGB24

每个像素用24位表示,RGB分量各使用8

MEDIASUBTYPE_RGB32

每个像素用32位表示,RGB分量各使用8位(剩下的8位不用)

MEDIASUBTYPE_ARGB32

每个像素用32位表示,RGB分量各使用8位(剩下的8位用于表示Alpha通道值)

MEDIASUBTYPE_YUY2

YUY2格式,以4:2:2方式打包

MEDIASUBTYPE_YUYV

YUYV格式(实际格式与YUY2相同)

MEDIASUBTYPE_YVYU

YVYU格式,以4:2:2方式打包

MEDIASUBTYPE_UYVY

UYVY格式,以4:2:2方式打包

MEDIASUBTYPE_AYUV

Alpha通道的4:4:4 YUV格式

MEDIASUBTYPE_Y41P

Y41P格式,以4:1:1方式打包

MEDIASUBTYPE_Y411

Y411格式(实际格式与Y41P相同)

MEDIASUBTYPE_Y211

Y211格式

MEDIASUBTYPE_IF09

IF09格式

MEDIASUBTYPE_IYUV

IYUV格式

MEDIASUBTYPE_YV12

YV12格式

MEDIASUBTYPE_YVU9

YVU9格式

 

下面分别介绍各种RGB格式。

 

¨ RGB1RGB4RGB8都是调色板类型的RGB格式,在描述这些媒体类型的格式细节时,通常会在

BITMAPINFOHEADER数据结构后面跟着一个调色板(定义一系列颜色)。它们的图像数据并不是真正

的颜色值,而是当前像素颜色值在调色板中的索引。以RGB12色位图)为例,比如它的调色板中

定义的两种颜色值依次为0x000000(黑色)和0xFFFFFF(白色),那么图像数据001101010111…

(每个像素用1位表示)表示对应各像素的颜色为:黑黑白白黑白黑白黑白白白

 

¨ RGB565使用16位表示一个像素,这16位中的5位用于R6位用于G5位用于B。程序中通常使用一

个字(WORD,一个字等于两个字节)来操作一个像素。当读出一个像素后,这个字的各个位意义如

下:

     高字节              低字节

R R R R R G G G     G G G B B B B B
可以组合使用屏蔽字和移位操作来得到RGB各分量的值:
 
#define RGB565_MASK_RED    0xF800
#define RGB565_MASK_GREEN  0x07E0
#define RGB565_MASK_BLUE   0x001F
R = (wPixel & RGB565_MASK_RED) >> 11;   // 取值范围0-31
G = (wPixel & RGB565_MASK_GREEN) >> 5;  // 取值范围0-63
B =  wPixel & RGB565_MASK_BLUE;         // 取值范围0-31
 

¨ RGB555是另一种16位的RGB格式,RGB分量都用5位表示(剩下的1位不用)。使用一个字读出一个

像素后,这个字的各个位意义如下:

     高字节             低字节

X R R R R G G       G G G B B B B B       X表示不用,可以忽略)

可以组合使用屏蔽字和移位操作来得到RGB各分量的值:
 
#define RGB555_MASK_RED    0x7C00
#define RGB555_MASK_GREEN  0x03E0
#define RGB555_MASK_BLUE   0x001F
R = (wPixel & RGB555_MASK_RED) >> 10;   // 取值范围0-31
G = (wPixel & RGB555_MASK_GREEN) >> 5;  // 取值范围0-31
B =  wPixel & RGB555_MASK_BLUE;         // 取值范围0-31
 
¨ RGB24使用24位来表示一个像素,RGB分量都用8位表示,取值范围为0-255。注意在内存中RGB各分
量的排列顺序为:BGR BGR BGR…。通常可以使用RGBTRIPLE数据结构来操作一个像素,它的定义
为:
 
typedef struct tagRGBTRIPLE { 
  BYTE rgbtBlue;    // 蓝色分量
  BYTE rgbtGreen;   // 绿色分量
  BYTE rgbtRed;     // 红色分量
} RGBTRIPLE;
 
¨ RGB32使用32位来表示一个像素,RGB分量各用去8位,剩下的8位用作Alpha通道或者不用。(ARGB32
就是带Alpha通道的RGB32。)注意在内存中RGB各分量的排列顺序为:BGRA BGRA BGRA…。通常可以
使用RGBQUAD数据结构来操作一个像素,它的定义为:
 
typedef struct tagRGBQUAD {
  BYTE    rgbBlue;      // 蓝色分量
  BYTE    rgbGreen;     // 绿色分量
  BYTE    rgbRed;       // 红色分量
  BYTE    rgbReserved;  // 保留字节(用作Alpha通道或忽略)
} RGBQUAD;
 
下面介绍各种YUV格式。YUV格式通常有两大类:打包(packed)格式和平面(planar)格式。前者
YUV分量存放在同一个数组中,通常是几个相邻的像素组成一个宏像素(macro-pixel);而后者
使用三个数组分开存放YUV三个分量,就像是一个三维平面一样。表2.3中的YUY2Y211都是打包格式,
IF09YVU9都是平面格式。(注意:在介绍各种具体格式时,YUV各分量都会带有下标,如Y0U0V0
表示第一个像素的YUV分量,Y1U1V1表示第二个像素的YUV分量,以此类推。)
 
¨ YUY2(和YUYV)格式为每个像素保留Y分量,而UV分量在水平方向上每两个像素采样一次。一个
宏像素为4个字节,实际表示2个像素。(4:2:2的意思为一个宏像素中有4Y分量、2U分量和2
V分量。)图像数据中YUV分量排列顺序如下:
Y0 U0 Y1 V0    Y2 U2 Y3 V2 …
 
¨ YVYU格式跟YUY2类似,只是图像数据中YUV分量的排列顺序有所不同:
Y0 V0 Y1 U0    Y2 V2 Y3 U2 …
 
¨ UYVY格式跟YUY2类似,只是图像数据中YUV分量的排列顺序有所不同:
U0 Y0 V0 Y1    U2 Y2 V2 Y3 …
 
¨ AYUV格式带有一个Alpha通道,并且为每个像素都提取YUV分量,图像数据格式如下:
A0 Y0 U0 V0    A1 Y1 U1 V1 …
 
¨ Y41P(和Y411)格式为每个像素保留Y分量,而UV分量在水平方向上每4个像素采样一次。一个
宏像素为12个字节,实际表示8个像素。图像数据中YUV分量排列顺序如下:
U0 Y0 V0 Y1    U4 Y2 V4 Y3    Y4 Y5 Y6 Y8 … 
 
¨ Y211格式在水平方向上Y分量每2个像素采样一次,而UV分量每4个像素采样一次。一个宏像素为
4个字节,实际表示4个像素。图像数据中YUV分量排列顺序如下:
Y0 U0 Y2 V0    Y4 U4 Y6 V4 …
 
¨ YVU9格式为每个像素都提取Y分量,而在UV分量的提取时,首先将图像分成若干个4 x 4的宏块,
然后每个宏块提取一个U分量和一个V分量。图像数据存储时,首先是整幅图像的Y分量数组,然后
就跟着U分量数组,以及V分量数组。IF09格式与YVU9类似。
 
¨ IYUV格式为每个像素都提取Y分量,而在UV分量的提取时,首先将图像分成若干个2 x 2的宏块,
然后每个宏块提取一个U分量和一个V分量。YV12格式与IYUV类似。
 
¨ YUV411YUV420格式多见于DV数据中,前者用于NTSC制,后者用于PAL制。YUV411为每个像素都
提取Y分量,而UV分量在水平方向上每4个像素采样一次。YUV420并非V分量采样为0,而是跟YUV411
相比,在水平方向上提高一倍色差采样频率,在垂直方向上以U/V间隔的方式减小一半色差采样,
如图2.12所示。 
    

2.12 YUV411YUV420的采样格式

系统分类: 嵌入式  |  用户分类: h.264编解码  |  标签: 无标签  |  来源: 无分类  | 

点击查看原文

发表评论 阅读全文(1795) | 回复(0)

发表于 2006/8/10 20:13:19

0

关于投票

高清视频

在90年代中VCD概念尚未被大多数人获知的时候,市场上已经有Sigma Design公司推出的VCD加速卡。当时的显示卡顶多就是集成了一个二维图形用户界面加速器再加上一个帧缓存控制器,缺乏视频加速功能,因此在电脑上观赏视频节目普遍依赖于CPU。

  然而在90年代中期的x86 CPU时钟频率最高也就是133MHz左右,缺乏多媒体指令集扩展,即使是应付今天看来画面细小的VCD(基于MPEG-1编码),依然是力不从心,这也就是当时市场上出现的VCD加速卡原因。

  到了DVD推出的时候,由于CPU指令集的扩展和频率提升,再加上不少显示卡已经具备硬件Overlay、运动补偿、色彩转换等功能,在电脑上播放分辨率比VCD高一倍的DVD已经不再需要外加独立的DVD加速卡了(当然市场上也有这样的产品销售,但是基本上是乏人问津而且就算购买也只是看重其视频输出能力,后来这样的功能也都被集成到显示卡上了)。

  到了2004年,由于日本、韩国、美国等发达国家的高清晰广播开始普及,一些电影发行商业推出了高清晰视频的DVD影碟,人们一下子发现,原来津津乐道了5、6年的标准分辨率(即720*576)DVD影片在高清晰影片面前显得多么的粗糙。

高清晰视频与H.264简介

  对什么是高清晰视频(HD视频)目前虽然缺乏严格的定义,但是根据比较流行的看法,主要是指分辨率达到ATSC定义的1920*1080、1280*720以及摄像机方面比较流行的1440*1080,前两者的屏幕长高比例均为16:9,后者则是4:3。

  除了分辨率外,HD视频还有帧速率、扫描方式(交错/非交错)、色彩深度等方面的不同参数。

  例如1280X720必须是逐行或者说非交错的,简称720p;1920x1080有逐行和交错两种模式。

  帧速率一般有每秒24、25、30或者60帧,NTSC提供了低于这些速率0.1%的变量,因此对于NTSC系统也有可能采用29.97fps(由30000/1001换算而来)、23.976fps(24000/1001)、59.94(60000/1001)。

  对于高端的摄编录系统,可能会采用非压缩或者低压缩的4:4:4 12位色深精度格式或者是4:2:2 10位色彩精度格式,而消费类的产品(例如家用/桌面播放器)大都采用4:2:0或者是4:1:1的8位压缩格式。

  由于采用了标清DVD 4倍的高分辨率,HD视频能提供前所未有细致入微的画面,但是随之而来的问题也相当突出,那就是视频中包含的信息量也随之增加到标清节目的4倍甚至更高。如果完全基于目前的恒码率MPEG2技术,1080p电影的码率起码要23Mbps以上,两个小时需要的空间不下20GB。这里带来了两个问题:存储空间以及网络传输带宽需求。

  DVD碟的下一代——蓝光碟(Blue-Ray Disc)能提供至少23GB的空间,而未来两年的硬盘也应该会是300GB为主流,因此如果采用恒码率MPEG2的话,存储媒介方面其实问题不大。

  但是网络带宽方面则显然不是这么一回事,目前的ADSL下载带宽上限为8~12Mbps,但是实际应用中也不过是2Mbps,而且能达到 2Mbps是不常见的。下一代的宽带技术应该是ADSL2+,下行带宽上限是24Mbps,不过从目前的ADSL实际应用看,24Mbps恐怕没有多少用户能享受到,能有1/3就很不错了。所以对于HD视频来说,必须采用比恒码率MPEG2更高效的压缩编码技术才能在未来的网络应用中让用户真真正正地享受到流畅的欣赏体验。

  然而可怕的事情来了,业界(下一代DVD的两个阵营以及DVB-S2)对于高清晰视频的压缩标准采取了有点模棱两可的态度,DVD标准制定组织 DVD Forum居然接纳了VC-1(WMVx的纯算法版)、H.264、MPEG2三种压缩标准,这对于上游厂商或者说标准制定者来说,有点皆大欢喜的味道,但是对于芯片厂商来说则是比较痛苦的:他们必须以最小的代价把三种标准的解决方案集成到同一枚芯片中,因为众多的节目内容商采用的编码方式肯定不会都只有一个。

  不过这不光是三个标准的技术实现问题,而且还包括三个技术的权利金以及台底下的角力(例如VC-1编解码器开发程度),纵然芯片厂商有能力把三个技术马上集成到同一枚芯片中,但是标准、授权制度制订的拖沓,往往会导致产品迟迟无法出台。

  H.264和VC-1在技术上比较接近,但是VC-1的前途由于是来自微软推荐的,而微软过去在DOS->Windows以及其他一些事情上曾经表现出来的蛮横/封闭性做法曾引起过大家的强烈不满,因此在业界对推动H.264显得更加积极。

系统分类: 嵌入式  |  用户分类: h.264编解码  |  标签: 无标签  |  来源: 无分类  | 

点击查看原文

发表评论 阅读全文(1052) | 回复(0)

发表于 2006/8/10 20:05:55

1

关于投票

H.264解码方案介绍

网络数字电视应用如火如荼的展开,H.264视频压缩国际标准也浮出水面,逐渐被大家所熟悉。H.264是由国际电信标准化部门ITU-T和制定 MPEG的国际标准化组织ISO/国际电工协会IEC共同制订的一种视频编码国际标准格式。H.264标准产生的初衷就是制定一个新的视频编码标准,以实现视频的高压缩比、高图像质量、良好的网络适应性。H.264同时又被称为MPEG-4 AVC(“活动图像专家组-4的高级视频编码”)或称为MPEG-4 Part10。

从H.264在2003年7月正式颁布后,电视广播、家电和通信三大行业都已进入H.264的实际运用研发中。比如象DVD联盟、日本广播电视公司、欧洲 DVB Steering Board、美国数字电视的卫星传送等机构都已决定采纳H.264标准。作为一个新的技术标准,为什么会在发布不到一年的时间内就获得这等“殊遇”,从各方面的评价来看,不外乎两个主要原因:

一、技术上的无可比拟的优势:在相同画面质量的情况下,H.264需要的带宽只有MPEG-4 ASP的1/2、MPEG-2的1/5。这个性能优势将允许流媒体在更低的带宽上传输,节省带宽成本。

二、多个标准组织的支持:H.264是ITU、MPEG、DVD、DVB、3GPP等工业化组织共同推进的下一代视频编码国际标准,我们知道,ITU在电信领域,MPEG和DVD组织在家用数字AV产品领域(如DVD、VCD),DVB组织在数字电视领域(DTV、HDTV),3GPP在下一代移动通信领域都有着不可撼动的地位,他们均得到国际工业界数百家大公司的支持,可以想见,在这些行业巨擘的推动下,H.264术的应用将迅速进入到视频服务、媒体制作发行、固定及移动运营网络、平台开发、设备终端制造、芯片开发等多个领域。

H.264 的高压缩比,高图像质量和国际性的特征非常适合像网络视频应用这样在带宽受限,紧缺的应用中,H.264大大降低了对网络带宽的需要,减轻了带宽和图像质量的矛盾所带来的运营成本的压力,同时也降低了存储,硬件设备等成本,为运营商创造了更大的盈利空间。例如在北美专为华人提供华语节目的麒麟电视台就采用了H.264作为其商用网络数字电视运营平台的视频压缩标准,在500~900kbps带宽条件下为用户提供近似DVD质量的视频点播(VOD)和视频直播节目。

H.264标准被网络数字电视应用的业界人士普遍看好,例如最近,中国电信透露将选择H.264和VC1作为其网络数字电视平台的编解码标准。然而现在实际在商用网络中应用并不广泛,主要原因是支持H.264的网络数字电视终端-网络机顶盒的生产厂家不多,更进一步讲提供H.264解码解决方案的技术提供商很少。在今年三月的中国国际广播电视信息网络展览会(CCBN2005)中展示采用H.264解码方案的 IP机顶盒有两家产品,分别是日本的Sentivision的产品和国内的北京传视数码科技有限公司拥有自主知识产权的数字媒体播放机(DMD)。那么为什么H.264解码方案的技术提供商不多呢?

至关重要的是H.264高性能的代价就是高复杂度,高复杂度带来的问题一是技术门槛增高,H.264 编解码标准的源码可以在网上免费下载,但编解码的速度很慢,所以简单的“拿来主义”,是无法在实际产品中使用的,这就需要研发H.264编解码的人员对 H.264标准有深入研究和理解,选择相应档次(Profile)和级(level)以满足应用的需求。更重要的是还需要对算法,指令级等方面进行充分的优化,从而达到产品性能的要求。问题二是消耗系统资源高,这就带来的产品硬件成本的增高,所以需要设计更为合理的软硬件架构来保证性能的同时尽可能地降低成本。

通常实现解码的方案采用CPU,DSP,ASIC和FPGA的架构,而目前 DSP成为实现H.264 解码的主流。像Sentivsion使用的是TI的DM642 DSP用于H.264的解码;传视数码的DMD系列网络机顶盒产品是采用ADI的Blackfin系列DSP完成其H.264的解码。这与DSP的特点关系紧密。DSP也是一种CPU,它们经特别设计,适合数字信号处理算法,应用于数字电视的多媒体处理一般正属于这种算法。通用CPU的最大问题是功耗太大,从Intel奔腾级别的处理器开始,都需要带一个风扇或冷凝器来降温。CPU和风扇或冷凝器均须占用较大的体积,这在嵌入式系统中常常是不能忍受的;同时也带来了设备对环境的较高要求,在高温、灰尘大的环境里,非常容易导致风扇机械性损坏,不可避免地烧坏CPU;这样也使设备的稳定性下降。而DSP的优势在于功耗非常非常的低(常常为数十到百mW级别),体积较小,价格也十分便宜。同时也适用于单纯解码这种应用。所以DSP的架构更适用于H.264 的解码方案。

目前能支持H.264解码的DSP处理芯片除上面提到的TI公司的 DM642 DSP和ADI公司Blackfin处理器;EQUATOR 公司的BSP16,Sigma Design公司的EM86XX,还有Philip公司的TriMedia系列及新品PNX1500等。

但并不是解决了解码问题,就万事大吉了,如何进一步降低硬件成本,生产出的解码设备性能稳定可靠,而且功能强大,的确是一件十分复杂繁琐的工作,特别是在软件系统方面,由于机顶盒性能的局限性和使用的实时性,它无法像PC那样可以支撑庞大的运行环境与程序,也缺乏完善的开发工具,这对软件开发者而言是一件很具有挑战性的工作。我们就以传视数码的H.264解码解决方案为例,了解一下H.264 解码方案的硬件和软件架构。

从结构上看,机顶盒一般由DSP、CPU、内存、外部存储控制器以及视音频输出,宽带接口等几大部分构成,如图1所示:


图1 H.264解码解决方案的硬件架构示意图

传视数码的H.264 解码解决方案采用美国模拟器件公司(Analog Devices, Inc.,简称ADI)Blackfin561双内核处理器完成视频编码和音频解码。ADI 的Blackfin适用于要求强大处理能力支持的音视频解码,特别是符合算法更为复杂的H.264 解码的要求。

同时,DSP 的采用为支持多编码标准提供了硬件上经济且灵活的解决方案。目前,数字电视市场没有统一的编解码标准,市场上采用较多的标准有MPEG-2, MPEG-4 ASP, MWV, H.264等,而且就目前的政策和市场情况而言,这种多编解码标准共存的局面还将持续很长的一段时间,所以能支持多编解码标准解决方案将更能适应市场的需求。

目前,采用H.264的Main Profile,支持码流500Kbps – 3Mbps,实现full D1,即DVD的视频质量。音频解码支持AAC5.1/MP3标准。除此之外,还可支持MPEG-2,MPEG-4,MWV9的音视频解码。

采用国内方舟II号GT2000 CPU处理操作系统,网络连接和与网络数字电视相关的应用程序,GT2000 CPU 主频为330MHz, 采用的操作系统为Linux,处理视频点播(VOD),组播,下载,推送等多种应用。

由于DSP完全负责了复杂的音视频编解码运算,所以CPU相对工作量少很多,所以没必要选用主频更高的处理器而无谓地增加成本。

内存主要分为Flash内存和SDRAM内存,此解决方案中采用8MB Flash ROM,64MB和32MB SDRAM分别支持系统和DSP工作。

Flash 用来驻留解码解决方案的系统软件、驱动软件、应用程序以及一些用户信息,系统断电时内容还可保留,同时通过在线更新Flash中驻留的软件,达到在线软件升级的目的。SDRAM主要是用来存储应用数据。解码解决方案的许多功能都需要内存来实现,例如音视频解码,图形处理等。内存是配合DSP/CPU来工作的,容量大的Flash和SDRAM的配置虽然可以为将来可能的新增应用预留内存空间,但并不是内存越大,软件的运行性能就越好,所以内存配置应与实际需求相一致,过大的配置只会增加成本,而对解码方案性能提高无意。

外部存储设备一般指外挂式硬盘。可根据用户需求,使用80GB,120GB 或200GB大小的硬盘,支持节目下载应用。以80GB硬盘为例,可支持200小时以上的H.264格式的节目内容。

外部存储设备一般指外挂式硬盘。可根据用户需求,使用80GB,120GB 或200GB大小的硬盘,支持节目下载应用。以80GB硬盘为例,可支持200小时以上的H.264格式的节目内容。

网络融合势必带来融合的终端的需求,而数字电视和网络的融合要求,也带动了支持数字电视和DVB功能的“双模”机顶盒的要求。传视数码正是基于这样的市场需求,在其H.264解码解决方案中提供了DVB接收的可选功能。

提供连接电视的多种接口,包括S端子,CVBS和YpbPr, 同时提供视频输入接口,用于与摄像头的连接,可根据市场需求,扩展视频电话或视频会议应用。

音频输出支持RCA接口。

10/100Mbps 以太网接口:集成的 10/100Mbps 以太网接口可提供DSL设备或cable modems的连接.WLAN接口(可选):支持802.11b/g无线局域网。同时对于使用DSL宽带接入的用户,家中客厅多半没有宽带接口,如果进行客厅布线改造,费时费力,部署非常复杂。但采用无线AP与原有DSL设备相连,就能迅速完成家庭宽带的客厅部署,实施简单,费用经济。

为方便连接外围设备,解决方案提供集成的USB端口,以提供更广泛的视频应用。

H.264解码解决方案作为一个终端产品,除了要具有良好的硬件平台外还需要配备不同的软件系统才能使其完成各种任务。软件架构可以分成三个主要的层:应用层、应用框架层,中间件层和驱动层,每一层都包含了诸多的程序或接口等,如图2所示。


图2 H.264解码解决方案的软件架构

系统层包括解码方案硬件的嵌入式操作系统,H.264/MPEG-2/MPEG-4/WMV9视频解码和音频解码程序和CA模块,它主要用于完成对硬件设备的系统操作,音视频解码,和应用于DVB接收的CA认证等工作。

中间件层包括嵌GUI、网络链接管理,应用管理,资源管理,CA接口和SI解析等。中间件的使用可以给 H.264解码方案软件的设计和应用带来极大好处,非常适用于将来更多新的应用的扩展需求。

应用框架层和应用层驻留应用程序以实现不同的应用需求,应用框架层驻留不同应用的共同特征部分,而应用层则针对不同应用的特殊部分。传视数码的H.264解码方案提供与数字电视相关的视频点播、直播、组播、下载,EPG(网络数字电视的EPG处理)和其他应用。需要指出的是DVB的EPG解析是通过中间件 SI解析(parse)完成的。

正如文章前面所分析的那样,整个方案的优势首先在于利用了H.264自身的高压缩的编码特征,从而在1Mbps – 1.5Mbps条件下实现DVD的视频质量。其二由于采用DSP+CPU的架构,达到了性能和成本的最佳平衡点,支持多种编码格式和将来可能出现的新的编码格式的最佳方案。其三提供了一个数字电视和DVB融合的双模架构。最后多种应用,多种输入输出方式和多种网络接入方式支持,可以衍生多种产品系列,从而针对相应用户群,迅速在市场上推出满足用户需求的产品,例如H.264 网络机顶盒,H.264播放机等等。

随着更多H.264解码方案的完善和推出,H.264编解码标准不再只是业内所推崇的技术标准,而将迅速占领市场,成为网络数字电视平台的编解码标准,网络数字电视终端-网络机顶盒产品的主流。

系统分类: 嵌入式  |  用户分类: h.264编解码  |  标签: 无标签  |  来源: 无分类  | 

点击查看原文

发表评论 阅读全文(5851) | 回复(1)

发表于 2006/8/10 17:40:57

2

关于投票

H.264标准及其在视频会议系统中的应用

摘要 随着我国通信网络设施的快速发展,视频业务也迅速发展起来,ITU-T也制定了多种相关标准,本文主要介绍了视频会议系统的基本概念及其对新的视频编解码技术提出的要求,分析了H.264编码标准的特点和技术优势,并介绍了H.264H.323系统中的实现方法。

关键词 H.264 H.323 图像 片 宏块 预测

1
、引言

   视频会议系统是一种可以在两点或多点间实现实时传送视频、音频和应用数据等多种信息、具有会议功能的多媒体通信系统。近年来,随着我国通信网络基础设施的快速建设和经济的飞速发展,会议电视业务由于可以为处于两点或多点的与会者提供视音频和数据等多种信息,节省大量费用,提高工作效率而发展迅速,并有望 成为下一代网络(NGN)的主要业务。H.264是由ITU-TISO两个组织的专家为实现视频的更高压缩比,更好的图像质量和良好的网络适应性而提出 的新的视频编解码标准。事实证明,H.264编码具有比其他的H系列视频压缩标准节省码流,比MPEG-4算法简单的特点。H.264的良好网络适应性和 内在的抗丢包能力、抗误码机制,使它不仅适于IP传输方式,也适合丢包严重、时延和抖动复杂的无线信道。H.264有望成为多媒体通信中首选的视频编解码标准。

2
、视频会议系统对视频编解码的要求

  视频会议系统从产生至今,ITU-T制定了多种适合于各类通信网络的标 准,目前通信网上传输多媒体信息的系统主要有H.320(基于ISDN)H.324(包括H.324IH.324PH.324M)H.31O(基于ATM)H.323(基于LAN)四类系统。随着IP问题(安全和QoS问题)的逐步解决,以IP作为承载网的优势将更加明显,下一代网络也将采用 IP技术作为承载网技术,因此本文以适用于在IP网上提供多媒体业务的H.323系统为主进行阐述。

  视频会议系统对视频编解码标准的具体要求是:

  (1)由于目前IP网络接入方式有LAN接入,EthernetxDSL等多种方式,一些接入方式如xDSL可提供的带宽有限,除去音频、数据占用的带宽,传输视频的可用带宽更少,要求视频编解码高效,压缩率高。

  (2)网络适应性好,便于视频流在网络中传输,

  (3)抗丢包性能和抗误码性能好,适应各种网络环境,包括丢包和误码严重的无线网络。

3
H.264编码的技术优势

  由于H.264在制定时就充分考虑了多媒体通信对视频编解码的各种要求,并借鉴了H系列和MPEG系列视频标准的研究成果,因而具有明显的优势。结合视频会议系统对视频编解码技术的要求,H.264的优势表现在以下三个方面:

  3.1 压缩率和图像质量方面

  H.264通过对传统的帧内预测、帧间预测、变换编码和熵编码等算法的改进来进一步提高编码效率和图像质量。

   (1)块的大小可变。在运动估计时,可以灵活地选择块的大小。在宏块(MB)划分上,H.264采用了16×616×88×168×8四种模式;当划分为8×8模式时,又可进一步采用8×44×84×4三种子宏块划分模式(见图1)进一步划分,这样做既可以使运动物体的划分更加精确,减小运动 物体边缘的衔接误差,又可以减小变换过程中的计算量。当对较大的平滑区域采用Intra_16×16的帧间预测方式时,为减小小尺寸变换带来的块间灰度差 异,H.264采用了对亮度数据的164×4块的DC系数进行第二次4×4变换,对色度数据的44×4块的DC系数进行22变换的方式。

  (2)1/4像素精度的运动估值。在H.264中 通过6FIR滤波器的内插获得1/2像素位置的预测值。当1/2像素值获得后,通过取整数像素位置和1/2像素位置像素值均值的方式获得1/4像素位置 的值。采用高精度运动估计会进一步减小帧间预测误差,减少了经变换和量化后的非O比特数,提高了编码效率。

  (3)多参考帧运动估值。 以往的编解码技术在对P()图像进行帧间预测时,只允许以前一个I图像或P图像为参考帧,对B图像进行预测时只允许以前后两个I图像或P图像为参考图 像。H.264则打破了这些限制,允许在Reference Buffer中的多个图像中选取一个(P预测方式)或两个(B预测方式)图像作为参考图像,参考图像甚至可以是采用双向预测编码方式的图像。

  (4)参考图像的选取与其编码方式无关。允许选取与当前图像更加匹配的图像为参考图像进行预测,减小了预测误差,提高编码效率。

  (5)加权预测。允许编码器以一定的系数对运动补偿预测值进行加权,从而在一定的场景下可以提高图像质量。

  (6)Intra_4×4模式的帧间预测。在这种模式下,每个4×4块都可以利用其上方和左侧的17个最接近的像素进行预测。

   (7)循环内的消除块效应滤波器。为消除在预测和变换过程中引入的块效应,H.264也采用了消除块效应滤波器,但与以往标准不同的是,H.264的消 除块效应滤波器位于运动估计循环内部,可以利用消除块效应以后的图像去预测其它图像的运动,进一步提高预测精度。滤波强度取决于宏块的预测方式、量化参数、运动矢量等。量化步长减小时,滤波器的作用也会相应降低。

  (8)更好的熵编码算法CAVLCCABAC

  3.2 网络适应性方面

  为了方便地在各种系统中灵活有效的应用H.264H.264编解码系统(见图2)定义了视频编码层VCL和网络提取层NAL。其中,VCL用于视频编解码,包括运动补偿,变换编码和熵编码等单元,NAL用于采用统一的格式对VCL视频数据的进行封装打包。
  (1)NAL Units。视频数据封装在整数字节的NALU中,它的第一个字节标志该单元中数据的类型。H.264定义了两种封装格式。基于包交换的网络系统可以使用 RTP封装格式封装NALU,并且可以通过在NALU后面增加一个16位的信息域的方式将多个NALU放在一个RTP中传输。另一些系统,如H.320系 统或MPEG-2系统可能会要求将NALU作为顺序比特流传送,为方便在这些系统中使用H.264H.264定义了一种比特流格式的传输机制,使用头编 码前缀(start code prefix)NALU封装起来,并用一个有限状态机来保证头编码前缀不会出现在它封装的NALU中,防止了错误定界的发生。

   (2)参数集。在以往视频编解码标准中,GOB\GOP\图像头信息是至关重要的,包含这些信息的包的丢失将直接导致与这些信息相关的数据不可用,因此这些标准大都采用了冗余编码技术来保护这些头信息。为解决这些问题,H.264将这些很少变化并且对大量VCL NALU起作用的信息放在参数集中传送。参数集分为两种,即序列参数集sequence parameter set和图像参数集picture parameter set,前者对一系列连续编码图像起作用,后者对连续编码图像序列中的单独图像起作用。VCL NALU通过标识位来指定它所参考的参数集。为适应多种网络环境,参数集可以带内传送,也可以采用带外方式传送。

  3.3 抗丢包和抗误码方面

  在H.264中,参数集,片的使用,FMO,冗余片等关键技术的使用可以大大提高系统的抗丢包和抗误码性能。

  (1)参数集的使用。参数集及其灵活传送方式的使用本身会大大降低因关键的头信息丢失而造成错误发生的可能。为保证参数集可靠的到达解码器端,可以采用重发的方式多次发送同一参数集,传送多个参数集或将参数集固化在解码器中。

   (2)(slice)的使用。在不使用FMO时,片是一系列宏块按照光栅扫描顺序的组合。图像可以划分成一个或几个片。片是独立的,也就是说,在编码 器和解码器使用的参考图像一致的情况下,只要给定序列参数集和图像参数集,片的语法元素和该片图像采样值就可以从码流中解析出来,而不需要其他片的数据 (片边缘消除块效应滤波过程可能会需要其他相邻片的数据)。将图像划分为多个片,当某一片不能正常解码时的空间视觉影响就会大大降低,而且片的头部还提供了重同步点。

  (3)FMO技术。通过FMO可以进一步提高片的差错恢复能力。通过片组(slice group)的使用,FMO改变了图像划分为片和宏块的方式。宏块到片组的映射定义了宏块属于哪一个片组。利用FMO技术,H.264定义了7种宏块扫描模式。

  如图3所示,阴影部分宏块属于片组0,白色部分属于片组1。假设片组O在传输过程中丢失,由于丢失宏块的相邻宏块都属于片组1,这样差错恢复工具就会有更多的可利用信息来恢复丢失片的数据。

  (4)帧内预测。H.264借鉴了以往视频编解码 标准在帧内预测上的经验,值得注意的是,在H.264中,IDR图像可以使短期参考图像缓存无效,之后的图像解码时不再参考IDR图像之前的图像,因而 IDR图像具有强壮的重同步性能。在一些丢包和误码严重的信道中,可以采取不定期传送IDR图像的方式进一步提高H.264的抗误码和抗丢包性能。

  (5)冗余片。为提高H.264的解码器在发生数据丢失时的健壮性,可以采用传送冗余片的方式。这些冗余片可以是基本图像的一部分。冗余片和基本片可以采用不同的编码参数,当基本片丢失时,可以通过冗余片重构原图像。

   (6)数据划分。由于运动矢量和宏块类型等信息相对于其他信息具有更高的重要性,因而在H.264中引入了数据划分的概念,将片中语义彼此相关的语法元 素放在同一个划分中。在H.264中有三种不同的数据划分。第一类划分中包含头信息等重要信息,如宏块类型、量化参数和运动矢量等,称为A类划分。第二类 划分包含帧内CPB和帧内系数,称为B类划分。第三类划分包含帧间CBPs和帧间系数,称为C类划分。若解码器发现帧内信息或帧间信息丢失,由于宏块类型 和运动矢量等重要信息的存在,仍然可以使差错恢复工具具有良好的性能。

  (7)多参考帧运动估值。多参考帧运动估值的一个作用是可以提高编码器的编码效率,另一个作用是提高差错恢复能力。在有反馈的系统(如采用RTP/RTCP作为应用层传输协议的通信系统)中,当编码器得知有图像丢失时,可以选择解码器已经正确接收的图像作为参考图像。

  (8)为阻止错误在空间上的蔓延,解码器端可以指定当P片或B片中的宏块在做帧内预测时不使用相邻的非帧内编码宏块作为参考。

4
、在H.323系统中实现H.264

   由于H.264是一种新的视频编解码标准,与以往标准在体系结构等方面有诸多差异,在H.323体系中应用H.264存在一些问题,比如如何在 H.245能力协商过程中正确协商端点之间的H.264能力和参数,因此必须对H.323标准的进行必要补充和修改。为此,ITU-T制定了H.241标 准。H.241标准定义了如何在原有的H.300系列终端间应用H.264视频编解码标准进行通信,废除了一一些不再适合H.264使用的信令,重新定义 了一些扩展信令来支持H.264。本文仅介绍与H.323相关的修改。

  (1)如何在H.245能力协商过程中协商H.264能力。 H.264能力集是一个包含一个或多个H.264能力的列表,每一个H.264能力都包含ProfileLevel两个必选参数和 CustomMaxMBPSCustomMaxFS等几个可选参数。在H.264中,Profile用于定义生成比特流的编码工具和算法,Level则 定义一些关键的参数。H.264能力包含在GenericCapability结构中,其中CapabilityIdentifier的类型为 standard,值为0.O.8.241.O.O.1,用于标识H.241能力。MaxBitRate用于定义最大比特率。Collapsing字段包 含H.264能力参数。

  ·ProfileParameterIdentifier类型为standard,值为41,用于标识 ProfileParameterValue类型为booleanAr-ray,其值标识Profile值,可以为643216,分别表示 BaselineMainExtended三个Profile

  ·LevelParameterIdentifier类型为standard,值为42,用于标识LevelParameterValue类型为unsignedMin,其值标识对应15个可选的Level值。

  其他的几个参数作为可选项出现。

   (2)由于H.264中图像的组织结构与传统的标准不同,一些原有的H.245信令不在适用于H.264(Miscella- neousCommand中的videoFastUpdateGOBvideoSendSync EveryGOB),因此H.241重新定义了几个信令。

  (3)H.264RTP封装格式参考RFC3550,载荷类型(PT)域未作规定。

5
、结束语

   作为一种新的国际标准,H.264标志着在视频编码技术上的不断进步,它在编码效率、图像质量、网络亲和性和抗误码方面都取得了成功。但随着终端和网络的快速发展,对视频编解码的新要求在不断出现,H.264也仍在继续完善和发展。目前,对H.264的研究主要集中在如何进一步优化算法结构、降低处理时 延、提高实时性和进一步提高图像质量上。目前,很多厂家都推出了使用H.264进行编解码的视频会议系统,大多数做到了在Baseline Profile上的互通。试验证明,H.264的图像质量较以往标准确实有很大的提高,尤其是在低码率的情况下。随着H.264自身的不断完善和视频通信的不断普及,相信H.264的应用将越来越广泛。

 

系统分类: 嵌入式  |  用户分类: h.264编解码  |  标签: 无标签  |  来源: 无分类  | 

点击查看原文

发表评论 阅读全文(1133) | 回复(0)

发表于 2006/8/10 12:39:26

1

关于投票

H.264开源解码器评测(转发)

 

20035月,当H.264编码标准草案发布时,很多人都觉得H.264太复杂,不宜实用。眨眼间3年过去了,以往的论断、疑惑被如今的现实冲洗的干干净净。随着硬件性能的提高和视频编码工作者对H.264的不断优化,如今的H.264已完全实用,最新的达芬奇芯片上能实现D1分辨率(720*480)视频的实时编码,而对于解码,普通的PC机就能实现x264编码的DVDrip电影的流畅播放。纵观过去的三年,有多少人对H.264倾注了热情和汗水才换来今天的成绩,而那些H.264的开源项目以及参与这些项目的开发者自然是功不可没。

本文评测的是作者接触过的H.264开源解码器,包括:JM decoder, T264 decoder, x264 decoder, ffmpeg libavcodec, Intel IPP simple player。评测的内容有:对H.264特性的支持、解码速度以及二次开发难易程度。

 

一、H.264开源解码器介绍

1JM decoder

JM decoderH.264的官方源码,通常也称为校验模型。其特点是支持特性好,实用性差。本文选用的程序是JM86,不支持high profile,因为本文不对high profile部分进行实验比较。

NOTE: JM一直没有做实用化方面的努力,所以其解码速度代表的是2003年的水平。

 

2T264 decoder

T264是国内的开源项目,T264 decoder的程序做过汇编优化,速度还可以,但只能解T264本身的码流。作者对T264 decoder version 0.142005-3-29)作了修改,支持baseline的解码。

 

3x264 decoder

x264本没有decoder,但其包含decoder的部分函数雏形,猜想作者在一开始时是准备实现decoder,后来可能是因为有了ffmpeg,就放弃了这个想法(纯粹属于猜测,呵呵)。

本文的x264 decoder是作者在x264 svn check out 2005.12.26的基础上实现的,支持baseline的解码。

 

4ffmpeg libavcodec

ffmpeg是一个大项目,它包含各种音视频标准的codec,还支持各类file format.avi, .mp4, .mkv and etc)的parsing。所以,很多开源项目都有直接或间接地采用了ffmpeg,如mplayer播放器就是直接采用了ffmpeg,而mpc播放器则是先采用了ffdshow filter,而ffdshow又采用了ffmpegffmpeg是一个非常棒的音视频编解码库,支持的标准非常全,而且编解码速度也很快。

本文实验采用的是cvs check out 2006.02.20的版本,作者对其中的apiexample demo进行了简单的修改,用于解码h.264

 

5Intel IPP simple player

IntelIPP库,全称为Integrated Performance Primitives,在Intel的各种处理器平台(IA-32, Itanium, xscale and etc)上实现了信号处理常用算法、常用数学运算及音视频编解码算法等等。IPP给我的第一感觉是,在Intel的处理器平台上,它实现的各种算法应该是最快的,至于实际结果如何,待等到实验比较后见分晓。

本文采用的IPP库版本为IA32 5.1.017 评估版

Intel IPP simple player是用于播放各种音视频文件的简单播放器,用c++实用,具体算法调用IPP库来实现。本文采用的simple player版本是5.0.017

 

二、对于H.264特性的支持

1JM86 decoder

support baseline, extended, main profile

 

2T264 decoder

baseline

 

3x264 decodeer

baseline

 

4ffmpeg libavcodec

support baseline, main profile, high profile except the feature: paff, mbaff…

 

5Intel IPP simple player

support baseline and main profile

 

三、评测条件

1、所用测试序列

 

1 所用测试序列

分辨率

序列名称

特点

编码帧数

QCIF

foreman

纹理复杂度一般

运动剧烈:画面人物和镜头均运动,还有场景的切换

300

CIF

foreman

同上

300

mthr_dotr

背景简单

画面人物运动幅度不大

100

mobile

纹理复杂度极高

运动形式丰富——画面有多个运动物体,但各运动物体运动方向规则且平缓,镜头也在移动

200

D1(720*480)

soccer2

镜头有移动,画面的足球运动员的运动也很剧烈

300

puppy

镜头无运动,画面中的玩具小狗也只有简单的运动

100

 

2、编码参数

编码程序:x264 svn check out 2006.05.06

参数设置示例:x264enc --frames 300 --no-cabac --qp 26 -o test.264 foreman.cif 352x288(相当于baseline

量化步长:2636

 

2、环境

CPU: Pentium4 2.4GHz, RAM: DDR 512M

OS: windows2000 professional+sp4

 

3、解码器程序编译环境

JM86 decoder: vc71 release

T264 decoder: vc71 release

x264 decodeer: vc71 release

ffmpeg libavcodec: MinGW

Intel IPP simple player: vc71 release + directX 9.0c sdk

 

4、解码参数设置

不保存重建序列(note: 是否保存重建序列对于解码速度的影响很大)

 

四、解码速度比较结果

待补充完整。。。

2 解码速度比较(单位:fps

分辨率

序列名称

量化步长

JM86 decoder

x264 decodeer

ffmpeg libavcodec

QCIF

foreman

26

50fps左右

684.93

1196

36

874.64

1916.67

CIF

foreman

26

15fps左右

168.44

303.86

36

190.11

503.37

mthr_dotr

26

182.82

421.28

36

200

634.62

mobile

26

129.28

190.07

36

173.01

353.46

D1(720*480)

soccer2

26

5fps左右

53.04

105.17

36

60.19