WebM Exciting New Video Standard with VP8, Vorbis, Matroska [Archive] - Page 7

rernst

27th June 2010, 20:15

rernst can you share the script you used to encode with mencoder, ive tried but im unable to select video bitrate, the best i found was this but it tells me vlc doesnt play libv

I used vbitrate. I noticed that only a subset of vpx options is accepted under ="xxx". I have somewhat run into a wall with the mencoder folks which seem hesitant to embrace vpx because they cannot deliver variable bitrate and therefore altref= is not supported. This it seems is the primary reason for vpx's excellent quality.

The main problem I see at the moment that the maintainers of libavcodec for mencoder have removed all of the Google patch in the latest svn I looked at. I don't fully understand that mentality.

I have switched to ffmpeg for that reason (which I will incorporate into YAMF as soon as some other work is done). Unfortunately ffmpeg, as I have found in doing so, has a lot of drawbacks compared to mencoder.

I would expect the MeGUI folk(s) to support vpx pretty soon (at least this looks like the logical choice).

Without mencoder enthusiasm that route looks like a dead end street and I would focus on ffmpeg.

Selur

27th June 2010, 20:56

rernst

27th June 2010, 21:00

Trying to match the ivfenc options with ffmpeg I came up with this spreadsheet (http://spreadsheets.google.com/ccc?key=0AvWxUS1XGCPAdGNtNW10a2p4c1VwdG1VZk1uMl9MUEE&hl=en) so far. It's free to edit for everyone using the above link, so if anyone wants to and can help to fill it plz do so. :)

Cu Selur
I believe -good and -best are matched by

-level 100 - best
-level 200 - average
-level 300 - fast encoding.

My understanding so far.

Selur

27th June 2010, 21:07

I added it to the spreadsheet :)

iwod

30th June 2010, 03:45

Is DS now working on FFmpeg Vp8 as well? I read the news on Ars

Astrophizz

30th June 2010, 04:23

According to the linked article, yes he's working on the x86 optimizations for the decoder.

Dark Shikari

30th June 2010, 06:09

I wrote:

Some of MMX 4 and 6-tap MC (original written by Ronald)
SSE2 4 and 6-tap MC
SSSE3 4 and 6-tap MC
MMX DC-only iDCT (rewritten from Ronald's original)
SSE4 DC-only iDCT
MMX iWHT
MMX, SSE2, and SSSE3 bilinear MC
Two dozen or so MMX/SSE/SSE2/SSSE3 intra prediction functions

Currently only the loopfilter (all 6 types: simple_h, simple_v, normal_inner_h, normal_inner_v, normal_mbedge_h, normal_mbedge_v) is left among "things that are important", and Ronald is doing that.

The linked article fails to mention Ronald for some bizarre reason, which is odd because he's done a huge amount of the work (he's been working on the C code as well).

hajj_3

30th June 2010, 08:16

nice work DS, how much faster do you think your optimisations will benefit a user with a fairly new cpu like a core 2? Are these optimisationss just for the decoder or have they been added to the decoder too?

oibaf

30th June 2010, 11:48

Is there a plan to port some of the ffmpeg vp8 decoder work to libvpx (it should at least be relicensed under BSD) or is it so much integrated with ffmpeg that it isn't feasible and libvpx should wait for dixie (http://review.webmproject.org/#change,118)? I am thinking of projects using libvpx, e.g. firefox or vp8 dshow filters, that could benefit from the speedups.

iwod

30th June 2010, 18:25

hajj_3

3rd July 2010, 09:46

WebM V0.9.9 DirectShow filters have just been released.

Changelog:

(1) two-pass VP8 encoding is now fully implemented

(2) makewebm now supports reading and writing GraphEdit (*.grf) files

(3) source filter now uses Cues element, for more efficient seeking

(4) webmmux filter now allows you to specify WritingApp element

(5) VP8 encoder filter now allows you to force a keyframe to be
created immediately

PatchWorKs

3rd July 2010, 22:57

Is DS now working on FFmpeg Vp8 as well?
Of course, DS is a Google employee !

Suggestion for the encoder (but not just the VP8 one): what about ThinkMeta Fiber Pool (http://www.thinkmeta.de/en/fiberpool_overview.html) "adoption" ?

Atak_Snajpera

3rd July 2010, 23:08

WebM V0.9.9 DirectShow filters have just been released.
Why do we even need this? Haali Media Splitter + latest FFDshow is not enough for webm???

clsid

4th July 2010, 00:17

ffdshow is currently still a little bit slower. But soon it will probably be faster.

GodofaGap

4th July 2010, 07:59

Why do we even need this? Haali Media Splitter + latest FFDshow is not enough for webm???
Is it really strange that a company provides a playback solution for a format it assembled itself?

zafna

4th July 2010, 09:31

Why do we even need this? Haali Media Splitter + latest FFDshow is not enough for webm???

why not?It also is an option for webm,and,this's not a bad thing:rolleyes:

Dark Shikari

4th July 2010, 10:05

Of course, DS is a Google employee !If I was a Google employee, I'd be working on libvpx, not ffmpeg ;)

Is there a plan to port some of the ffmpeg vp8 decoder work to libvpx (it should at least be relicensed under BSD) or is it so much integrated with ffmpeg that it isn't feasible and libvpx should wait for dixie? I am thinking of projects using libvpx, e.g. firefox or vp8 dshow filters, that could benefit from the speedups.No, ffmpeg is LGPL, and libvpx is BSD. I will not release the asm under a more liberal license (at least not without significant compensation), because the express purpose of this project is to take control away from Google and give it back to the free software community.

If everyone uses ffmpeg vp8 because it's faster and better, Google will no longer have control of both the encoder and decoder, and will thus no longer be able to abuse their position as much as they can (and have) now.

lnatan25

4th July 2010, 15:24

So, the purpose is noble, but if a "significant compensation" comes, the hell with morals? :rolleyes:

bob0r

4th July 2010, 16:22

"significant compensation" only means even better code can be written and the cycle starts all over again! :)

iwod

5th July 2010, 09:18

I cant wait for a FFmpeg version of Vp8.......Althought it sounds like it is at least a few years away..........

Dark Shikari

5th July 2010, 09:27

So, the purpose is noble, but if a "significant compensation" comes, the hell with morals? :rolleyes:"Significant compensation" could be used to fund other noble endeavors, obviously. :p

oibaf

5th July 2010, 10:25

Thanks for the clarification. However, what do you mean with:

If everyone uses ffmpeg vp8 because it's faster and better, Google will no longer have control of both the encoder and decoder, and will thus no longer be able to abuse their position as much as they can (and have) now.

They released very liberal (BSD) code + patent grant that can be used in all free and closed software for free (even ffmpeg could just relicense this code to LGPL and integrate in ffmpeg, but having an independent implementation is nice), why do you think they are abusing their position (just asking, since it's not clear to me :confused:)?

Dark Shikari

5th July 2010, 10:33

Thanks for the clarification. However, what do you mean with:

They released very liberal (BSD) code + patent grant that can be used in all free and closed software for free (even ffmpeg could just relicense this code to LGPL and integrate in ffmpeg, but having an independent implementation is nice), why do you think they are abusing their position (just asking, since it's not clear to me :confused:)?In a normal situation with a standardized file format, the spec is the rule. No implementation is privileged. If bugs are found in implementations, you fix the implementations. This makes it fair for anyone to implement a program that abides by the spec, because they know that they will be subject to the same rules as everyone else.

Google has done the complete opposite.

They have already repeatedly deemed that bugs in libvpx are "part of the spec". In many cases, their spec outright contradicted libvpx. Now they've reneged on the entire concept of the spec, renamed it into a "bitstream guide", and stated that everything libvpx does is correct no matter how stupid, how buggy, and how broken.

There is no "fairness" -- they are right and you are wrong. There is no public mechanism, like in a standards organization, for anyone else to have any input. They've attempted to appease people with an "experimental branch" that will never actually matter, much like an H.264+ released today wouldn't matter for years to come, and won't affect anything that they do now.

In this sense, VP8 might as well be a proprietary format. There is no spec, it's controlled entirely by a single megacorporation, compatibility is interoperability with their software and their software alone (including its bugs), and everyone else gets screwed. It's no different from Adobe Flash or Microsoft Word, except perhaps that there are apparently still people out there who will defend them for it.

EricJ2190

5th July 2010, 18:26

Is the ffmpeg implementation of VP8 going to follow the spec instead if libvpx?

Dark Shikari

5th July 2010, 19:29

Is the ffmpeg implementation of VP8 going to follow the spec instead if libvpx?No, if we followed the spec it would be totally useless -- it wouldn't play anything. We're following libvpx.

The difference is that once it's working, if people use it, Google will no longer be able to change things on a whim, because they don't control ffmpeg.

GodofaGap

5th July 2010, 21:28

The difference is that once it's working, if people use it, Google will no longer be able to change things on a whim, because they don't control ffmpeg.
Of course they can, and ffmpeg can then choose to have a non-working VP8 implementation or not.

Dark Shikari

5th July 2010, 22:42

Of course they can, and ffmpeg can then choose to have a non-working VP8 implementation or not.If everyone uses ffmpeg's decoder, and Google changes the format, none of Google's new videos will work in anyone's players.

kieranrk

6th July 2010, 00:32

If everyone uses ffmpeg's decoder, and Google changes the format, none of Google's new videos will work in anyone's players.

I assume VLC will be the major chunk of "anyone's players".

What I don't understand is why doing this will change Google's attitude since most people will assume the player is broken before the video is.

Dark Shikari

6th July 2010, 00:44

I assume VLC will be the major chunk of "anyone's players".

What I don't understand is why doing this will change Google's attitude since most people will assume the player is broken before the video is.It might not work, but it can't hurt to try.

Regardless, the situation before ffmpeg vp8 was that there was only one decoder which Google had full control over. Sure, someone could have forked it, but nobody did. Now, there is another option.

GodofaGap

6th July 2010, 07:55

If everyone uses ffmpeg's decoder
This is a rather big if. I'm sure Google is not going to rely solely on ffmpeg for playback of their format.

I also don't see any reason why Google would even want to control the format that way, cause they would have had a much easier job with a closed format. There is also a bigger problem that, if they want other people to use this, they can never break backwards compatibility when the format is released as stable. Otherwise they are just pushing people (especially content providers) back to H264. At some point the cost of re-encoding a whole media library is going to outweigh the cost of royalties.

I really don't think it's the format itself Google is trying to control here.

Dark Shikari

6th July 2010, 08:26

This is a rather big if. I'm sure Google is not going to rely solely on ffmpeg for playback of their format.They're relying solely on ffmpeg for Vorbis encoding, despite the fact that the ffmpeg developers themselves have explicitly told them to stop doing so because ffmpeg's Vorbis encoder is a pile of balls.

Also, most consumer tools (VLC, MPC-HC, etc) rely on ffmpeg.I also don't see any reason why Google would even want to control the format that way, cause they would have had a much easier job with a closed format. There is also a bigger problem that, if they want other people to use this, they can never break backwards compatibility when the format is released as stable. Otherwise they are just pushing people (especially content providers) back to H264. At some point the cost of re-encoding a whole media library is going to outweigh the cost of royalties.

I really don't think it's the format itself Google is trying to control here.So why hasn't Google submitted VP8 to a standards organization, like W3C? Well, other than the fact that they themselves aren't sure of the specifics of their own format, besides "this C code appears to decode it correctly".

GodofaGap

6th July 2010, 09:07

They're relying solely on ffmpeg for Vorbis encoding, despite the fact that the ffmpeg developers themselves have explicitly told them to stop doing so because ffmpeg's Vorbis encoder is a pile of balls.
I'm not sure what this has to do with relying on ffmpeg for VP8 playback. Or are you suspecting that they will start to constantly change the Vorbis bitstream too?

Also, most consumer tools (VLC, MPC-HC, etc) rely on ffmpeg.
Yes, but if Google *is* going to change the format on every whim then they will provide playback solutions themselves. There is no point in pushing a format no one can play.

So why hasn't Google submitted VP8 to a standards organization, like W3C? Well, other than the fact that they themselves aren't sure of the specifics of their own format, besides "this C code appears to decode it correctly".
There is a piece in the puzzle missing between not bringing a format to a standards organization and constantly pissing everybody off (including content providers) by breaking compatibility of your own format.

oibaf

6th July 2010, 09:13

I don't think Google want to keep control of the codec, they said many times that the format is frozen and this is also said in The first in-depth technical analysis of VP8 blog post (http://x264dev.multimedia.cx/?p=377) and on their FAQ (http://www.webmproject.org/about/faq/):

Are VP8 or WebM subject to change?
The VP8 and WebM specifications as released on May 19th, 2010 are final. [...]

The problem is that the specs are not well written and incomplete and independent implementations are useful to validate the real bitstream.

Anyway also ffmpeg decoders/encoders often didn't comply the specs, this is what I get with ffplay 0.5.1 included with latest Ubuntu 10.04 with a theora video:
http://img686.imageshack.us/img686/6079/ffplayffmpegtheora.png

Fortunately VLC uses libtheora rather than libavcodec...:
http://img710.imageshack.us/img710/9601/vlctheora.png

The ffmpeg theora problem should hopefully be fixed with ffmpeg 0.6 released on 2010-06-15.

Maybe Google should hire some more developers with open source experience (theora or ffmpeg developers?) to speed up the process (update the specs and fix/improve the reference library).

iwod

6th July 2010, 09:31

They're relying solely on ffmpeg for Vorbis encoding, despite the fact that the ffmpeg developers themselves have explicitly told them to stop doing so because ffmpeg's Vorbis encoder is a pile of balls.

Are they insane? Why use FFmpeg Vobris Encoder? The official one already included the tuning from aoTuV... which is MUCH MUCH better then FFmpeg encoder.....

God we are stuck in the middle of no where. Designing a Hardware Decoder for WebM will be hard. With no Standard what so ever. We are hold back by Stupid Apple usage of Mpeg 4 which is Baseline Profile. I would be happy if they even use Mainline or not High profile... Baseline is painful.

nurbs

6th July 2010, 10:01

All the new Apple stuff can play High Profile.

Leeloo Minaï

6th July 2010, 13:05

The problem is that the specs are not well written and incomplete and independent implementations are useful to validate the real bitstream.

Anyway also ffmpeg decoders/encoders often didn't comply the specs...

Did you see you are in contradictory with yourself ?
An independent implementation (like FFmpeg) which does not respect the specs (like theora in your example) cannot validate anything...

dragsidious

9th July 2010, 05:12

What matters much more to me then any spec is the ability for a decoder to properly decode the video.

Does anybody produce a reference 'lowest common denominator' decoder for WebM/VP8 yet? Does a reference hardware decoder exist?

To me this is what matters. Every time I've seen people try to establish standards and specifications in software.... all that is much less relevant then whether or not it's going to be compatible with what the end user will be using to view the data.

I can't think of a single complex specification were people follow it to the letter: TCP/IP, CSS, HTML, NFS, etc etc. Hell I can think of a few big examples were people followed to closely to the letter of the specification and ended up with extreme compatibility issues. One example of this is the NFSv4 folks that tried to copy Microsoft's file system ACL documentation so slavishly that they ended up with something that was completely incompatible to any existing implementation.

I don't know if having reference hardware and software decoding makes sense exactly, but it does to me. God damn the specification and full speed ahead.

Having a separate GPL/LGPL licensed ffmpeg vp8 encoder is a fantastic idea and I can't think of any better project to do it. In my eyes ffmpeg is just about the king for this sort of thing.

If this can be used as leverage to get a established reference decoder, in hardware and software, then this will go a long long way to making Webm be more acceptable for wider adoption.

If a video is decode-able on the reference decoder and is not on a different one then you know the bug is in the decoder. If a video is playable on a project's specific decoder, but not on the reference then the bug is in the encoder. Otherwise you end up with a strong tendency to say it's the other person's fault that your shit is broke.

wiak

9th July 2010, 05:18

If I was a Google employee, I'd be working on libvpx, not ffmpeg ;)

No, ffmpeg is LGPL, and libvpx is BSD. I will not release the asm under a more liberal license (at least not without significant compensation), because the express purpose of this project is to take control away from Google and give it back to the free software community.

If everyone uses ffmpeg vp8 because it's faster and better, Google will no longer have control of both the encoder and decoder, and will thus no longer be able to abuse their position as much as they can (and have) now.
:stupid:
i prefer ffmpeg encoder over ivfenc, why? alot more noob friendly

CruNcher

9th July 2010, 14:27

:stupid:
i prefer ffmpeg encoder over ivfenc, why? alot more noob friendly
:spitshismilk:

Selur

9th July 2010, 14:48

yup, first time I ever read that some one called ffmpeg "noob friendly" ;)

stax76

10th August 2010, 10:11

There is now basic WebM support using ffmpeg in StaxRip.

https://sourceforge.net/projects/staxmedia

hajj_3

11th August 2010, 13:35

new build of WebM out (webmdshow-0.9.10.0-20100809): http://webm.googlecode.com/files/webmdshow-0.9.10.0-20100809.zip

Emp3r0r

23rd August 2010, 04:54

sibvic

23rd August 2010, 13:37

Found this demo video on YouTube encoded in WebM format:

WebM Demo with Leonardo Dicaprio - Shot with Red Camera (http://www.youtube.com/watch?v=rLxQiI8c1Bs&p=4FFFFF981ECC3263&playnext=1&index=14&html5=True)

Quality looks good to me, however I can't get the video to play full screen with the html5 player.

HTML5 forbids full screen play for 3rd-party players (because it's easy to emulate login form/dialog by full screen video+script and steal your password). Browsers should add support of full screen play themselves.

Emp3r0r

23rd August 2010, 23:21

ah hah, pressing F11 got me really close, just the player controls remained on the screen

PatchWorKs

28th August 2010, 00:21

As you probably noticed, MPEG LA’s AVC License Will Not Charge Royalties for Internet Video that is Free to End Users through Life of License (http://www.mpegla.com/main/Pages/Media.aspx).

WebM side effect ? Is their fear rising ?

wiak

28th August 2010, 00:46

Found this demo video on YouTube encoded in WebM format:

WebM Demo with Leonardo Dicaprio - Shot with Red Camera (http://www.youtube.com/watch?v=rLxQiI8c1Bs&p=4FFFFF981ECC3263&playnext=1&index=14&html5=True)

Quality looks good to me, however I can't get the video to play full screen with the html5 player.
you can check my webm/html5 test site at http://s3.nwgat.net/sintel/sintel.html ;)

encoded with FFmpeg & xiph vorbis encoder 1.2

zafna

28th August 2010, 03:50

webm is fully free,it never has royalties problem from google,you don't need to pay for anything,all is free

ricardo.santos

28th August 2010, 15:00

We can use AVC on the web free of charge when using non copyrighted videos NOW. I doubt commercial companies will change their pricing when they use webm (online video rental).

I think the current situation is more than enough/fair with AVC almost everywhere, if you make a profite you'll have to pay, if you use for personall use (family blog) you don't have to pay.

the concept of ONE video format is great but AVC is already playable in every browser, offers better quality, has fair usage terms.

Transition to webm will take more time than what people think (unless flash player includes webm decoding) and webmasters will have to pay more for hosting as they will have to host 2 versions of the same file.

I'm a newbie but all i see in this is a situation where hardware companies have a opportunity to sell more hardware "webm compatible", i think the format is being "pushed/rushed" to us.

Has anyone solved the ffmpeg bug where ffmpeg doesnt use the bitrate specified by the user?