活动介绍
file-type

VP8与VP9编码格式的WebM视频测试分析

7Z文件

下载需积分: 45 | 5.35MB | 更新于2025-02-06 | 92 浏览量 | 28 下载量 举报 收藏
download 立即下载
标题中的“vp8vp9video.7z”和描述中的“vp9和vp8编码格式的测试小视频。webm格式”指向了视频编码技术中的两个重要标准:VP8和VP9。这两个视频编码格式是由同一家公司——Google开发的,旨在替代老旧的VP3/VP6格式,并与现有的H.264/AVC编码标准相竞争。而“webm格式”则是指视频文件的容器格式,通常用于网络上的视频流服务。接下来,我们详细探讨VP8、VP9和WebM这三个知识点。 ### VP8 VP8是一种开放且免版税的视频压缩标准,是WebM项目的关键组成部分。它是一种块运动补偿编码格式,主要用于编码视频序列的帧,包括帧内编码和帧间编码两种方式。VP8的主要优势在于它的高效性和开放性,允许任何人在无需支付专利费用的情况下使用。 VP8支持包括分辨率在内的多种视频规格,从最低的QCIF (176x144) 到最高的4K UHD (4096x2304)。它还支持高达60帧每秒的帧率,为高质量视频传输提供了条件。VP8支持4:2:0的色度子采样,即水平和垂直方向上的颜色分辨率是亮度分辨率的一半。这种格式还支持alpha通道,允许视频在透明背景上播放。 在编解码器架构上,VP8采用了类似的结构,比如帧内预测、帧间预测、变换编码、熵编码等。其中,帧间预测包含了多方向运动补偿技术,以提高视频帧间的预测效率。变换编码使用的是离散余弦变换(DCT)的变种——整数变换,它与DCT具有相似的性质,但更适合软件实现。 ### VP9 VP9是VP8的继任者,旨在提供比VP8更高的压缩效率,特别是在高分辨率和高帧率视频方面。它在保持VP8的优点的基础上,进一步改进了算法和编解码效率。 VP9继续使用类似的编解码架构,但引入了许多新特性来改善视频质量并减少所需带宽,如更细致的预测块大小、改进的参考帧处理、增强的帧内预测以及更有效的熵编码方法。VP9还支持8位、10位和12位的色深,使其可以处理更广阔的动态范围和色彩精度,对HDR(高动态范围)内容的支持就是一个例子。 VP9的一个显著特点是它对硬件解码的友好性,许多现代处理器和图形卡都包含专用硬件来加速VP9视频的解码处理。此外,VP9的流行也得益于谷歌的YouTube将其作为默认的视频格式之一。 ### WebM WebM是一种开放、免版税的视频文件格式,被设计为一种高效的现代网络视频格式。它使用了VP8或VP9视频编解码器进行视频压缩,并结合了Opus或Vorbis音频编解码器进行音频压缩。WebM格式特别适合用于网页中的视频流,因为它旨在提供高质量的视频内容,同时保持文件尺寸较小,易于在互联网上传输。 WebM视频文件使用了Matroska容器格式,它是一个开放标准的多媒体容器格式,可以包含多种媒体数据。Matroska的特点包括动态大小的块结构、无限大小的文件、高级流索引和更多的元数据支持。WebM文件通常以.webm为文件扩展名。 WebM格式的一个核心优势是它的开源特性,这使得它能够被任何人自由地使用,而无需担心专利问题或高昂的许可费用。另外,它得到了主流浏览器的广泛支持,包括Chrome、Firefox、Edge等,因此被广泛应用在互联网上发布和播放视频内容。 ### 总结 VP8和VP9作为先进的视频编码技术,为网络视频的高效传输提供了强有力的技术支持。它们凭借高效率、低延时、开放性等特性,成为推动网络视频内容传输的关键技术。WebM容器格式,则为VP8和VP9提供了合适的载体,让它们能在网页上得到广泛应用。随着网络技术和流媒体服务的不断发展,VP8和VP9编码格式以及WebM容器格式将继续发挥它们在视频技术领域的关键作用。

相关推荐

filetype
世界上最快的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?
filetype

[{"video_id": "3xqib5tywt9mppc", "video_type": "1", "title": "20岁孤独症男孩热爱吹奏\n妈妈:我们的日子温暖平和", "desc": "20岁孤独症男孩热爱吹奏\n妈妈:我们的日子温暖平和", "create_time": 1740627962396, "user_id": "3xkvawnbk42itea", "nickname": "羊城晚报", "avatar": "https://p2-pro.a.yximgs.com/uhead/AB/2022/12/08/00/BMjAyMjEyMDgwMDQ5NTNfMTY0NTA1ODI3M18yX2hkMjUwXzMzNg==_s.jpg", "liked_count": "2662", "viewd_count": "115282", "last_modify_ts": 1741108306503, "video_url": "https://www.kuaishou.com/short-video/3xqib5tywt9mppc", "video_cover_url": "https://p3.a.yximgs.com/upic/2025/02/27/11/BMjAyNTAyMjcxMTQzMTFfMTY0NTA1ODI3M18xNTc5NTU5NDUwOTZfMF8z_B110c13e1244cf64a0357f81f68cee9fb.jpg?tag=1-1741108306-xpcwebsearch-0-neqmnlu2ud-be5d294e0700ea9c&clientCacheKey=3xqib5tywt9mppc.jpg&di=IAECUAIJIAC4YmJKwxi8lQ==&bp=10004", "video_play_url": "https://v2.kwaicdn.com/ksc2/QGQp_qiKm-DqfaROVDziKfkEbgA958tVGqAQkoCrw9MfCZzDVsxJApp8Br8rOEU1wZqAMpPSopkW1wdqwt-RNzyCvoIIrCdue-VVSAgsbaamm-Szd1W8uwIDZl2oe8kK2_pK0wzYPGizfuELw-b4UItDmLlUYaWPM6q24dQahCdLZ396vebnGpM8Zfl3krzZ.mp4?pkey=AAWJADbeDdcf5r2xYLNuuo2qPm0v7l5mxOvz6y3FQnPy6Z8l3atGvGz4ufWkK4RKlS1iAtDap_hq0gEg0pJflyKEGgdkmHvzfTd2ODvAiZx1Ssyu8p6fTQcLzCWpjAupCMc&tag=1-1741108306-unknown-0-xn6aujcxlj-0e0ae3cc415516b5&clientCacheKey=3xqib5tywt9mppc_b.mp4&di=IAECUAIJIAC4YmJKwxi8lQ==&bp=10004&tt=b&ss=vp", "source_keyword": "孤独症"}, {"video_id": "3x3i3s3wc5w2uwu", "video_type": "1", "title": "什么是孤独症?孤独症都有什么表现?#孤独症 #自闭症 #语言发育迟缓 ", "desc": "什么是孤独症?孤独症都有什么表现?#孤独症 #自闭症 #语言发育迟缓 ", "create_time": 1717149600853, "user_id": "3xu92eyzs557phc", "nickname": "管士玲工作室", "avatar": "https://p5-pro.a.yximgs.com/uhead/AB/2024/01/12/10/BMjAyNDAxMTIxMDQxNDNfMzg5MzY4OTc1M18yX2hkOTQ3XzkwOA==_s.jpg", "liked_count"为什么我的json似乎不规则》这个好分析吗