WebM Exciting New Video Standard with VP8, Vorbis, Matroska

[Disabled]

Originally Posted by zambelli

In fact, it pays more than most since it ships quite a few decoders...

Thats wrong. H264 royalties are capped at (I guess) 5 Million $, so Microsoft pays less per license then anyone else (unless youre under 100000 shipped units and its free).

[mariush]

Originally Posted by zambelli

Microsoft pays VC-1 and H.264 royalties just like everyone else. In fact, it pays more than most since it ships quite a few decoders (i.e. Windows, Xbox, Zune, Silverlight, etc.).

Of course they pay just like anyone else - well maybe not like everyone else because I'm sure they get a blanket/volume/negociated license.

But being one of the largest companies with patents in the MPEG-LA patent pools, they also get some money back from licensing "at the end of the day".

Just by looking at the list of patents in the patent pool for h264 alone, Microsoft has 4 pages of patents there:
http://www.mpegla.com/main/programs/...s/avc-att1.pdf

Anyway, this is getting to be a bit off topic...

ps. Judging by the signature in the footer of your post, I think you could at least mention that you work for Microsoft or are involved with them.

[IgorC]

Originally Posted by CruNcher

Yeah though i find it bad news that Microsoft bought Skype
Skype always drove the VPx for low latency Videoconferencing and im not sure if Microsoft will continue that (actually it would be pretty strange if they would) on the other side with websockets nowadays skypes videoconferencing doesn't matter that much anymore.

VP8 and Skype's speech codec (SILK) are both open source. No big threat.

Also, Skype and Xiph have joined their codecs into new open source one with high quality and low delay. Opus.
It's a hybrid codec: SILK (low bitrate) + CELT (high quality MDCT encoder).
It performs very good now.
See the results of the last comparison in my signature.

[cid_xvid]

Originally Posted by IgorC

VP8 and Skype's speech codec (SILK) are both open source. No big threat.

Also, Skype and Xiph have joined their codecs into new open source one with high quality and low delay. Opus.
It's a hybrid codec: SILK (low bitrate) + CELT (high quality MDCT encoder).
It performs very good now.
See the results of the last comparison in my signature.

Skype has been adquired by Microsoft. I am afraid of the future of Opus encoder.

[iwod]

It is interesting that Opus is THAT good while free of patents. And yet we cant say the same for Video Codec.

[IgorC]

Originally Posted by iwod

It is interesting that Opus is THAT good while free of patents. And yet we cant say the same for Video Codec.

There is very high quality and open source H.264 encoder (x264).While there is no such encoder for AAC standard.

That is one of the reasons why Opus had chance to do well comparing to commercial AAC encoders. Those AAC encoders aren't bad but it's often to see that open source implementations perform generally better.

[IgorC]

VP8 Codec SDK "Cayuga" Released

http://blog.webmproject.org/

Also now VP8 is used in One-to-One Skype calls.

[GoWebM]

Today we're making available "Cayuga," the third named release of the VP8 Codec SDK (libvpx). Note that the VP8 format definition has not changed, only the SDK. You can download the Cayuga libvpx snapshot (version 0.9.7) from the WebM Project Downloads page or clone it from our Git repository.

As promised, for Cayuga we targeted more areas for encoder speed improvements. Using our previous release ("Bali") as a benchmark, we’ve seen the following VP8 encoder improvements on x86 processors.

+11.5% "Best" mode (at speed 0)
+21.5% "Good" mode (at speed 0)
+22.5% "Real-time" mode (at speed 6, a typical speed for videoconferencing applications)

We also compared the encoder performance of "Cayuga" to our first named release ("Aylesbury") release and got the following results:

+35% "Best" mode (at speed 0)
+75% "Good" mode (at speed 0)
+52% "Real-time" mode (at speed 6)

We saw the following improvements on ARM processors:

On ARM Cortex A9 with Neon extensions, real-time encoding of video telephony content is 35% faster than Bali on single core and 48% faster on multi-core.

On the NVIDIA Tegra2 platform, real time encoding is 40% faster than Bali.

For more technical readers, here are some detailed improvements we made in the libvpx Cayuga encoder:

Improved the datarate control in one-pass realtime compression.

Improved one-pass variable bitrate (VBR) visual quality by average ~7% across a large collection of videos.

Improved video conferencing user experience through error concealment, a feature that produces high visual quality frames even under conditions of substantial packet loss.

Improved the ARM v6 and v7 encoders and decoders through greater use of SIMD features and strong use of cache prefetching.

Thanks to everyone who worked on Cayuga, and welcome to our eleven new contributors:

Alok Ahuja
Alexis Ballier
Ronald Bultje
Rafael Ávila de Espíndola
Ralph Giles
Stefan Holmer
Mike Hommey
Taekhyun Kim
Aron Rosenberg
Joshua Bleecher Snyder
Thijs Vermeir

Source: VP8 Codec SDK "Cayuga" Released

[Sirber]

Originally Posted by GoWebM

Any Video Converter Version 3.23 (released on May 11, 2011 ), add WebM as supported input and output video format.

Then:

* Non-commercial WebM Tools (Windows): Miro Video Converter, XMedia Recode, Firefogg, MediaCoder.

* Commercial WebM Tools (No cloud soft.): Bigasoft Total Video Converter, Any Video Converter.

Do you know of others?




Sorry my english

Bencos using ffmpeg. http://www.detritus.qc.ca

[GoWebM]

Starting today, “Cloudberry”, the third release of the Hantro H1 VP8 hardware encoder, is available at no cost through the WebM Project hardware page. Partners having already signed the online licensing agreement will receive an automatic update.

Moving along with our mission statement - creating the world’s best real-time video encoder - we’re again one step closer to our goal thanks to Cloudberry’s substantial quality gains. In PSNR comparisons, Cloudberry performs on average 1.27 dB better than our initial Anthill release, which we launched less than five months ago. It also beats the previous Blueberry release by 0.45 dB, with comparable increases using the SSIM quality metric.

We’ve also bridged an important milestone: Cloudberry is able to encode high-quality 720p video (video teleconference use cases) at well under 1 Mbps, as shown in the following chart.




The optimized Cloudberry control software is backwards compatible and will also benefit chips with the Blueberry hardware inside them, providing 0.08 dB average PSNR increase without any hardware changes required.

In our next release, we are focusing on further software-based quality improvements especially related to multipass encoding and optimal usage of VP8 Golden frames - both of which will benefit SoCs that use either Blueberry or Cloudberry. On the hardware side, we also have numerous improvements in mind, such as further optimizing the macroblock mode selection. This fourth release is planned to be available at the end of Q3.

The VP8 H1 encoder IP has been licensed already to nearly 40 semiconductor companies through the WebM Project, and more requests are pouring in. For licensing details about the H1, see our hardware page. Our reseller partner Verisilicon also licenses Cloudberry as a part of the multiformat Hantro H1 encoder.


For more technical readers, here is the list of new features in Cloudberry:

- RD-optimized quantization
- Improved intra/inter macroblock mode selection
- Improved inter macroblock RD functions
- Improved intra macroblock mode selection
- More macroblock level coding information returned to software (enables effective multipass optimizations)

The following curves show PSNR quality metrics for a 720p video call, comparing the H1 Cloudberry release to previous H1 releases and to the libvpx Bali software SDK release. As a point of interest, the Cloudberry encoder performs similarly to libvpx’s “-rt -cpu-used=-5” setting, which is equivalent to what a WebRTC based application can achieve on the fastest PCs.

Source: Third Generation VP8 Hardware Encoder IP “Cloudberry” Released

[CruNcher]

Duclair is out
http://blog.webmproject.org/2012/01/...-released.html

[smok3]

Originally Posted by CruNcher

Duclair is out
http://blog.webmproject.org/2012/01/...-released.html

trying to compile git, but getting this at ./configure:
http://pastebin.com/NQWuG6v6
any clues?

edit: tarball did compile, does this look right?;

Included encoders:

    vp8    - WebM Project VP8 Encoder v0.9.7-p1-62-g2aa4085

How would a best, good, fast cq based ffmpeg command line look like?

[nakTT]

I have tried this WebM to encode my video. Unfortunately at this stage it still lagging (in video quality - my test was at 500kbps) way behind x264. Hope it will progress fast for the better.

[Nintendo Maniac 64]

Am I crazy, or is YouTube's 480p config for WebM BETTER quality than their h.264 one? I used this video as my test case:
http://www.youtube.com/watch?v=vnc-c2SCz_0

Even crazier is that the 480p FLV is 48.7MB while the 480p WebM is 39.7MB! O_o (and apparently the WebM versions even have better audio quality as well)


Also interesting, if you don't have a hardware h.264 decoder, WebM uses less CPU. This is particularly noticable with older PCs, specifically YouTube's 720p WebM files can actually run well on a lowly 2GHz Pentium 4 (that is, assuming you're playing the file in a dedicated media player) while h.264 is a stutter-fest.

[Midzuki]

Originally Posted by Nintendo Maniac 64

Am I crazy, or is YouTube's 480p config for WebM BETTER quality than their h.264 one? I used this video as my test case:
http://www.youtube.com/watch?v=vnc-c2SCz_0

Even crazier is that the 480p FLV is 48.7MB while the 480p WebM is 39.7MB! O_o (and apparently the WebM versions even have better audio quality as well)


Also interesting, if you don't have a hardware h.264 decoder, WebM uses less CPU. This is particularly noticable with older PCs, specifically YouTube's 720p WebM files can actually run well on a lowly 2GHz Pentium 4 (that is, assuming you're playing the file in a dedicated media player) while h.264 is a stutter-fest.

That looks and sounds incredibly weird O_o

So I'd like to know if:

1) which VP8 encoder has become faster && more-efficient lately?

2) which VP8 decoder has finally become decently-fast?

Three months ago (IIRC), last time I tried a WebM file from YouTube on my Pentium-4 through Opera 11.50, the playback dropped tons of frames, and the audio sync was simply impossible.

[Nintendo Maniac 64]

Originally Posted by Midzuki

That looks and sounds incredibly weird O_o

What is this "that" you're referring to? Do you mean the video, the post, the WebM having better quality, or something else?

(note that I do not think I can answer your questions - I specialize in audio, and definitely not video)

[dapperdan]

Looks like Google is ready to go public with work on what will become VP9 (or VP8+, it's not clear to me how radical they intend to be):

https://gerrit.chromium.org/gerrit/#change,17840

[vivan]

Originally Posted by Nintendo Maniac 64

Even crazier is that the 480p FLV is 48.7MB while the 480p WebM is 39.7MB! O_o

Originally Posted by Nintendo Maniac 64

config for WebM BETTER quality than their h.264 one?

quality? I don't think so. http://www.check2pic.ru/compare/12266/

In other cases youtube gives webm higher bitrate. Like this: http://www.youtube.com/watch?v=APyr48GACzc
21.6 MB for 1080p mp4, 13.6 MB for 720p mp4... And 33.0 MB for 720p webm. Lol.

[Midzuki]

Originally Posted by Nintendo Maniac 64

What is this "that" you're referring to? Do you mean the video, the post, the WebM having better quality, or something else?

All of the above, including the "something else".

[Nintendo Maniac 64]

Originally Posted by vivan

quality? I don't think so. http://www.check2pic.ru/compare/12266/

In other cases youtube gives webm higher bitrate. Like this: http://www.youtube.com/watch?v=APyr48GACzc
21.6 MB for 1080p mp4, 13.6 MB for 720p mp4... And 33.0 MB for 720p webm. Lol.

I said at 480p. From what it looks like, the situation is reversed, with WebM having better video, audio, AND a smaller filesize. (unless I AM crazy. :P)

Note that, in particular, 480p h.264 uses 'Main' profile rather than 'High'.

EDIT: Take a look at these two images - I can't read Russian, so I can't make a comparison-thingy like you did (note that both images have 200% nearest neighbor applied to make them easier to see):
WebM
H.264

It would seem that it's not as clear-cut as it is for 720p. The HUD, sky, and building on the left looks better on h.264, but the water and track looks better on WebM. The spires in the distance are a toss-up to me.