A Blog From Behind the Trenches

As with all new software it will continue to improve. They start out buggy and get improved with testing. Plus user testing will help out with performance bugs, as most people do not have the same hardware

All you have to do is look at any piece of software in its early stages, it is buggy and may not have good performance or quality, it takes time to improve

On my Mac I am use http://www.xiph.org/quicktime/ for .ogg in quicktime
there are others here: http://www.xiph.org/downloads/ for other programs (Wikipedia even use .ogg on some of the media files http://en.wikipedia.org/wiki/Ogg#File_format )

Originally posted by mgillespie:

I trust Google to have spent wisely (as they have always shown in the past), over the opinion of someone with a heavily vested interest in H.264.

Nail. On. Head.

Seems like you skipped the part where VP8 is full of potential patent-encumbered code. I know you probably don't want to touch on this subject if you are not a lawyer or have deep understanding on exactly what is patented or not. But it still remains an issue.


H.264 Baseline profile does not compress as well as Main or High. Better compression saves bandwidth but requires more CPU and hence more power. Bandwidth is far from cheap these days and they could use decoder ASIC to improve decoding and not use as much power on it. I don't see why you should limit the web to some baseline inferior standard.

Seems like you skipped the part where VP8 is full of potential patent-encumbered code.

'Looks like what we did too' is not 'patent-encumbered code'.

Originally posted by saivert:

Seems like you skipped the part where VP8 is full of potential patent-encumbered code.

Seems we have yet another FUD-spewing troll.

To counter the FUD-spewing troll.

Google backs open codec against patent trolls

Originally posted by saivert:

H.264 Baseline profile does not compress as well as Main or High.

H264 baseline is all you can use if you want to reach devices and mobile phones. Fail.

Originally posted by prd3:

H264 baseline is all you can use if you want to reach devices and mobile phones. Fail.

I don't think that's the point. Why should a new codec that is meant to take a big a role in the future of web video be aimed so low? Do you think a codec similar to h264 baseline would look as good in, say, 5 years? I'm all in favor of the open web and vp8, but that's something to consider.
Peace

Originally posted by Kireta:

I don't think that's the point. Why should a new codec that is meant to take a big a role in the future of web video be aimed so low? Do you think a codec similar to h264 baseline would look as good in, say, 5 years? I'm all in favor of the open web and vp8, but that's something to consider.

If something much better is available in five years we can consider switching then?

Originally posted by Frenzie:

If something much better is available in five years we can consider switching then?

Codec that gives excellent quality is already available.

Originally posted by Kireta:

I don't think that's the point. Why should a new codec that is meant to take a big a role in the future of web video be aimed so low? Do you think a codec similar to h264 baseline would look as good in, say, 5 years? I'm all in favor of the open web and vp8, but that's something to consider.

How about reading the blog post before commenting? It has been clearly pointed out that WebM is better than H264 baseline, which is what you need to use anyway if you want to go for H264. And while x264 is already mature and optimized, WebM is completely fresh and has a lot of optimization remaining.

And Google is going to allow improvements to WebM in the future, so it's only going to get better and better. So if your argument is "they will start using something different from H264 baseline", then we might as well go with an improved WebM.

Why should we aim equally low low and accept H264 if we can't accept WebM? You are contradicting yourself.

Originally posted by zbgoswvhvsq:

Codec that gives excellent quality is already available.

Yes, WebM. For H264, baseline is the only thing you can realistically use today. If you are suggesting other H264 profiles than baseline, then all that hardware will have to change, and then we might as well go for the improved WebM instead.

A correction: VP8 has been in development for years. It isn't exactly a "new" or "raw" codec. It's just that nobody has actually been able to get their hands on it until now. Also when he said it's set in stone he meant that the bitstream/spec was frozen, which it is. The implementations can be improved but the basic codec itself cannot be changed without extensions to the bitstream (like h.263+ is an extension of h.263). Changing the bitstream tends to break backwards compatibility though.

Haavard, what do you think about the licensing of WebM? Why doesn't Google protect end users from patent lawsuits? Even better if the people in charge of video at Opera could respond to that.

Originally posted by prd3:

Google backs open codec against patent trolls

What? google grants the assorted own patents for free, it doesnt protect against patents that arent its own.
the patent clause only makes sure the FOSS community doesnt abuse the granted patents themself. To quote the article you linked yourself: "Basically, it helps ensure that the community that adopts this can't claim patent infringement."

Originally posted by prd3:

Yes, WebM. For H264, baseline is the only thing you can realistically use today. If you are suggesting other H264 profiles than baseline, then all that hardware will have to change, and then we might as well go for the improved WebM instead.

Some mobile devices only understand Baseline, and are limited to resolutions of 640x480. With higher resolutions you also need better profiles (Main or High) and devices which can use the higher res also support Main Profile in hardware. And thats still a ton of devices (every net-/lap-/desktop IGP/GPU with H264 support, ipad, psp..).

And if we go with an "improved" WebM, why not wait 2 years for h265 awell

Originally posted by Haavard:

Despite claims to the contrary, The WebM format is not set in stone

WebM is the container, sure if you allow H264 as codec it will improve =)
But VP8 is strictly locked down, with google not even accepting fixes for discovered bugs. go back to the linked analysis and find "Practical problems" in the page, there is an update.
I dont understand why google cant wait for a couple independent decoders to make sure the spec is clean enough before finalizing it.

prd3, I think it would be incorrect to say that VP8 gives excellent quality. "Good enough" is right term (w/o paying attention to VP* blur).

Does anyone know how to mux raw ivf streams into mkv (webm)?

Originally posted by Astrophizz:

The implementations can be improved but the basic codec itself cannot be changed without extensions to the bitstream (like h.263+ is an extension of h.263). Changing the bitstream tends to break backwards compatibility though.

But they keep a research group, dedicated to improving the VP8 codec where they can. The decision to make the current spec final was probably because wanted it out in a public testing quickly.
Most likely they will, in a year, or a few years, announce a WebM2, which should solve most of these problems

Originally posted by Astrophizz:

A correction: VP8 has been in development for years. It isn't exactly a "new" or "raw" codec.

WebM is. Also, VP8 clearly is RAW if you look at the specs and all that. Huge room for improvement.

The implementations can be improved but the basic codec itself cannot be changed without extensions to the bitstream (like h.263+ is an extension of h.263).

And Google is open to doing exactly that.

Originally posted by NRage:

Some mobile devices only understand Baseline

SOME! Baseline is the only thing you can use if you want to reach beyond the PC.

Originally posted by NRage:

WebM is the container

No, WebM is the video format, including container, video and audio.

Originally posted by NRage:

But VP8 is strictly locked down, with google not even accepting fixes for discovered bugs. go back to the linked analysis and find "Practical problems" in the page, there is an update.

You are WRONG. The update links to the FAQ which CLEARLY explains that there's a new dev branch for improvements.

Originally posted by zbgoswvhvsq:

prd3, I think it would be incorrect to say that VP8 gives excellent quality. "Good enough" is right term (w/o paying attention to VP* blur).

No, it's BETTER than H264 baseline, which is all that matters right now. H264 baseline is the only one with widespread hardware support.

Originally posted by prd3:

No, it's BETTER than H264 baseline, which is all that matters right now. H264 baseline is the only one with widespread hardware support.

When On2 was developing their encoders they decided to prefer PSNR score over human visual perception. VP8 scores better than h264 baseline as far as PSNR goes, but PSNR is not a good judge of psycho-visual effects and tends to prefer blurrier pictures. That's what zbgoswvhvsq was describing.

Originally posted by prd3:

You are WRONG. The update links to the FAQ which CLEARLY explains that there's a new dev branch for improvements.

prd3, that page says that the spec is indeed FINAL. From http://www.webmproject.org/about/faq/
"The VP8 and WebM specifications as released on May 19th, 2010 are final. We believe that the code and tools can evolve and improve for many years without requiring changes to the core specifications."
The spec is LOCKED DOWN and if they were to change it in a few years they would have to require everyone to get a new decoder. It would be like changing the video format and that's why they state that it require significant improvements. Beyond that, they're defining the spec through a software implementation which is a little baffling because it makes it much more difficult to know if you're making a correct VP8 encoder. It leaves a lot of grey area.

Add onto all that that since there are bugs in the spec code, the spec REQUIRES these bugs to be present in future encoders. Someone already submitted a decoder patch to fix artifacts that show up in video but it required fixing a bug in the encoder, so they reverted the patch!
05:28 < derf> Gumboot: You’ll be disappointed to know they got the loop filter ordering wrong again.
05:29 < derf> Dark_Shikari: They ordered it such that you have to process each macroblock in full before processing the next one.

<derf> gmaxwell: It survives it with a patch that causes artifacts because their encoder doesn’t clamp MVs properly.
<gmaxwell> ::cries::
<derf> So they reverted my decoder patch, instead of fixing the encoder.
<gmaxwell> “but we have many files encoded with this!”
<gmaxwell> so great.. single implementation and it depends on its own bugs.

Originally posted by Astrophizz:

That's what zbgoswvhvsq was describing.

And what I'm describing is that WebM is BETTER than H264 baseline.

Originally posted by Astrophizz:

prd3, that page says that the spec is indeed FINAL.

Yes, but they are using a different branch for FUTURE IMPROVEMENTS. If something is really needed, it will be added.

Originally posted by Astrophizz:

“but we have many files encoded with this!”

Except they said that they wouldn't be opposed to recoding them, they just didn't have time before the announcement.

Quit spreading anti-anything-not-H264 FUD already.

What does "better than H.264 baseline" mean for you? Also, it's not that recoding the files with the solution would take time, they would have to change the VP8 standard. The fact that they aren't willing to fix bugs because they've already committed to this path is an issue. I'm not anti-anything-not-H.264. I think WebM and VP8 could be good but from my perspective it has been mishandled. That's all.

Originally posted by prd3:

No, it's BETTER than H264 baseline, which is all that matters right now. H264 baseline is the only one with widespread hardware support.

It has the potential to be better, the current encoder "right now" isnt. It likely will mature in 1-2 years time to fulfill its potential.

Originally posted by prd3:

No, WebM is the video format, including container, video and audio.

From the official FAQ:
"What is WebM?

WebM is an open, royalty-free media file format designed for the web. WebM files consist of video streams compressed with the VP8 video codec and audio streams compressed with the Vorbis audio codec. The WebM file structure is based on the Matroska media container."

WebM is a Matroska container with tons of things forbidden (particularly other video/audio codecs than the 2 mentioned)

Originally posted by prd3:

Yes, but they are using a different branch for FUTURE IMPROVEMENTS. If something is really needed, it will be added.

And that would be a different codec (call it VP9 or VP8+) if it doesnt adhere to the VP8 specs which already is known to contain bugs and requires all en-/decoders to implement them.

Originally posted by NRage:

It has the potential to be better, the current encoder "right now" isnt.

It is.

Originally posted by NRage:

The WebM file structure is based on the Matroska media container.

Your emphasis is wrong. You should have bolded FILE STRUCTURE. The FILE STRUCTURE is based on Matroska. WebM is still the container+codecs.

Originally posted by NRage:

And that would be a different codec (call it VP9 or VP8+) if it doesnt adhere to the VP8 specs which already is known to contain bugs and requires all en-/decoders to implement them.

Actually, Google said they were open to re-encoding all their stuff after the initial launch.

First of all, you can't transcode from a lossy and particularly modern codec to a different lossy codec. It is possible but the quality degration makes it real bad. It is like saving a jpeg dozen times after changing it.
Solution: Use the raw/almost raw (for example, betacam digital, consumer dv) to re-encode to the nre format. While it is amazingly pricey for a content provider, it is possible. The impossible is consumer videos already uploaded to youtube.
Fot developers, it is like converting opera from C to BASIC and blindly reconverting to C.
Hating patents is one thing, ignoring reality is another. Haavard also confuses Google with Opera. Google is the company who abandoned all ppc mac users in chrome while Opera does ship a perfecly working, very accelerated 10.5+ to Mac ppc users running 10.4.11. X264 guys have also put a huge time and effort to altivec acceleration. Where will be vp8 altivec? Will they even bother? You can deal with plain c normally but for advanced codecs, hand crafted acceleration is a must. That is, in case you dare to compete with h264.
Let me describe what I talk about when I say altivec/sse accelerated code: I can watch 720P hd/h264 on a 1,42 GHZ mac mini via coreplayer, from the guys created the mkv format. /Yes, 25 fps. 50 when I benchmark.

Originally posted by Ilgaz:

First of all, you can't transcode from a lossy and particularly modern codec to a different lossy codec.

What makes you think they won't be recoding the original video file?

Hating patents is one thing, ignoring reality is another. Haavard also confuses Google with Opera. Google is the company who abandoned all ppc mac users in chrome while Opera does ship a perfecly working, very accelerated 10.5+ to Mac ppc users running 10.4.11.

Why are you attacking Opera employees, and what on earth are you talking about? Who is ignoring reality about what?

X264 guys have also put a huge time and effort to altivec acceleration.

What are you going on about? Are you drunk? Are you saying that VP8 can't be improved at all? LOL. Drunk indeed.

Originally posted by prd3:

VP8 can't be improved at all? LOL

Yeah, sure, guys can change their specs and add some pretty cool patented technologies.

prd3 please stop insulting people, it's a bad defensive tactic.

Originally posted by zbgoswvhvsq:

Yeah, sure, guys can change their specs and add some pretty cool patented technologies.

You don't need to change the spec to improve VP8.

prd3, FOR SHAME! That was a prepared statement from an On2 exec more than a year ago, with no actual examples and no real performance comparisons! Half of what he described simply does not work as advertised, and the MV clamping simplification actually BROKE the reliability of MV clamping!

I am currently working my way through a large batch of 'live' clips from YouTube, which demonstrate Google's own working implementation of the VP8 encoder. I can not say that I am reassured, but I will place my findings in my own blog page when I am finished going through them.

The license and the sources/"spec" are a veritable nightmare, I'll need to break them down separately over this next week. VP8 may be 'final', but it is not complete.

That streamingmedia.com post uses the Mainconcept encoder (not particularly good) and has the images hosted as GIF files. Posting codec comparisons in a lossy format is a big no-no. And that guy calls himself an expert.

Dillon, why give that fellow any credit at all? He had some other party reprocess a lossy source clip, which began with poor image quality and some artifacting.

The so-called "360p" shows VP8 consistently taking 30%-100% more bandwidth on YouTube, with much worse audio quality. The 720p ranges from -5% to +30% bandwidth, with roughly equal audio quality and marginally worse image quality. Especially bad are: "high-contrast mixed-color images", "color gradients", and "fast motion" (really any fast motion, but especially full-scene fast motion). When you see stepping or dithering in the gradients and fades, you are looking at the 1990's all over again. VP8 HQ reminds me of Bink Video HQ.

VLC's WebM support is not perfect, but it uses very little CPU compared to Opera. I saw in another thread (desktopteam? the forum thread?) that the performance hit in Opera is very temporary while they test a better drawing interface. In VLC I did not see torn frames, so most of the *really* bad image problems are an issue with Opera's development preview.

I still intend to have a writeup of my own later this week, but here are a few clips I used for the comparison:

http://www.youtube.com/watch?v=tQxbpryKKQo
"360p"11.5MB/20.9MB; "720p"44.3MB/62.MB
Adriana Lima COMEBACK (very poor audio in VP8/360p)

http://www.youtube.com/watch?v=EMs5pWce1y0
"360p"10.8MB/13.5MB; "720p"34.5MB/34.3MB (!)
BLUR - Danica Patrick (well it certainly is blurry)

http://www.youtube.com/watch?v=IMS-gewLP44
"360p"16.6MB/38.9MB (!); "720p"56.5MB/77.0MB
Hot Chip - I Feel Better (grueling, x264 does much better)
*It is noteworthy that VP8 LQ takes nearly 2.5x the space!

http://www.youtube.com/watch?v=8sFlBJ1Jk3w
"360p"26.5MB/48.8MB; "720p"95.9MB/108MB
Billy Joel - Piano Man HD (Audio problems crept in VP8 LQ)
*VLC choked and died on the VP8 HQ, I blame VLC for this

If anyone wants to check this but does not know how to extract clips, please contact me via PM.

Interesting info cutting spoon. Haven't had much time for geeky articles and comparisons lately about VP8, but the issues in haavard's linked article made me recall this article about ogg, http://hardwarebug.org/2010/03/03/ogg-objections/ , which likewise is not flattering about ogg.

It seems that Opera has to worst CPU performance with WebM (compared to chrome and firefox)
http://forum.doom9.org/showthread.php?p=1402558#post1402558
Does anyone know why this might be?

Because its not final and just a labs build...

Fair enough, haha.

OK, apparently the WebM lab build does a bunch of unnecessary stuff with the video frame buffers. Seems the devs know about it so that's good.
http://forum.doom9.org/showthread.php?p=1402663#post1402663

Originally posted by deadHarlequin:

the issues in haavard's linked article made me recall this article

That was about the video container, so-called ".ogg"; one may note that VP8 uses the ".webm" container, which is a partial implementation of the superior Matroska (.mkv) container recommended in the anti-ogg argument.

This was very fascinating to read: http://carlodaffara.conecta.it/?p=420

Dillon: Initial preview takes frames from the decoder and presents them as a stream of images, possibly a canvas hack or other creative use of Vega. The only official comment I've seen, is that it's waiting on some other work they're doing with the presentation engine. Quite possibly it will be drawn as a GPU texture in the future, same as most good media player software. Just give them time.

Yeah I asked Philip Jägenstedt and he says there's a lot of optimization do be done in both the software and hardware rendering.
http://blog.foolip.org/2010/05/19/vp8-has-landed/#comment-742

Originally posted by Astrophizz:

Yeah I asked Philip Jägenstedt and he says there's a lot of optimization do be done in both the software and hardware rendering.

http://blog.foolip.org/2010/05/19/vp8-has-landed/#comment-742

Just what I said:

Originally posted by ouzoWTF:

Because its not final and just a labs build...

Hardware acceleration (even 2d) is truly amazing. If you have an Intel GMA, crashing the graphics driver will boot you back to 640x480(4bit). VLC can still play movies under that condition, but as imagined they are ugly and CPU-heavy. You can also tell VLC to output using Windows GDI in XP, with a similar performance hit. So it will only get better from here.

I wasn't arguing with you, OuzoWTF. You don't need to repeat yourself.

Originally posted by Astrophizz:

Fair enough, haha.

Originally posted by Cutting Spoon:

Hardware acceleration (even 2d) is truly amazing. If you have an Intel GMA, crashing the graphics driver will boot you back to 640x480(4bit).

Maybe this will help and they'll push out some driver updates for our GMA's?

Cheers!

Good find! But this is not about Intel GMA. This is about Intel SOC. Of all companies, Intel is in a better position by using x86-based hardware decoding. This is because many hardware decoders are simpler, similar to the stream processors in video cards.

Some of the decoding steps in VP8 are very difficult to implement with current hardware decoding technology, but Intel has been pushing the idea of a graphics card built from x86 micro-cores. Intel's reasoning is that x86 and SSE are more flexible than purely graphical technology, and allow more complicated operations to be handled by just the graphics card.

So, Intel's Atom-based graphics chips are probably easier to customize for dedicated VP8 decoding. Most other companies will need to engineer entirely new configurations of decoding logic before they can even TEST hardware-based VP8. Don't expect to see any direct-to-webm camcorders in the near future.

Originally posted by Cutting Spoon:

Don't expect to see any direct-to-webm camcorders in the near future.

I'd rather shoot in something a little less lossy.

True, but many of those cheap and crappy handycams are only for recording to put on YouTube. A professional camera should use lossless settings and a hard drive or SSD, so VP8 is not even a contender in that arena.

This is the most recent post regarding this topic and I thought this might interest people: http://www.businesswire.com/news/home/20100825006629/en

Basically the MPEG LA will allow video to be released online without licensing fees so long as the video itself is free. This basically renders all of the fears about what will happen in 2016 null.

Originally posted by Astrophizz:

the video itself is free

So what does that make of online pay sites for video?

Seems that they would have to pay licensing fees. Are you thinking about something like Netflix or Hulu Pro? I always thought that the argument against having to pay licensing fees for h.264 was that it would stagnate the average person from hosting videos. I don't believe the average person intends to charge people for said videos but I might be wrong.

Or from a Cable provider that allows you to watch shows online

Yes I suppose the cable provider would have to pay licensing fees. But then I suppose they're already paying licensing for mpeg2 or h.264 as those are the two main broadcast formats (if they have to pay to broadcast them). The licensing might be different though and I don't know if they'd have to pay for both or just the original licensing.