H.265和VP9的区别和应用

在这里插入图片描述

VP9和H.265(也称为HEVC, High Efficiency Video Coding)是两种现代的视频编码标准,它们各自有不同的设计目标、技术特性和应用场景。以下是它们之间的一些主要区别和对比:

技术和标准方面

1. 开发背景和标准化

VP9

开发者:由Google开发。

标准化:没有通过正式的国际标准化机构,但得到了广泛支持,特别是在网络视频流媒体应用中。

H.265 (HEVC)

开发者:由ITU-T VCEG(Video Coding Experts Group)和ISO/IEC MPEG(Moving Picture Experts Group)共同开发。

标准化:被国际标准化机构(ITU和ISO)认可,是正式的国际标准。

2. 编码效率

VP9

在高压缩率和高质量之间提供了较好的平衡,适合互联网视频流媒体。

相比VP8,其编码效率提高了50%左右。

H.265 (HEVC)

比H.264(其前身)效率高出约50%。

特别适合高分辨率视频(如4K、8K),在保持高质量的同时,显著降低了比特率。

3. 压缩算法

VP9

使用了较为复杂的预测和变换技术,包括基于块的预测、帧间预测等。

采用了树形分割的块结构,可以灵活调整不同区域的编码参数。

H.265 (HEVC)

使用了先进的分层编码结构,包括编码树单元(CTU),支持更大的块大小和更复杂的块分割。

采用了更高效的帧内预测和帧间预测技术,提高了压缩效率。

4. 编码复杂度

VP9

相对H.265,VP9的编码和解码复杂度稍低,因此在某些硬件实现中可能更节省资源。

更适合网络环境和嵌入式系统中使用。

H.265 (HEVC)

编码和解码复杂度较高,对计算资源要求更高。

需要专门的硬件加速支持来实现实时编码和解码。

应用和兼容性

1. 使用场景

VP9

广泛应用于视频流媒体平台。

得到了Google Chrome和其他一些浏览器的支持,特别适合Web视频播放。

H.265 (HEVC)

广泛应用于电视广播、蓝光光盘等高分辨率视频存储和传输。

在视频会议、IPTV等需要高压缩率和高画质的场景中使用。

2. 硬件支持

VP9

得到了较多现代设备的支持,如智能手机、平板电脑和电视盒等。

一些新型的SoC(系统级芯片)都集成了对VP9的硬件加速。

H.265 (HEVC)

被广泛集成到现代的硬件中,包括智能电视、蓝光播放器和高端移动设备。

由于其高复杂度,对硬件要求较高,因此需要专用的硬件解码器支持。

3. 专利和许可

VP9

采用了开放的许可方式,Google提供免费使用,因此没有专利费用。

被认为是开源社区和互联网公司友好的选择。

H.265 (HEVC)

由于涉及多家公司和机构的专利,使用H.265可能需要支付专利费。

专利池管理(如HEVC Advance和MPEG LA)负责专利授权和费用管理。

总结

性能对比:

H.265在高分辨率视频编码方面表现突出,尤其适合需要高效压缩的应用。

VP9在互联网视频流媒体领域具有优势,编码复杂度较低,适合在线内容分发。

应用场景:

如果需要广泛兼容性和高压缩效率,H.265是更好的选择。

对于网络视频和需要避免专利费用的场景,VP9则是理想的选择。

硬件和软件支持:

H.265由于其复杂度,更多依赖于硬件加速。

VP9在现代设备上也得到了广泛支持,特别是在移动设备和浏览器中。

每种编码标准都有其特定的优势和应用场景,选择合适的标准需要根据具体的需求、设备支持和成本考虑来决定。

世界上最快的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
发出的红包

打赏作者

空间机器人

您的鼓励是我创作最大的动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值