常见视频编码比较大全 常见视频解码技术资料1

本文详细介绍了多种视频格式的特点和应用场景,包括AVI、ASF、MPEG、DIVX、Xvid等本地影像视频格式,以及ASF、WMV、RM、RMVB等网络影像视频格式。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

ASF

ASF 是 Advanced Streaming format 的缩写,由字面(高级流格式)意思就应该看出这个格式的用处了吧。说穿了 ASF 就是 MICROSOFT 为了和现在的 Real player 竞争而发展出来的一种可以直接在网上观看视频节目的文件压缩格式!由于它使用了 MPEG4 的压缩算法,所以压缩率和图像的质量都很不错。因为 ASF 是以一个可以在网上即时观赏的视频“流”格式存在的,所以它的图象质量比 VCD 差一点点并不出奇,但比同是视频“流”格式的 RAM 格式要好。不过如果你不考虑在网上传播,选最好的质量来压缩文件的话,其生成的视频文件比 VCD (MPEG1)好是一点也不奇怪的,但这样的话,就失去了 ASF 本来的发展初衷,还不如干脆用 N AVI 或者 DIVX 。但微软的“子第”就是有它特有的优势,最明显的是各类软件对它的支持方面就无人能敌。

n AVI

n AVI 是 newAVI 的缩写,是一个名为 ShadowRealm 的地下组织发展起来的一种新视频格式。它是由 Microsoft ASF 压缩算法的修改而来的(并不是想象中的 AVI),视频格式追求的无非是压缩率和图象质量,所以 NAVI 为了追求这个目标,改善了原始的 ASF 格式的一些不足,让 NAVI 可以拥有更高的帧率(frame rate)。当然,这是牺牲 ASF 的视频流特性作为代价的。概括来说, NAVI 就是一种去掉视频流特性的改良型 ASF 格式!再简单点就是---非网络版本的 ASF !

AVI

AVI 是 Audio Video Interleave 的缩写,这个看来也不用我多解释了,这个微软由 WIN3.1 时代就发表的旧视频格式已经为我们服务了好几个年头了。如果这个都不认识,我看你还是别往下看了,这个东西的好处嘛,无非是兼容好、调用方便、图象质量好,但缺点我想也是人所共知的:尺寸大!就是因为这点,我们现在才可以看到由 MPEG1 的诞生到现在 MPEG4 的出台。

MPEG

MPEG 是 Motion Picture Experts Group 的缩写,它包括了 MPEG-1, MPEG-2 和 MPEG-4 (注意,没有MPEG-3,大家熟悉的MP3 只是 MPEG Layeur 3)。MPEG-1相信是大家接触得最多的了,因为它被广泛的应用在 VCD 的制作和一些视频片段下载的网络应用上面,可以说 99% 的 VCD 都是用 MPEG1 格式压缩的,(注意 VCD2.0 并不是说明 VCD 是用 MPEG-2 压缩的)使用 MPEG-1 的压缩算法,可以把一部 120 分钟长的电影(未视频文件)压缩到 1.2 GB 左右大小。MPEG-2 则是应用在 DVD 的制作(压缩)方面,同时在一些 HDTV(高清晰电视广播)和一些高要求视频编辑、处理上面也有相当的应用面。使用 MPEG-2 的压缩算法压缩一部 120 分钟长的电影(未视频文件)可以到压缩到 4 到 8 GB 的大小(当然,其图象质量等性能方面的指标 MPEG-1 是没得比的)。MPEG-4 是一种新的压缩算法,使用这种算法的 ASF 格式可以把一部 120 分钟长的电影(未视频文件)压缩到 300M 左右的视频流,可供在网上观看。其它的 DIVX 格式也可以压缩到 600M 左右,但其图象质量比 ASF 要好很多。

DIVX

DIVX 视频编码技术可以说是一种对 DVD 造成威胁的新生视频压缩格式(有人说它是 DVD 杀手),它由 Microsoft mpeg4v3 修改而来,使用 MPEG4 压缩算法。同时它也可以说是为了打破 ASF 的种种协定而发展出来的。而使用这种据说是美国禁止出口的编码技术 --- MPEG4 压缩一部 DVD 只需要 2 张 CDROM!这样就意味着,你不需要买 DVD ROM 也可以得到和它差不多的视频质量了,而这一切只需要你有 CDROM 哦!况且播放这种编码,对机器的要求也不高,CPU 只要是 300MHZ 以上(不管你是PII,CELERON,PIII,AMDK6/2,AMDK6III,AMDATHALON,CYRIXx86)在配上 64 兆的内存和一个 8兆 显存的显卡就可以流畅的播放了。这绝对是一个了不起的技术,前途不可限量!
 
Xvid

Xvid(旧称为XviD)是一个开放源代码的MPEG-4视频编解码器,它是基于OpenDivX而编写的。Xvid是由一群原OpenDivX义务开发者在OpenDivX于2001年7月停止开发后自行开发的。Xvid支持多种编码模式,量化(Quantization)方式和范围控,运动侦测(Motion Search)和曲线平衡分配(Curve)等众多编码技术,对用户来说功能十分强大。Xvid的主要竞争对手是DivX。但Xvid是开放源代码的,而DivX则只有免费(不是自由)的版本和商用版本。  近五年来,XviD一直是世界上最流行的视频编码器。估计在BT(BitTorrent)和eMule上至少90%的电影、电视剧是用XviD压制的。但是在中国的情况有些特殊,因为中国的影视发布者喜欢用RMVB格式。XviD的文件扩展名可以是AVI、MKV、MP4等。需要说明的是,仅从扩展名并不能看出这个视频的编码格式。比如说一部电影是.avi格式,但是实际上的视频编码格式可以是DV Code,也可以是XviD或者其他的;音频编码格式可以是PCM、AC3或者MP3。
  MP4和MKV格式比AVI更先进,支持更多的功能,比如字幕。AVI视频的字幕需要另外的SRT文件。目前国外绝大多数的影视资源都是AVI格式。

 

QuickTime

QuickTime(MOV)是 Apple(苹果)公司创立的一种视频格式,在很长的一段时间里,它都是只在苹果公司的 MAC 机上存在。后来才发展到支持 WINDOWS 平台的,但平心而论,它无论是在本地播放还是作为视频流格式在网上传播,都是一种优良的视频编码格式。到目前为止,它共有 4 个版本,其中以 4.0 版本的压缩率最好!

REAL VIDEO

REAL VIDEO (RA、RAM)格式由一开始就是定位就是在视频流应用方面的,也可以说是视频流技术的始创者。它可以在用 56K MODEM 拨号上网的条件实现不间断的视频播放,当然,其图象质量和 MPEG2、DIVX 等比是不敢恭维的啦。毕竟要实现在网上传输不间断的视频是需要很大的频宽的,这方面 ASF 的它的有力竞争者!
什么是RMVB格式
所谓RMVB格式,是在流媒体的RM影片格式上升级延伸而来。VB即VBR,是Variable Bit Rate(可改变之比特率)的英文缩写。我们在播放以往常见的RM格式电影时,可以在播放器左下角看到225Kbps字样,这就是比特率。影片的静止画面和运动画面对压缩采样率的要求是不同的,如果始终保持固定的比特率,会对影片质量造成浪费。

而RMVB则打破了原先RM格式那种平均压缩采样的方式,在保证平均压缩比的基础上,设定了一般为平均采样率两倍的最大采样率值。将较高的比特率用于复杂的动态画面(歌舞、飞车、战争等),而在静态画面中则灵活地转为较低的采样率,合理地利用了比特率资源,使RMVB在牺牲少部分你察觉不到的影片质量情况下最大限度地压缩了影片的大小,最终拥有了近乎完美的接近于DVD品质的视听效果,如图1所示的就是RMVB格式的《圣斗士冥王篇》。可谓体积与清晰度“鱼与熊掌兼得”,其发展前景不容小觑。

相较DVDrip而言,RMVB的优势不言而喻。首先在保证影片整体视听效果的前提下,RMVB的个头只有300~450MB左右(以90分钟的标准电影计算),而DVDrip却需要700MB甚至更多;其次RMVB的字幕为内嵌字幕,不像DVDrip那样要安装调试字幕外挂软件,有时还会出现乱码;更重要的是RMVB的影音播放只需一次性安装完解码器,以后无论影像还是音效都无需另行调试。而DVDrip却视频、音频解码一大堆,设置不当还会造成音画不同步、花屏失声等等毛病。


一、本地影像视频
                    ●AVI格式:它的英文全称为Audio Video
                  Interleaved,即音频视频交错格式。它于1992年被Microsoft公司推出,随Windows3.1一起被人们所认识和熟知。所谓“音频视频交错”,就是可以将视频和音频交织在一起进行同步播放。这种视频格式的优点是图像质量好,可以跨多个平台使用,其缺点是体积过于庞大,而且更加糟糕的是压缩标准不统一,最普遍的现象就是高版本Windows媒体播放器播放不了采用早期编码编辑的AVI格式视频,而低版本Windows媒体播放器又播放不了采用最新编码编辑的AVI格式视频,所以我们在进行一些AVI格式的视频播放时常会出现由于视频编码问题而造成的视频不能播放或即使能够播放,但存在不能调节播放进度和播放时只有声音没有图像等一些莫名其妙的问题,如果用户在进行AVI格式的视频播放时遇到了这些问题,可以通过下载相应的解码器来解决。
                    ●nAVI格式:nAVI是newAVI的缩写,是一个名为ShadowRealm的地下组织发展起来的一种新视频格式(与我们上面所说的AVI格式没有太大联系)。它是由Microsoft
                  ASF压缩算法的修改而来的,但是又与下面介绍的网络影像视频中的ASF视频格式有所区别,它以牺牲原有ASF视频文件视频“流”特性为代价而通过增加帧率来大幅提高ASF视频文件的清晰度。
                    ●DV-AVI格式:DV的英文全称是Digital Video
                  Format,是由索尼、松下、JVC等多家厂商联合提出的一种家用数字视频格式。目前非常流行的数码摄像机就是使用这种格式记录视频数据的。它可以通过电脑的IEEE
                  1394端口传输视频数据到电脑,也可以将电脑中编辑好的的视频数据回录到数码摄像机中。这种视频格式的文件扩展名一般是.avi,所以也叫DV-AVI格式。
                    ●MPEG格式:它的英文全称为Moving Picture Expert
                  Group,即运动图像专家组格式,家里常看的VCD、SVCD、DVD就是这种格式。MPEG文件格式是运动图像压缩算法的国际标准,它采用了有损压缩方法减少运动图像中的冗余信息,说的更加明白一点就是MPEG的压缩方法依据是相邻两幅画面绝大多数是相同的,把后续图像中和前面图像有冗余的部分去除,从而达到压缩的目的(其最大压缩比可达到200:1)。目前MPEG格式有三个压缩标准,分别是MPEG-1、MPEG-2、和MPEG-4,另外,MPEG-7与MPEG-21仍处在研发阶段。
                    MPEG-1:制定于1992年,它是针对1.5Mbps以下数据传输率的数字存储媒体运动图像及其伴音编码而设计的国际标准。也就是我们通常所见到的VCD制作格式。使用MPEG-1的压缩算法,可以把一部120分钟长的电影压缩到1.2GB左右大小。这种视频格式的文件扩展名包括.mpg、.mlv、.mpe、.mpeg及VCD光盘中的.dat文件等。
                    MPEG-2:制定于1994年,设计目标为高级工业标准的图像质量以及更高的传输率。这种格式主要应用在DVD/SVCD的制作(压缩)方面,同时在一些HDTV(高清晰电视广播)和一些高要求视频编辑、处理上面也有相当的应用。使用MPEG-2的压缩算法,可以把一部120分钟长的电影压缩到4到8GB的大小。这种视频格式的文件扩展名包括.mpg、.mpe、.mpeg、.m2v及DVD光盘上的.vob文件等。
                    MPEG-4:制定于1998年,MPEG-4是为了播放流式媒体的高质量视频而专门设计的,它可利用很窄的带度,通过帧重建技术,压缩和传输数据,以求使用最少的数据获得最佳的图像质量。目前MPEG-4最有吸引力的地方在于它能够保存接近于DVD画质的小体积视频文件。另外,这种文件格式还包含了以前MPEG压缩标准所不具备的比特率的可伸缩性、动画精灵、交互性甚至版权保护等一些特殊功能。这种视频格式的文件扩展名包括.asf、.mov和DivX
                  AVI等。
                    小提示:细心的用户一定注意到了,这中间怎么没有MPEG-3编码?实际上,大家熟悉的MP3就是采用的MPEG-3(MPEG
                  Layeur3)编码。
                  ●DivX格式:这是由MPEG-4衍生出的另一种视频编码(压缩)标准,也即我们通常所说的DVDrip格式,它采用了MPEG4的压缩算法同时又综合了MPEG-4与MP3各方面的技术,说白了就是使用DivX压缩技术对DVD盘片的视频图像进行高质量压缩,同时用MP3或AC3对音频进行压缩,然后再将视频与音频合成并加上相应的外挂字幕文件而形成的视频格式。其画质直逼DVD并且体积只有DVD的数分之一。这种编码对机器的要求也不高,所以DivX视频编码技术可以说是一种对DVD造成威胁最大的新生视频压缩格式,号称DVD杀手或DVD终结者。
                    ●MOV格式:美国Apple公司开发的一种视频格式,默认的播放器是苹果的QuickTimePlayer。具有较高的压缩比率和较完美的视频清晰度等特点,但是其最大的特点还是跨平台性,即不仅能支持MacOS,同样也能支持Windows系列。
                    二、网络影像视频
                    ●ASF格式:它的英文全称为Advanced Streaming format,它是微软为了和现在的Real
                  Player竞争而推出的一种视频格式,用户可以直接使用Windows自带的Windows Media
                  Player对其进行播放。由于它使用了MPEG-4的压缩算法,所以压缩率和图像的质量都很不错(高压缩率有利于视频流的传输,但图像质量肯定会的损失,所以有时候ASF格式的画面质量不如VCD是正常的)。
                    ●WMV格式:它的英文全称为Windows Media
                  Video,也是微软推出的一种采用独立编码方式并且可以直接在网上实时观看视频节目的文件压缩格式。WMV格式的主要优点包括:本地或网络回放、可扩充的媒体类型、部件下载、可伸缩的媒体类型、流的优先级化、多语言支持、环境独立性、丰富的流间关系以及扩展性等。
                    ●RM格式:Real Networks公司所制定的音频视频压缩规范称为Real
                  Media,用户可以使用RealPlayer或RealOne
                  Player对符合RealMedia技术规范的网络音频/视频资源进行实况转播并且RealMedia可以根据不同的网络传输速率制定出不同的压缩比率,从而实现在低速率的网络上进行影像数据实时传送和播放。这种格式的另一个特点是用户使用RealPlayer或RealOne
                  Player播放器可以在不下载音频/视频内容的条件下实现在线播放。另外,RM作为目前主流网络视频格式,它还可以通过其Real
                  Server服务器将其它格式的视频转换成RM视频并由Real
                  Server服务器负责对外发布和播放。RM和ASF格式可以说各有千秋,通常RM视频更柔和一些,而ASF视频则相对清晰一些。
                    ●RMVB格式:这是一种由RM视频格式升级延伸出的新视频格式,它的先进之处在于RMVB视频格式打破了原先RM格式那种平均压缩采样的方式,在保证平均压缩比的基础上合理利用比特率资源,就是说静止和动作场面少的画面场景采用较低的编码速率,这样可以留出更多的带宽空间,而这些带宽会在出现快速运动的画面场景时被利用。这样在保证了静止画面质量的前提下,大幅地提高了运动图像的画面质量,从而图像质量和文件大小之间就达到了微妙的平衡。另外,相对于DVDrip格式,RMVB视频也是有着较明显的优势,一部大小为700MB左右的DVD影片,如果将其转录成同样视听品质的RMVB格式,其个头最多也就400MB左右。不仅如此,这种视频格式还具有内置字幕和无需外挂插件支持等独特优点。要想播放这种视频格式,可以使用RealOne  Player2.0或RealPlayer8.0加RealVideo9.0以上版本的解码器形式进行播放。


世界上最快的VP9视频解码器 As before , I was very excited when Google released VP9 – for one, because I was one of the people involved in creating it back when I worked for Google (I no longer do). How good is it, and how much better can it be? To evaluate that question, Clément Bœsch and I set out to write a VP9 decoder from scratch for FFmpeg. The goals never changed from the original ffvp8 situation (community-developed, fast, free from the beginning). We also wanted to answer new questions: how does a well-written decoder compare, speed-wise, with a well-written decoder for other codecs? TLDR (see rest of post for details): as a codec, VP9 is quite impressive – it beats x264 in many cases. However, the encoder is slow, very slow. At higher speed settings, the quality gain melts away. This seems to be similar to what people report about HEVC (using e.g. x265 as an encoder). single-threaded decoding speed of libvpx isn’t great. FFvp9 beats it by 25-50% on a variety of machines. FFvp9 is somewhat slower than ffvp8, and somewhat faster than ffh264 decoding speed (for files encoded to matching SSIM scores). Multi-threading performance in libvpx is deplorable, it gains virtually nothing from its loopfilter-mt algorithm. FFvp9 multi-threading gains nearly as much as ffh264/ffvp8 multithreading, but there’s a cap (material-, settings- and resolution-dependent, we found it to be around 3 threads in one of our clips although it’s typically higher) after which further threads don’t cause any more gain. The codec itself To start, we did some tests on the encoder itself. The direct goal here was to identify bitrates at which encodings would give matching SSIM-scores so we could do same-quality decoder performance measurements. However, as such, it also allows us to compare encoder performance in itself. We used settings very close to recommended settings forVP8,VP9andx264, optimized for SSIM as a metric. As source clips, we chose Sintel (1920×1080 CGI content, source ), a 2-minute clip from Tears of Steel (1920×800 cinematic content, source ), and a 3-minute clip from Enter the Void (1920×818 high-grain/noise content,screenshot). For each, we encoded at various bitrates and plotted effective bitrate versus SSIM . sintel_ssimtos_ssimetv_ssim You’ll notice that in most cases, VP9 can indeed beat x264, but, there’s some big caveats: VP9 encoding (using libvpx) is horrendously slow – like, 50x slower than VP8/x264 encoding. This means that encoding a 3-minute 1080p clip takes several days on a high-end machine. Higher –cpu-used=X parameters make the quality gains melt away. libvpx’ VP9 encodes miss the target bitrates by a long shot (100% off) for the ETV clip, possibly because of our use of –aq-mode=1. libvpx tends to slowly crumble at higher bitrates for hard content – again, look at the ETV clip, where x264 shows some serious mature killer instinct at the high bitrate end of things. Overall, these results are promising, although the lack-of-speed is a serious issue. Decoder performance For decoding performance measurements, we chose (Sintel)500 (VP9), 1200 (VP8) and 700 (x264) kbps (SSIM=19.8); Tears of Steel4.0 (VP9), 7.9 (VP8) and 6.3 (x264) mbps (SSIM=19.2); and Enter the Void 9.7 (VP9), 16.6 (VP8) and 10.7 (x264) mbps (SSIM=16.2). We used FFmpeg to decode each of these files, either using the built-in decoder (to compare between codecs), or using libvpx-vp9 (to compare ffvp9 versus libvpx). Decoding time was measured in seconds using “time ffmpeg -threads 1 [-c:v libvpx-vp9] -i $file -f null -v 0 -nostats – 2>&1 | grep user”, with this FFmpeg and this libvpx revision (downloaded on Feb 20th, 2014). sintel_archs tos_archsetv_archs A few notes on ffvp9 vs. libvpx-vp9 performance: ffvp9 beats libvpx consistently by 25-50%. In practice, this means that typical middle- to high-end hardware will be able to playback 4K content using ffvp9, but not using libvpx. Low-end hardware will struggle to playback even 720p content using libvpx (but do so fine using ffvp9). on Haswell, the difference is significantly smaller than on sandybridge, likely because libvpx has some AVX2 optimizations (e.g. for MC and loop filtering), whereas ffvp9 doesn’t have that yet; this means this difference might grow over time as ffvp9 gets AVX2 optimizations also. on the Atom, the differences are significantly smaller than on other systems; the reason for this is likely that we haven’t done any significant work on Atom-performance yet. Atom has unusually large latencies between GPRs and XMM registers, which means you need to take special care in ordering your instructions to prevent unnecessary halts – we haven’t done anything in that area yet (for ffvp9). Some users may find that ffvp9 is a lot slower than advertised on 32bit; this is correct, most of our SIMD only works on 64bit machines. If you have 32bit software, port it to 64bit. Can’t port it? Ditch it. Nobody owns 32bit x86 hardware anymore these days. So how does VP9 decoding performance compare to that of other codecs? There’s basically two ways to measure this: same-bitrate (e.g. a 500kbps VP8 file vs. a 500kbps VP9 file, where the VP9 file likely looks much better), or same-quality (e.g. a VP8 file with SSIM=19.2 vs. a VP9 file with SSIM=19.2, where the VP9 file likely has a much lower bitrate). We did same-quality measurements, and found: ffvp9 tends to beat ffh264 by a tiny bit (10%), except on Atom (which is likely because ffh264 has received more Atom-specific attention than ffvp9). ffvp9 tends to be quite a bit slower than ffvp8 (15%), although the massive bitrate differences in Enter the Void actually makes it win for that clip (by about 15%, except on Atom). Given that Google promised VP9 would be no more than 40% more complex than VP8, it seems they kept that promise. we did some same-bitrate comparisons, and found that x264 and ffvp9 are essentially identical in that scenario (with x264 having slightly lower SSIM scores); vp8 tends to be about 50% faster, but looks significantly worse. Multithreading One of the killer-features in FFmpeg is frame-level multithreading, which allows multiple cores to decode different video frames in parallel. Libvpx also supports multithreading. So which is better?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值