WebM Exciting New Video Standard with VP8, Vorbis, Matroska

[buzzqw]

in HDC beta (check latest post on HDC thread) i added support for ivfenc (NIC version)

BHH

[clsid]

clsid: Never compiled anything for 64bit and I have no idea about what to do, how it differs or anything. However, try: http://nic.dnsalias.com/WebMx64.zipI have only tested the decoder (in combo with Haali splitter) and it works. Thanks!

[AgusBohemio]

ffmpeg with webm compiled in DEB package
http://www.megaupload.com/?d=YTSYPOE2

[CruNcher]

http://www.mediafire.com/download.php?lwymozzmtzi <- Vp8
http://www.mediafire.com/download.php?jtdmmqitm52 <- X264

Encoding Speed
VP8 = 12 FPS (--good --cpu-used=5)
x264 = 30 FPS (--subme 2)

The Visual difference is not that big at least the best what i saw so far compared to H.264 the most problematic thing you can see in the Vp8 encode is missing AQ else it does a pretty good job :)

[Emp3r0r]

Anyone seen a x64 direct-show filter floating around?

[poisondeathray]

Anyone seen a x64 direct-show filter floating around?

There's one a few posts up :)

[GodofaGap]

Just thought i'd let people know VLC 1.1.0 pre-RC with WebM support has just been released: http://people.videolan.org/~jb/webm/ (18.0mb)

.webm files play:)

Did this move somewhere else because the link is dead and the 1.1.0 RC has VP8 decoding removed.

[hajj_3]

the RC does have WebM support, i've tried it myself. http://www.videolan.org/vlc/releases/1.1.0-RC.html

The link was deleted as webm was added to the RC build btw.

[julius666]

http://www.mediafire.com/download.php?lwymozzmtzi <- Vp8
http://www.mediafire.com/download.php?jtdmmqitm52 <- X264

Encoding Speed
VP8 = 12 FPS (--good --cpu-used=5)
x264 = 30 FPS (--subme 2)

The Visual difference is not that big at least the best what i saw so far compared to H.264 the most problematic thing you can see in the Vp8 encode is missing AQ else it does a pretty good job :)

--ref 1, --me dia, --subme 2, no psy-rd
Is this a joke? Of course VP8 is almost as good as H264 if you use so bad settings in x264. :rolleyes:

[GodofaGap]

the RC does have WebM support, i've tried it myself. http://www.videolan.org/vlc/releases/1.1.0-RC.html

The link was deleted as webm was added to the RC build btw.
I have downloaded that and it gave me 'VLC does not support VP80.. etc.'

Also

http://forum.videolan.org/viewtopic.php?f=34&t=76798&p=252505&hilit=webm#p252505

many fixes over 1.1.0-pre4, with notably:
- x264 options update for preset/tune
- Translations update
- Multiple Qt and Mac OS X interfaces fixes
- Fixes for H264 decoding with DR, Audio Convertion, DxVA2 decoding
- DVD, flv, MP4, AVI and AVI/ODML demuxing fixes and improvements
- VP8/Webm decoding support <== REMOVED

[CruNcher]

Im not comparing the compression efficiency here im comparing the PSY Visual Difference and that seems not far of some improvements their and in speed and we have a very well Low Bitrate competitor, though most probably it will take some time for these improvements and by then H.265 will be very far into Research and of course by that time VP8 in even that improved state would be no match, so work on the future VP9 should begin as early as possible also.

[julius666]

Im not comparing the compression efficiency here im comparing the PSY Visual Difference and that seems not far of some improvements their and in speed and we have a very well Low Bitrate competitor, though most probably it will take some time for these improvements and by then H.265 will be very far into Research and of course by that time VP8 in even that improved state would be no match, so work on the future VP9 should begin as early as possible also.

Please explain what "PSY Visual Difference" means, I've never heard of it.

[CruNcher]

x264 = 12 FPS
http://www.mediafire.com/download.php?0mmzmmgtnmm

the result doesn't surprise and no PSY RD here not even RD @ all

so all in all the VP8 Encoder needs a lot of improvement and a lot solutions need to be found working in the new VPx way for things that have been found improving H.264 visualy, but all in all VP8 isn't that bad to start with :)

It is the heaviest MPEG competitor @ the moment and the more that work on it the better it will get in the future :)

[julius666]

x264 = 12 FPS
http://www.mediafire.com/download.php?0mmzmmgtnmm

the result doesn't surprise and no PSY RD here not even RD @ all

so all in all the VP8 Encoder needs a lot of improvement and a lot solutions need to be found working in the new VPx way for things that have been found improving H.264 visualy, but all in all VP8 isn't that bad to start with :)

It is the heaviest MPEG competitor @ the moment and the more that work on it the better it will get in the future :)

Oh, now I understand what you want to achieve :)
You want to dumb down H264 near to the VP8 standard and compare that to the VP8 encoder's result, to know how good is the implementation of the VP8 encoder (correct me if I'm wrong). Please make it clearer next time.
My knowledge of VP8 specs is very limited, but --me umh (or esa/tesa, if you want to be precise) and maybe --trellis 2 would be good as well, but better quality. And isn't 3 ref frames (because of that "golden frames" thing) allowed?
(And there are no weighted p-frames in VP8, you should turn that off).

[Brazil2]

http://nic.dnsalias.com/ivfenc.zip <-- is ivfenc that can take an AviSynth script
http://nic.dnsalias.com/AVSVorbis.zip <-- is aoTuV B5.7 Vorbis Encoder that can take an AVISynth script
Thanks for these tools :)
Although I haven't tried much the latest aoTuV yet but I usually prefer to use -q3 which, in my opinion, sounds better with the latest Oggenc2 from Rarewares than with aoTuV.


http://code.google.com/p/webm/downloads/detail?name=webmdshow-0.9.7.0-20100526.zip <-- Latest DirectShow filters for playback
Sorry to sound stupid but I can't find any DLL in this package ?
So I'm still using the ones from v0.9.6.0 (http://code.google.com/p/webm/downloads/detail?name=webmdshow-0.9.6.0-20100524.zip&can=2&q=).


I've been quite impressed by low bitrate VP8, can look very "watchable".
Yes quality is not bad at all but the counterpart is that files are much larger than with x264 at the same bitrate, I guess because of the lack of B-frames.

[Brazil2]

I have downloaded that and it gave me 'VLC does not support VP80.. etc.'
Get the first RC build with VP8/Webm decoding support here:
http://www.megaupload.com/?d=EU2B1PGB

[CruNcher]

Oh, now I understand what you want to achieve :)
You want to dumb down H264 near to the VP8 standard and compare that to the VP8 encoder's result, to know how good is the implementation of the VP8 encoder (correct me if I'm wrong). Please make it clearer next time.
My knowledge of VP8 specs is very limited, but --me umh (or esa/tesa, if you want to be precise) and maybe --trellis 2 would be good as well, but better quality. And isn't 3 ref frames (because of that "golden frames" thing) allowed?
(And there are no weighted p-frames in VP8, you should turn that off).


You want to dumb down H264 near to the VP8 standard and compare that to the VP8 encoder's result <- we have a winner :)
trellis would slow it down a lot more much way under the VP8 Encoder speed :) yep maybe a higher motion search would be better
Yeah but in this case Golden frames should have been off at least i didn't set the switch for them though i dunno yet what @ default the encoder does
Weighted P makes no real difference here it's not used anyways :)

Also Parkrun is a very Psy intense Source with other sources the difference would be much lower :) see my full Music Video Encode in VP8 as Nic said very watchable :)
http://www.supergenije.com/cruncher/

[GodofaGap]

Get the first RC build with VP8/Webm decoding support here:
http://www.megaupload.com/?d=EU2B1PGB
That works! Thanks. :)

[julius666]

Yeah but in this case Golden frames should have been off at least i didn't set the switch for them though i dunno yet what @ default the encoder does

I don't see any option (http://www.webmproject.org/tools/encoder-parameters/) that would turn golden-frames on or off, aren't they always enabled?

And you could use higher subme in x264. The VP8-encoder itself also has RDO (it's turned on automatically when you use lower --cpu-use than 4) which is enabled only at --subme 6 in x264. Then you could use --psy-rd too, that would give a huge quality improvement.

[Nic]

@Brazil2:
You can ABX between AoTuV and standard Vorbis at -q3? That'd be surprising - should be v.hard to tell the difference. I'm sure you won't be able to tell the difference for your video encodes, so I wouldn't worry about it (I'll put out my source code in case anyone does wanna recompile tho)

http://code.google.com/p/webm/downloads/detail?name=webmdshow-0.9.7.0-20100526.zip <--- in there is install_webdmshow.exe - running that will install the DShow filters (the DLLs).


counterpart is that files are much larger than with x264 at the same bitrate, I guess because of the lack of B-frames. bitrate determines size, so I assume you mean quality.

-Nic

@All: Remember when encoding with ivfenc to use -t to set the number of threads (probably to the number of CPUs you have). -t 4 on my Q9650 does make quite a bit of difference to the encoding speed.

[CruNcher]

I don't see any option (http://www.webmproject.org/tools/encoder-parameters/) that would turn golden-frames on or off, aren't they always enabled?

And you could use higher subme in x264. The VP8-encoder itself also has RDO (it's turned on automatically when you use lower --cpu-use than 4) which is enabled only at --subme 6 in x264. Then you could use --psy-rd too, that would give a huge quality improvement.

For x264 i used respectively 2 and 5 :) as 6 and above would slow down more as you said RD comes into play i disabled that for both especially if you go crazy as you said and using it with trellis not to speak of --trellis 2 it would get a lot slower then the VP8 encoder @ --good ;)
Hmm indeed seems Golden Frames are always on only the alternate reference frames aren't

[ricardo.santos]

Hi everyone!

i've been trying Vp8 for a week now but im faced with a problem, im using a ffmpeg vp8 build but i have to encode the audio separately with lamexp because the ffmpeg build doesnt have libvorbis that gives better results than the default vorbis encoder in ffmpeg

i start with :

ffmpeg -i 01.mp4 -b 450k -threads 2 -an -s 480x192 video.webm
ffmpeg -i 01.mp4 -acodec pcm_s16le -vn test.wav
oggenc2.exe --resample 22050 -b 48 test.wav

then mux mkv and ogg it with mkvtoolnix and then "parse" the file with MKCLEAN

mkclean.exe --doctype 4 final.mkv final.webm

everything works fine but ive noticed that medianfo reports video bitrate as 563k and overal bitrate 631k.

So far if i need to achive a certain bitrate i have to setup the bitrate value as half of what it should be, for example to achieve 900k i need to setup the encode with 450k. this way mediainfo reports the correct bitrate.

When setting up an encode with 450k the ffmpeg windows reports the video is being encoded with 450k but the mediainfo reports 900k as video bitrate.

I tried 3 encodes (wmv, theora and x264) and at 900k they all have pretty much the same size, with vp8 at 900k i get a much bigger file, i i setup with 450k i get the same size i get with the other 3 foprmats at 900k.

Can anyone tell me what i'm doing wrong or is it a mediainfo bug?

This is the vp8/ffmpeg build im using:
http://micksam7.com/blog/index.php/?p=743

Thanks

[Dislikeyou]

When setting up an encode with 450k the ffmpeg windows reports the video is being encoded with 450k but the mediainfo reports 900k as video bitrate.

[22:22] <Dark_Shikari> mediainfo is quite often horrifically unreliable
[22:22] <derf> That actually sounds like a framerate doubling problem.
[22:22] <Dark_Shikari> and yeah, that
[22:22] <@jk8> could be related to the timebase=framerate*2 hack
[22:22] <derf> It's a really big coincidence that it would be off by exactly a factor of 2.
[22:23] <derf> Yes, that is what I'm suggesting.
[22:23] <Dark_Shikari> mediainfo iirc is not very accurate for bitrate of VFR videos
[22:23] <Dark_Shikari> I think it doesn't even try.
[22:23] <Dark_Shikari> which could explain that.

[poisondeathray]

I tried 3 encodes (wmv, theora and x264) and at 900k they all have pretty much the same size, with vp8 at 900k i get a much bigger file, i i setup with 450k i get the same size i get with the other 3 foprmats at 900k.


How are you reading the "size" or "bigger file"? Do you mean "bigger file" as in "filesize" as in windows explorer?

filesize = bitrate x running time

if your vp8 encode has a larger filesize (and assuming same running time) , this implies the bitrate is higher than that of the other encodes (disregarding container size differences)

[GodofaGap]

@Brazil2:
You can ABX between AoTuV and standard Vorbis at -q3? That'd be surprising - should be v.hard to tell the difference. I'm sure you won't be able to tell the difference for your video encodes, so I wouldn't worry about it (I'll put out my source code in case anyone does wanna recompile tho)
Moreover, I remember AoTuV b2 was actually merged into libvorbis 1.1 and I think they were planning on continuing updating libvorbis with AoTuV improvements. So even libvorbis is AoTuV. :)

(although it might be behind)

@Nic:
It's a bit much to ask I know, but would you consider adding piped raw yv12 input?

Thanks for the work in any case. :)

[ricardo.santos]

@Dislikeyou
Thanks for the info

[22:22] <derf> It's a really big coincidence that it would be off by exactly a factor of 2.

with 225k mediinfo reports 450, with 450k mediainfo reports 860... just video bitrates...no audio envolved

How are you reading the "size" or "bigger file"? Do you mean "bigger file" as in "filesize" as in windows explorer?

filesize = bitrate x running time

if your vp8 encode has a larger filesize (and assuming same running time) , this implies the bitrate is higher than that of the other encodes (disregarding container size differences)

thats exactly what is happening, the source file is equal for all encodes in the various formats, even if i disregard the mediainfo reports, the filesize "says" the bitrate is not right, i can only think that the bitrate is higher to explain that.

has anyone had similar experiences? If there's a bug somewhere people could be wrongfully judging quality without noticing that the bitrate is twice as much as x264.

i've tried the ivfenc utility by nic and the same problem appears.


wmv, theora, x264 @450k = 2,90 MB

ffmpeg with vp8 results:

vp8 @ 450k = 3,64 MB
vp8 @ 225k = 2,90 MB

i know it doesnt look that much but on a 10min video the difference in filesize is very noticeable

[Nic]

Hmmm, I just tried running (script has 1400 frames at 23.976):
x264 a.avs -B 450 -o a.264 -p 2
ivfenc --target-bitrate=450 a.avs a.ivf -p 2

To do a similar test and the files were almost exactly the same size:
3,299,704 a.264
3,298,996 a.ivf

one pass is less accurate:
3,496,651 a.264
3,371,109 a.ivf

But I certainly don't see the doubling or difference you do. Anyone else having the same issue as Ricardo?

GodofaGap: AoTuV has been updated quite a bit since then :) raw yv12 input? Maybe ;)

[ricardo.santos]

will try a 2 pass with ffmpeg and ivfenc

[ricardo.santos]

Source: 1 min avi file

ivfenc @450k, 2 pass= 3,23 MB
x264 @450k, 2 pass= 3,21 MB
ffmpeg/vp8 @450k, 2 pass= 4,22 MB
ffmpeg/vp8 @225k, 2 pass= 3,30 MB


video converted with @225k

General
Complete name : C:\video.webm
Format : Matroska
File size : 3.30 MiB
Duration : 1mn 0s
Overall bit rate : 462 Kbps
Writing application : Lavf52.64.0
Writing library : Lavf52.64.0

Video
ID : 1
Format : V_VP8
Codec ID : V_VP8
Bit rate : 453 Kbps


it seems the 2 pass solved the ivfenc problem, so im guessing its an ffmpeg related problem? Can anyone share how you're doing the 2 pass conversion with ffmpeg?

[Dislikeyou]

There's probably loads of ways to test this easily on windows, but in case anyone finds it useful:

http://nic.dnsalias.com/ivfenc.zip <-- is ivfenc that can take an AviSynth script


Your version crash when using --timebase=<arg>

[Leeloo Minaï]

The problem is related to ffmpeg, i tried the webm build posted in this thread and it seems it does not respect at all targeted video bitrate...

Nic's ivfenc is far more reliable.

[Nic]

Dislikeyou: Probably, but why would you want to use a timebase different to the one that's coming in via Avisynth? That's likely to cause issues. Change the framerate in AviSynth if you want something different.

EDIT: Actually it's a problem with how I went from C -> C++ for ivfenc. D'oh! So crashes on the parsing of the timebase. I've fixed it, will test sometime tomorrow and upload a new version.

[Sagittaire]

One2tech say "VP8 on par with H264 (x264) for PSNR" ... and it's not the case in my test.

Actualy at maximum quality (with One2Tech setting) VP8 is not on par with x264 for visual quality in medium quality encoding in my test (q20-25 meduim quality encoding).

WebM encoder is really complete implementation for VP8?

[iwod]

One2tech say "

WebM encoder is really complete implementation for VP8?

Well, there is only one encoder, one implementation of VP8, that is WebM. Dont expect there will be any others.

[CruNcher]

http://www.mediafire.com/download.php?dxzkjtmqjnj <- another test Vp8 had a hard time on this one as the source is very noisy Broadcast Mpeg-2 not like the RED ONE before

[Nic]

No real difference, but http://nic.dnsalias.com/ivfenc.zip (v1.3)

Updated to latest git version (with added .avs support)
Doesn't crash when you ctrl+c to quit early now
--timebase= doesn't do anything, but doesn't crash it now
ARCH_X86 isn't set in vpx_encoder.c which means FLOATING_POINT_INIT/RESTORE isn't getting called (bug in the git repo code?)
Defaulted threads to 4 - just runs faster that way, why wouldn't you want it :)

-Nic

[nurbs]

WebM encoder is really complete implementation for VP8?
It's the only implementation there is, but there is still stuff that is missing in the encoder like psy-optimizations and adaptive quantization and there may be some remaining bugs (that aren't in the bitstream spec and therefore can be fixed). If that works like in x264 that would lower PSNR of course. Also according to discussions in the webm development mailing list AQ will come with a relatively high overhead, up to 2 bits per macroblock. That would be 60 kbit/s on a 640x480@25p video in the worst case.

One2tech say "VP8 on par with H264 (x264) for PSNR"
That, along with the claim I've repeatedly read that VP8 will be up to 50% more efficient than H.264, is called marketing (AKA lies).

Updated to latest git version (with added .avs support)
Nice :-)

Defaulted cpu to 16
What does that mean? Is that --cpu-used? In that case wouldn't that mean very low quality?

edit:
All the threads on the webm discussion boards (http://www.webmproject.org/about/discuss/) are suddenly gone. :confused:

[Nic]

@nurbs: Do you know, I think you might be right (i.e I'm an idiot) - the description just seemed to mean how much cpu was used (and with it at 16 the CPU would reach near 100% which seemed better). But looking thru the code, setting the CPU high does affect the quality. Think I'll revert that change.

[CruNcher]

You could make it ffmpeg default of 3 :)
and those that don't want RD should use 4 or 5
Though this thinking of On2 compared to subme faster encode = lower number = less quality makes sense as faster encode = higher number = less quality
and --deadline reversed lower number = faster speed upto 0 which changes to infinite time (--best) and 1 being realtime (--rt)

[hajj_3]

Mkvtoolnix 4.0.0 has just been released with WebM support :)

http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.0.0-setup.exe

changelog: http://www.bunkus.org/videotools/mkvtoolnix/doc/ChangeLog

Still no support in the latest MPC-HC builds :( I wonder when they will add support.

[nurbs]

MPC-HC uses ffmpeg for decoding IIRC, so whenever VP8 is merged there the player will support it.

[ricardo.santos]

Been trying ffmpeg and ivfenc at same bitrates, just for "fun" nothing "pro", you can watch 4 examples @:

http://ricardouk.com/videos

Altough ivfenc produces "clear" images it has more macroblocks than ffmpeg, to me it looks like ffmpeg tries to reduce macroblocks by "undefining" the video.

Still videos converted with Ivfenc look great, with ffmpeg taking advantage on "faster" videos.

[clsid]

MPC-HC uses ffmpeg for decoding IIRC, so whenever VP8 is merged there the player will support it.
It only uses a small subset of ffmpeg.

Playing webm files with MPC is already possible with the WebM DirectShow filters, or Haali Spitter plus just the VP8 decoder.

[Gromozeka]

Nic
you can add pipe? :)

ffmpeg -i 1.avs -f yuv4mpegpipe - | ivfenc - out.ivf --yv12 -t -p 1 --best --cpu-used=0 --target-bitrate=400 --end-usage=0 -v \
--minsection-pct=5 --maxsection-pct=800 --kf-min-dist=0 --kf-max-dist=360 --token-parts=2 --static-thresh=0 --min-q=0 --max-q=63\

[CruNcher]

Hmm Nic STRG+C crashes with --cpu-used= 1,2 and 6 <- very strange behavior :D

doesn't happen with the first build

starts with the 1.2 build :D the crash is in avifil32.dll

[Nic]

Can't reproduce - but up'd a new version handling it a different way (http://nic.dnsalias.com/ivfenc.zip) :)

[CruNcher]

Can't reproduce - but up'd a new version handling it a different way (http://nic.dnsalias.com/ivfenc.zip) :)

fixed :)

PS: How about making --drop-frame=0 default :)

[Ulf]

MediaInfo reports a frame rate that is twice the true framerate for a 'webm' file (muxed with Mkvtoolnix 4.0.0). MPC plays the file OK.

If I extract the 'ivf' and 'ogg' files (using mkvextract.exe) and remux them with mkvmerge, MediaInfo reports the true frame rate but MPC plays the file at half frame rate.

Does anyone have a clue whats going wrong?:confused:

[ricardo.santos]

i noticed that but the videos play fine and i know the true frame rate, could be a mediainfo bug, webm is a "new" format.

[Dislikeyou]

Im no expert but i think it reports double frame rate cause ivf encoded movies has doubled frames.. i mean if u extract the same movie to png u will notice that frame 1 and 2 are different.. but frame 3 and 4 are same and 5 and 6 are same and so on until the end.. it basically duplicates the frames.. so frame 250 in original movie will be frame 500 in the ivf encoded movie.. so i dont know if it is mediainfo bug or not