WebM Exciting New Video Standard with VP8, Vorbis, Matroska

[Atak_Snajpera]

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 think transition will be very smooth and easy. Just install FireFox 4.0 or Chrome and you are ready to go.

[nurbs]

Yeah, 'cause that will magically make every website HTML5 compatible and convert every file on the internet into webm. :rolleyes: There are also plenty of devices where installing either of the browsers not an option. There is definitely going to be a transition period and I doubt H.264 will vanish any time soon.

[Midzuki]

Just install FireFox 4.0 or Chrome and you are ready to go.

Not everybody likes Chrome and/or Firefox. :)

[Sharktooth]

opera likes webm too...
internet exploDer 9 will support it thru a plugin.
so 4 of the most common web browsers (will) support webm almost out of the box.
plus, next nvidia and ati cards (dont know about intel) will support webm hardware decoding...
and remember MPEG-LA can always "change" idea...

[Astrophizz]

Actually the mpegla can't reverse their position without risking legal repercussions. Also Chrome supports both h.264 and webm.

[oibaf]

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).


There is an interesting article about this here: Hold The Celebrations; H.264 Is Not The Sort Of Free That Matters (http://lwn.net/Articles/402955/):

First, the H.264-format video needs to be created - but that isn't free under this move. Then it needs to be served up for streaming - but that isn't free under this move. There then needs to be support for decoding it in your browser - but adding that isn't free under this move. Finally it needs to be displayed on your screen. [...] The only part of this sequence being left untaxed is the final one. Importantly, they are not offering to leave the addition of support for H.264 decoding in your browser untaxed. In particular, this means the Mozilla Foundation would have to pay to include the technology in Firefox.

[Sharktooth]

can you hear the bells ringing? webm is free in all those aspects.
IMHO webm is the future even if it is not on par with h.264... expecially x264.
in the meanwhile google released a quicktime component for webm. download(s) here: http://code.google.com/p/webm/downloads/list

[iwod]

No Hardware acceleration is a main concern.

[ricardo.santos]

@oibaf

First, the H.264-format video needs to be created - but that isn't free under this move.

My understanding is that for personal/noncommercial use its free, i can use my minidv camcorder and convert to h264 without paying.

Then it needs to be served up for streaming - but that isn't free under this move.

If people use webm they need to pay for hosting the files like we do for mp4 now, theres free storage for both formats.

There then needs to be support for decoding it in your browser - but adding that isn't free under this move.

i can play it in my browser though plash player for free.

[Sharktooth]

No Hardware acceleration is a main concern.
HW acceleration is coming from all the bigs... including nvidia, ati, intel... etc.

[Sharktooth]

@oibaf


My understanding is that for personal/noncommercial use its free, i can use my minidv camcorder and convert to h264 without paying.



If people use webm they need to pay for hosting the files like we do for mp4 now, theres free storage for both formats.



i can play it in my browser though plash player for free.
free for the end user does not mean free...
if one day you want to code a html5 web browser you cant include the h.264 decoder for free...
megui, for example, uses a lot of non-free software and we have to find a solution moving the update server to another country to circumvent patent laws.
there are several aspect of a single problem. so dont jump on the horse just coz someone said it's a winner... it could be a looser as well...

[ricardo.santos]

free to create aswell if im not mistaken as long as it meets some criteria like if the source is not copyrighted or the user makes money out of it.


unless im proven wrong the format is free for end user, free to create/convert/stream under certain circumstances like the ones mentioned above.

why do people say "its not free at all" when its actually not true, it is free if you want to share your holidays videos through your personnal blog.

Of course big (commercial) companies are supporting this, opportunity to sell chips/ processors/players etc etc that are "compatible" or in some way enhance the webm experience, big online commercial companies are also happy with this as they can still charge the same price for their video services (video rentals, cable etc) while using a free format.

Do i belive the user (large majority of internet users) will benefit from this: NO
Will commercial companys benefit: YES


@Sharktooth
I'm keeping an open mind about this, but theres a lot of mp4 bashing for no apparent reason, normal users are being mislead by "mp4 is not free, you cant convert/stream your videos with it"

[Superb]

libvpx v0.9.2 is out (http://code.google.com/p/webm/downloads/list).
2010-09-02 v0.9.2
Enhancements:
Disable frame dropping by default
Improved multithreaded performance
Improved Force Key Frame Behaviour
Increased rate control buffer level precision
Fix bug in 1st pass motion compensation
ivfenc: correct fixed kf interval, --disable-kf
Speed:
Changed above and left context data layout
Rework idct calling structure.
Removed unnecessary MB_MODE_INFO copies
x86: SSSE3 sixtap prediction
Reworked IDCT to include reconstruction (add) step
Swap alt/gold/new/last frame buffer ptrs instead of copying.
Improve SSE2 loopfilter functions
Change bitreader to use a larger window.
Avoid loopfilter reinitialization when possible
Quality:
Normalize quantizer's zero bin and rounding factors
Add trellis quantization.
Make the quantizer exact.
Updates to ARNR filtering algorithm
Fix breakout thresh computation for golden & AltRef frames
Redo the forward 4x4 dct
Improve the accuracy of forward walsh-hadamard transform
Further adjustment of RD behaviour with Q and Zbin.
Build System:
Allow linking of libs built with MinGW to MSVC
Fix target auto-detection on mingw32
Allow --cpu= to work for x86.
configure: pass original arguments through to make dist
Fix builds without runtime CPU detection
msvs: fix install of codec sources
msvs: Change devenv.com command line for better msys support
msvs: Add vs9 targets.
Add x86_64-linux-icc target
Bugs:
Potential crashes on older MinGW builds
Fix two-pass framrate for Y4M input.
Fixed simple loop filter, other crashes on ARM v6
arm: fix missing dependency with --enable-shared
configure: support directories containing .o
Replace pinsrw (SSE) with MMX instructions
apple: include proper mach primatives
Fixed rate control bug with long key frame interval.
Fix DSO link errors on x86-64 when not using a version script
Fixed buffer selection for UV in AltRef filtering

[Sharktooth]

@Sharktooth
I'm keeping an open mind about this, but theres a lot of mp4 bashing for no apparent reason, normal users are being mislead by "mp4 is not free, you cant convert/stream your videos with it"
infact you cant unless you pay for a licensed encoder or someone release a free but still licensed encoder (so who release it have to pay).
you can use x264 coz binaries are build by users and/or hosted in a country where there are non restrictive laws on patents... same for h.264 decoders (like ffmpeg/libavcodec).
so, im sorry but h.264 is NOT free at all.

[nurbs]

I can see the problem here. Your definition of "NOT free at all" is different from other peoples definition. Most people would think "NOT free at all" means there isn't a single case where it's free, while by your definition it means there are many cases where it is free, but also many where it isn't.

[Sharktooth]

exactly. it all depends by local laws on patents.
MPEG-LA just made some content free to distribute on some medium... no more than that.

[LigH]

I wonder why the threads number for ivfenc is recommended (http://www.webmproject.org/tools/encoder-parameters/#6_multi-threaded_encode_and_decode) to "number of real cores - 1". Would that rather mean the "number of additional forks" of the parallelizable encoder routine? Did anyone already test the performance for different core/thread ratios like that was done for x264? (Sorry if I missed that, I rarely read here, and might have searched for the wrong keywords.)

P.S.: It doesn't seem like Nic is going to update his AviSynth enabled ivfenc mod regularly? Please prove me wrong or point me to alternatives. ;)

P.P.S.: I believe ivfenc lies to me. The first pass definitely does not run at 46 fps, rather 4.6 fps ...

[oibaf]

New VP8 Test Vectors Available:
http://webmproject.blogspot.com/2010/09/new-vp8-test-vectors-available.html

[foxyshadis]

So has anyone had a chance to do a real quality comparison between the latest versions and the current x264? (Comparing at same bitrate and same encoding speed.) I'm really quite interested in how much the quality gap has narrowed over the summer.

HW acceleration is coming from all the bigs... including nvidia, ati, intel... etc.

HW acceleration was "coming" for H.264 and VC1 from at least 2004. The first demos weren't until 2005, public releases in early 2006, and they still weren't really bug-free until 2007. Plus you had to buy new hardware - then buy it again when it turned out the first generation wasn't 100% fixable. So color me somewhat unimpressed that it's in the pipeline, even if it's more of a priority now than then.

[PatchWorKs]

HW acceleration was "coming" for H.264 and VC1 from at least 2004. The first demos weren't until 2005, public releases in early 2006, and they still weren't really bug-free until 2007. Plus you had to buy new hardware - then buy it again when it turned out the first generation wasn't 100% fixable. So color me somewhat unimpressed that it's in the pipeline, even if it's more of a priority now than then.

Well, i believe that WebM "supporters" push it more quickly:

http://www.webmproject.org/about/supporters/

[LigH]

@ foxyshadis:

I would like to. If I knew where to get the most recent ivf encoder with AviSynth support. I believe the ifvenc Nic mod version I have (June 2010) has lib 0.9.0, but I read lib 0.9.2 is out... Unfortunately it seems that Nic did not link his ivfenc mod on his website. So I possibly need to use ffmpeg then?

[sibvic]

ffmpeg nightly builds for windows: http://ffmpeg.arrozcru.org/autobuilds/blog/

[MasterNobody]

So has anyone had a chance to do a real quality comparison between the latest versions and the current x264? (Comparing at same bitrate and same encoding speed.) I'm really quite interested in how much the quality gap has narrowed over the summer.
Here is my small testing.

Participants:
VP8 0.9.0.0 (http://webm.googlecode.com/files/vpx-vp8-debug-src-x86-win32mt-vs8-v0.9.0.zip) released at 18.05.2010
VP8 0.9.1.1 (http://webm.googlecode.com/files/vpx-vp8-debug-src-x86-win32mt-vs8-v0.9.1.1.zip) released at 22.06.2010
VP8 0.9.2.0 (http://webm.googlecode.com/files/vpx-vp8-debug-src-x86-win32mt-vs8-v0.9.2.zip) released at 02.09.2010
x264 r900 (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=a9af9425820cfba99ae4b378c33c4fee4e99b2ce) released at 06.07.2008
x264 r1595 (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=c7876580bf822e63f1f77689218bfbbea4f9b9fc) released at 21.05.2010
x264 r1652 (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=4c27afb595ac8e8a621ffc2bf8120f0d43c80384) released at 24.06.2010
x264 r1713 (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=c27666276eb4d63b0c9ee2b9a375feabc27c8f4e) released at 03.09.2010

First sample for testing was park_joy_1080p.y4m (http://media.xiph.org/video/derf/y4m/1080p/park_joy_1080p.y4m) which was encoded at 8000 kbit/s bitrate. But at first sample was converted to raw yuv (so all versions can use one source file) with mencoder (mencoder x:\park_joy_1080p.y4m -ovc raw -of rawvideo -vf format=i420 -o x:\park_joy_1080p.yuv)
bat-file used for encoding:datetime -u +"%%D %%T" >vp8_0900.txt
ivfenc_0900 x:\park_joy_1080p.yuv vp8_0900.ivf -w 1920 -h 1080 --timebase=1/50 --target-bitrate=8000 --good --cpu-used=0 -t 8 -p 2 --end-usage=0 --undershoot-pct=100 --kf-max-dist=250 --drop-frame=0 --resize-allowed=0 --static-thresh=0 --auto-alt-ref=1 --lag-in-frames=16 --profile=0
datetime -u +"%%D %%T" >>vp8_0900.txt

datetime -u +"%%D %%T" >vp8_0911.txt
ivfenc_0911 x:\park_joy_1080p.yuv vp8_0911.ivf -w 1920 -h 1080 --timebase=1/50 --target-bitrate=8000 --good --cpu-used=0 -t 8 -p 2 --end-usage=0 --undershoot-pct=100 --kf-max-dist=250 --drop-frame=0 --resize-allowed=0 --static-thresh=0 --auto-alt-ref=1 --lag-in-frames=16 --profile=0
datetime -u +"%%D %%T" >>vp8_0911.txt

datetime -u +"%%D %%T" >vp8_0920.txt
ivfenc_0920 x:\park_joy_1080p.yuv vp8_0920.ivf -w 1920 -h 1080 --timebase=1/50 --target-bitrate=8000 --good --cpu-used=0 -t 8 -p 2 --end-usage=0 --undershoot-pct=100 --kf-max-dist=250 --drop-frame=0 --resize-allowed=0 --static-thresh=0 --auto-alt-ref=1 --lag-in-frames=16 --profile=0
datetime -u +"%%D %%T" >>vp8_0920.txt

datetime -u +"%%D %%T" >x264_0900.txt
x264_0900.exe -o x264_0900.h264 x:\park_joy_1080p.yuv 1920x1080 --fps 50/1 -B 7700 -p 1 -b 8 --b-pyramid --bime -w -r 16 --mixed-refs -A all --me umh --merange 24 --subme 7 --b-rdo --8x8dct -t 2 --threads auto --thread-input --no-psnr --no-ssim --progress
x264_0900.exe -o x264_0900.h264 x:\park_joy_1080p.yuv 1920x1080 --fps 50/1 -B 7700 -p 2 -b 8 --b-pyramid --bime -w -r 16 --mixed-refs -A all --me umh --merange 24 --subme 7 --b-rdo --8x8dct -t 2 --threads auto --thread-input --no-psnr --no-ssim --progress
datetime -u +"%%D %%T" >>x264_0900.txt

datetime -u +"%%D %%T" >x264_1595.txt
x264_1595.exe -o x264_1595.h264 x:\park_joy_1080p.yuv 1920x1080 --fps 50/1 -B 8000 -p 1 --slow-firstpass --preset veryslow -r 16 --aq-mode 2 --psy-rd 0:0
x264_1595.exe -o x264_1595.h264 x:\park_joy_1080p.yuv 1920x1080 --fps 50/1 -B 8000 -p 2 --preset veryslow -r 16 --aq-mode 2 --psy-rd 0:0
datetime -u +"%%D %%T" >>x264_1595.txt

datetime -u +"%%D %%T" >x264_1652.txt
x264_1652.exe -o x264_1652.h264 x:\park_joy_1080p.yuv 1920x1080 --fps 50/1 -B 8000 -p 1 --slow-firstpass --preset veryslow -r 16 --aq-mode 2 --psy-rd 0:0
x264_1652.exe -o x264_1652.h264 x:\park_joy_1080p.yuv 1920x1080 --fps 50/1 -B 8000 -p 2 --preset veryslow -r 16 --aq-mode 2 --psy-rd 0:0
datetime -u +"%%D %%T" >>x264_1652.txt

datetime -u +"%%D %%T" >x264_1713.txt
x264_1713.exe -o x264_1713.h264 x:\park_joy_1080p.yuv --input-res 1920x1080 --fps 50/1 -B 8000 -p 1 --slow-firstpass --preset veryslow -r 16 --aq-mode 2 --psy-rd 0:0
x264_1713.exe -o x264_1713.h264 x:\park_joy_1080p.yuv --input-res 1920x1080 --fps 50/1 -B 8000 -p 2 --preset veryslow -r 16 --aq-mode 2 --psy-rd 0:0
datetime -u +"%%D %%T" >>x264_1713.txt

datetime -u +"%%D %%T" >x264_1713psy.txt
x264_1713.exe -o x264_1713psy.h264 x:\park_joy_1080p.yuv --input-res 1920x1080 --fps 50/1 -B 8000 -p 1 --slow-firstpass --preset veryslow --tune film -r 16 --aq-mode 2
x264_1713.exe -o x264_1713psy.h264 x:\park_joy_1080p.yuv --input-res 1920x1080 --fps 50/1 -B 8000 -p 2 --preset veryslow --tune film -r 16 --aq-mode 2
datetime -u +"%%D %%T" >>x264_1713psy.txt
Results of encoding were muxed with MKVToolnix: park_joy_samples.rar (http://www.mediafire.com/?7rb9qb6kk554c41)
Average SSIM calculated with Elecard Video Quality Estimator:VP8 0.9.0.0 SSIM_Y: 0.7788, SSIM_U: 0.7851, SSIM_V: 0.7340, SSIM_YUV: 0.7749
VP8 0.9.1.1 SSIM_Y: 0.7815, SSIM_U: 0.7847, SSIM_V: 0.7310, SSIM_YUV: 0.7768
VP8 0.9.2.0 SSIM_Y: 0.7801, SSIM_U: 0.7849, SSIM_V: 0.7323, SSIM_YUV: 0.7758
x264 r900 SSIM_Y: 0.7939, SSIM_U: 0.7903, SSIM_V: 0.7373, SSIM_YUV: 0.7878
x264 r1595 SSIM_Y: 0.8406, SSIM_U: 0.8012, SSIM_V: 0.7606, SSIM_YUV: 0.8287
x264 r1652 SSIM_Y: 0.8403, SSIM_U: 0.8011, SSIM_V: 0.7605, SSIM_YUV: 0.8284
x264 r1713 SSIM_Y: 0.8415, SSIM_U: 0.8011, SSIM_V: 0.7607, SSIM_YUV: 0.8293
x264 r1713p SSIM_Y: 0.8250, SSIM_U: 0.8045, SSIM_V: 0.7725, SSIM_YUV: 0.8177
x264 r1713p = x264 r1713 + psy options

Second sample for encoding was part of BlackPearl DVD (Lossless H.264: BlackPearl.mkv (http://www.mediafire.com/?99gsnf4vbqfypcl)) which was encoded 2000 kbit/s bitrate. But at first sample was converted to raw yuv with avs2yuv.
bat-file used for encoding:
datetime -u +"%%D %%T" >vp8_0900.txt
ivfenc_0900 x:\BlackPearl_720x352.yuv vp8_0900.ivf -w 720 -h 352 --timebase=1001/24000 --target-bitrate=2000 --good --cpu-used=0 -t 8 -p 2 --end-usage=0 --undershoot-pct=100 --kf-max-dist=250 --drop-frame=0 --resize-allowed=0 --static-thresh=0 --auto-alt-ref=1 --lag-in-frames=16 --profile=0
datetime -u +"%%D %%T" >>vp8_0900.txt

datetime -u +"%%D %%T" >vp8_0911.txt
ivfenc_0911 x:\BlackPearl_720x352.yuv vp8_0911.ivf -w 720 -h 352 --timebase=1001/24000 --target-bitrate=2000 --good --cpu-used=0 -t 8 -p 2 --end-usage=0 --undershoot-pct=100 --kf-max-dist=250 --drop-frame=0 --resize-allowed=0 --static-thresh=0 --auto-alt-ref=1 --lag-in-frames=16 --profile=0
datetime -u +"%%D %%T" >>vp8_0911.txt

datetime -u +"%%D %%T" >vp8_0920.txt
ivfenc_0920 x:\BlackPearl_720x352.yuv vp8_0920.ivf -w 720 -h 352 --timebase=1001/24000 --target-bitrate=2000 --good --cpu-used=0 -t 8 -p 2 --end-usage=0 --undershoot-pct=100 --kf-max-dist=250 --drop-frame=0 --resize-allowed=0 --static-thresh=0 --auto-alt-ref=1 --lag-in-frames=16 --profile=0
datetime -u +"%%D %%T" >>vp8_0920.txt

datetime -u +"%%D %%T" >x264_0900.txt
x264_0900.exe -o x264_0900.h264 x:\BlackPearl_720x352.yuv 720x352 --fps 24000/1001 -B 1970 -p 1 -b 8 --b-pyramid --bime -w -r 16 --mixed-refs -A all --me umh --merange 24 --subme 7 --b-rdo --8x8dct -t 2 --threads auto --thread-input --no-psnr --no-ssim --progress
x264_0900.exe -o x264_0900.h264 x:\BlackPearl_720x352.yuv 720x352 --fps 24000/1001 -B 1970 -p 2 -b 8 --b-pyramid --bime -w -r 16 --mixed-refs -A all --me umh --merange 24 --subme 7 --b-rdo --8x8dct -t 2 --threads auto --thread-input --no-psnr --no-ssim --progress
datetime -u +"%%D %%T" >>x264_0900.txt

datetime -u +"%%D %%T" >x264_1595.txt
x264_1595.exe -o x264_1595.h264 x:\BlackPearl_720x352.yuv 720x352 --fps 24000/1001 -B 1990 -p 1 --slow-firstpass --preset veryslow -r 16 --aq-mode 2 --psy-rd 0:0
x264_1595.exe -o x264_1595.h264 x:\BlackPearl_720x352.yuv 720x352 --fps 24000/1001 -B 1990 -p 2 --preset veryslow -r 16 --aq-mode 2 --psy-rd 0:0
datetime -u +"%%D %%T" >>x264_1595.txt

datetime -u +"%%D %%T" >x264_1652.txt
x264_1652.exe -o x264_1652.h264 x:\BlackPearl_720x352.yuv 720x352 --fps 24000/1001 -B 1990 -p 1 --slow-firstpass --preset veryslow -r 16 --aq-mode 2 --psy-rd 0:0
x264_1652.exe -o x264_1652.h264 x:\BlackPearl_720x352.yuv 720x352 --fps 24000/1001 -B 1990 -p 2 --preset veryslow -r 16 --aq-mode 2 --psy-rd 0:0
datetime -u +"%%D %%T" >>x264_1652.txt

datetime -u +"%%D %%T" >x264_1713.txt
x264_1713.exe -o x264_1713.h264 x:\BlackPearl_720x352.yuv --input-res 720x352 --fps 24000/1001 -B 1990 -p 1 --slow-firstpass --preset veryslow -r 16 --aq-mode 2 --psy-rd 0:0
x264_1713.exe -o x264_1713.h264 x:\BlackPearl_720x352.yuv --input-res 720x352 --fps 24000/1001 -B 1990 -p 2 --preset veryslow -r 16 --aq-mode 2 --psy-rd 0:0
datetime -u +"%%D %%T" >>x264_1713.txt

datetime -u +"%%D %%T" >x264_1713psy.txt
x264_1713.exe -o x264_1713psy.h264 x:\BlackPearl_720x352.yuv --input-res 720x352 --fps 24000/1001 -B 1990 -p 1 --slow-firstpass --preset veryslow --tune film -r 16 --aq-mode 2
x264_1713.exe -o x264_1713psy.h264 x:\BlackPearl_720x352.yuv --input-res 720x352 --fps 24000/1001 -B 1990 -p 2 --preset veryslow --tune film -r 16 --aq-mode 2
datetime -u +"%%D %%T" >>x264_1713psy.txt
Results of encoding were muxed with MKVToolnix: BlackPearl_samples.rar (http://www.mediafire.com/?7rb9qb6kk554c41)
Average SSIM calculated with Elecard Video Quality Estimator:
VP8 0.9.0.0 SSIM_Y: 0.9796, SSIM_U: 0.9827, SSIM_V: 0.9759, SSIM_YUV: 0.9796
VP8 0.9.1.1 SSIM_Y: 0.9798, SSIM_U: 0.9827, SSIM_V: 0.9760, SSIM_YUV: 0.9797
VP8 0.9.2.0 SSIM_Y: 0.9797, SSIM_U: 0.9828, SSIM_V: 0.9762, SSIM_YUV: 0.9797
x264 r900 SSIM_Y: 0.9822, SSIM_U: 0.9767, SSIM_V: 0.9687, SSIM_YUV: 0.9803
x264 r1595 SSIM_Y: 0.9858, SSIM_U: 0.9819, SSIM_V: 0.9754, SSIM_YUV: 0.9844
x264 r1652 SSIM_Y: 0.9858, SSIM_U: 0.9818, SSIM_V: 0.9754, SSIM_YUV: 0.9844
x264 r1713 SSIM_Y: 0.9859, SSIM_U: 0.9818, SSIM_V: 0.9753, SSIM_YUV: 0.9845
x264 r1713p SSIM_Y: 0.9828, SSIM_U: 0.9844, SSIM_V: 0.9791, SSIM_YUV: 0.9826
x264 r1713p = x264 r1713 + psy options

P.S. I wouldn't make any conclusions or screenshots, look at the encoded samples yourself.

[LigH]

WebM is not yet exciting.

I tested different ways to create a recode of Blender movies (with a reduced dimension). But trying to get a subjective impression of the possible quality, I already had issues with the playback, even in different players.

I used the following software:

webmdshow-0.9.10.0-20100809
IVFEnc 1.5 (AVS input mod by Nic; 2010-06-07)
ffmpeg-latest-mingw32-static (arrozcru.org; 2010-09-11) - incl. ffplay
some tools used by MeGUI 0.3.5.10: MP4Box (2010-04-10), x264 core:104 r1713 c276662, mkvmerge 4.3.0
AviSynth 2.58
BeHappy 0.2.4.20767 (2009-10-11) with OggEnc v2.87 (libvorbis 1.3.1) and NeroAacEnc 1.1.34.2
mpc-homecinema.1.4.2530_(x86)_msvc2010 (xvidvideo.ru)
ffdshow_rev3567_20100909_icl11 (xvidvideo.ru)
VLC media player 1.1.4

Just for convenience and speedup, I created an internediate AVC file with 1080p resolution via ImageSource because reading single PNGs is already the slowest part. This I used as "good-enough master", scaled down to 640×360 pixels, to feed the AVC and IVF encoders in 2-pass encoding with 700 kbps. Audio was converted from the AC3 audio stream of the AVI version, using BeHappy with NicAudio (DRC activated), normalization to 95% and DPL II + LFE downmix, with quality 2 for OggEnc2 and quality 0.3 for NeroAacEnc, to get similar-sized results.

At home I have only an Athlon X2 3800+ and a GeForce 6800 available, so I used the DGAVCDecDI version of the AviSynth source script, and auto or 2 thread encoding.

(In the office I can use a Phenom-II X4 945 and a GeForce 9600 available, so I may use a DGDecNV version of the AviSynth source script, and auto or 4 thread encoding...)

BBB_0360_700_avc.bat
E:\Programme\MeGUI\tools\x264\x264.exe --pass 1 --bitrate 700 --preset slower --thread-input --output BBB_0360_700.mp4 BBB_0360_DI.avs
E:\Programme\MeGUI\tools\x264\x264.exe --pass 2 --bitrate 700 --preset slower --thread-input --output BBB_0360_700.mp4 BBB_0360_DI.avs
E:\Programme\MeGUI\tools\mp4box\MP4Box.exe BBB_0360_700.mp4 -add BBB.m4a

BBB_0360_700_ivf.bat
E:\Programme\ivfenc\ivfenc.exe --codec=vp8 --passes=2 --pass=1 --fpf=BBB_0360.stats --best --threads=1 --token-parts=1 --end-usage=0 --target-bitrate=700 BBB_0360_DI.avs BBB_0360_700.ivf
E:\Programme\ivfenc\ivfenc.exe --codec=vp8 --passes=2 --pass=2 --fpf=BBB_0360.stats --best --threads=1 --token-parts=1 --end-usage=0 --target-bitrate=700 BBB_0360_DI.avs BBB_0360_700.ivf
E:\Programme\MKVtoolnix\mkvmerge.exe -o BBB_0360_700.webm -w BBB_0360_700.ivf BBB.ogg

BBB_0360_700_ffm.bat
E:\Programme\ffmpeg\bin\ffmpeg.exe -y -i BBB_0360_DI.avs -vb 700k -level 100 -pass 1 -f webm NUL
E:\Programme\ffmpeg\bin\ffmpeg.exe -y -i BBB_0360_DI.avs -i BBB.ogg -acodec copy -vb 700k -level 100 -pass 2 BBB_0360_700_ffm.webm

Overall, the quality was not bad, although artifacts are easily recognisable. No surprise, the appearance of AVC and VP8 artifacts differs - there are scenes where one of both is worse, and it was not always VP8. At least in my opinion.

But the ability to play the results differed a lot:

BBB_0360_700.mp4

Opera 10.62: not displayed
MPC-HC: OK
VLC: OK
ffplay: OK


BBB_0360_700.webm (ifvenc, mkvmerge -w)

Opera 10.62: video and audio play OK, seekable in general (long delays during the ending cast)
MPC-HC (internal Matroska splitter disabled): video plays for ~9 seconds, audio choppy - then a race to the end of the file, replay not possible
MPC-HC (internal Matroska splitter enabled): video and audio play OK, seekable to distinct positions except the ending cast
VLC: video and audio play OK, seekable to distinct positions except the ending cast
ffplay: video and audio play OK, seekable to distinct positions but skips the ending cast


BBB_0360_700_ffm.webm (ffmpeg alone)

Opera 10.62: video plays smooth, audio choppy (~0.4 sec steps), seeking works almost anywhere
MPC-HC (internal Matroska splitter disabled): audio plays smooth, video choppy (~0.4 sec steps), seeking works when pulling the grabber, not when clicking
MPC-HC (internal Matroska splitter enabled): audio plays smooth, video choppy (~0.4 sec steps), seeking works almost anywhere
VLC: video plays smooth, audio choppy (~0.4 sec steps), seeking works almost anywhere
ffplay: video and audio play OK, seekable to distinct positions even during the ending cast


Want to test yourself? -- http://www.ligh.de/WebM/

[Reimar]

E:\Programme\ivfenc\ivfenc.exe --codec=vp8 --passes=2 --pass=1 --fpf=BBB_0360.stats --best --threads=1 --token-parts=1 --end-usage=0 --target-bitrate=700 BBB_0360_DI.avs BBB_0360_700.ivf
E:\Programme\ivfenc\ivfenc.exe --codec=vp8 --passes=2 --pass=2 --fpf=BBB_0360.stats --best --threads=1 --token-parts=1 --end-usage=0 --target-bitrate=700 BBB_0360_DI.avs BBB_0360_700.ivf
E:\Programme\MKVtoolnix\mkvmerge.exe -o BBB_0360_700.webm -w BBB_0360_700.ivf BBB.ogg
MPC-HC (internal Matroska splitter enabled): video and audio play OK, seekable to distinct positions except the ending cast


You did not set --kf-max-dist, thus you will only be able to seek (efficiently) to whatever the encoder detects as scene changes.
While I'd expect it isn't hard to find real issues, and I think ivfenc uses a bad default here, this one is a case of not knowing your tools...

[LigH]

Obviously, yes ... I am possibly too used to relying on sane defaults (x264 is a good example, in contrast).

This is a good hint, I will recreate the files with the suggested option, many thanks!

So there are possibly only two issues left:

a) "usual" multiplexer issues with ffmpeg (like with mp4 too)

b) pro and con internal Matroska splitter of MPC-HC - why the hell is it required at all, is the WebM DS Filter not enough? ... Was my Haali Media Splitter too old?! :o

[Sharktooth]

the ifvenc version plays ok on chrome for linux as well as the x264 version. the webm created by ffmpeg is choppy though...

[LigH]

Not only choppy, also MPC-HC reports dropping lots of frames. Probably a similar issue to the MP4 B-frame multiplexing bug in the ffmpeg multiplexer.

[ricardo.santos]

VP8 VFW Codec released
http://www.optimasc.com/products/vp8vfw/index.html

@Nic
Will you continue updating your ivfenc with avs support version? There's been a new (non avs) version around for a while. I know there's ffmpeg but the bitrate problem (oversizing) has not been solved.

Does anyone know if mencoder will support vp8/webm? I remember someone saying there was some incompatibilities between mencoder and vp8, any news?

[LigH]

Not only a bitrate problem, but also a multiplexer issue in ffmpeg (^ #374).

I am not certain if Nic regularly reads here... :( -- And noone else yet was able to build a working encoder with vpx 0.9.2 + Nic's source patch?

[ricardo.santos]

Not only a bitrate problem, but also a multiplexer issue in ffmpeg (^ #374).
i wasnt aware of the multiplexer issue as i'm using nic's ivfenc version for my encodes/testing because ffmpeg kept oversizing my encodes.

It seems that after the initiall "rush" things are slowing down.

[Reimar]

Does anyone know if mencoder will support vp8/webm? I remember someone saying there was some incompatibilities between mencoder and vp8, any news?

It should be working fine mostly (never tested myself though). Due to their stupid design choice you can't properly use "alternate reference frames", but that should also be the case for the VFW codec and even for FFmpeg to a degree. Unless they decided to go for a sane design by now (sane as in "will work with more than their own encoder implementation and framework").

[Sharktooth]

a sane design is not even possible due to mpeg patents...

[Reimar]

a sane design is not even possible due to mpeg patents...

In this case it's rather that a sane design is possible due to avoiding MPEG patents. Packed B-frames is quite a messy hack, however the same approach would have worked quite fine for alternate keyframes, would not really have been a hack and probably would have worked better for about 99% of use cases (and I doubt it would have been a real issue for the remaining 1%).

[Kurtnoise]

Does anyone have try makewebm app w/ avisynth scripts as input ?

[J_Darnley]

You mean something like ffmpeg?

[Kurtnoise]

Not exactly...makewebm uses directshow filters to encode A/V streams.

http://review.webmproject.org/gitweb?p=webmdshow.git;a=tree

[LigH]

Rather something like the sourcepatch from http://nic.dnsalias.com/ivfenc.zip used with the VPX library 0.9.2 ... I remember 'Selur' tried that but the result didn't work, kept crashing.

[Kurtnoise]

both makewebm & vpxenc (ivfenc's name doesn't exist anymore) use libvpx to encode in VP8. So...

[valgor]

v0.9.5 "Aylesbury" is released
http://code.google.com/p/webm/downloads/list

CHANGELOG since v0.9.2


2010-10-28 v0.9.5 "Aylesbury"
Our first named release, focused on a faster decoder, and a better encoder.

- Upgrading:
This release incorporates backwards-incompatible changes to the
ivfenc and ivfdec tools. These tools are now called vpxenc and vpxdec.

vpxdec
* the -q (quiet) option has been removed, and replaced with
-v (verbose). the output is quiet by default. Use -v to see
the version number of the binary.

* The default behavior is now to write output to a single file
instead of individual frames. The -y option has been removed.
Y4M output is the default.

* For raw I420/YV12 output instead of Y4M, the --i420 or --yv12
options must be specified.

$ ivfdec -o OUTPUT INPUT
$ vpxdec --i420 -o OUTPUT INPUT

* If an output file is not specified, the default is to write
Y4M to stdout. This makes piping more natural.

$ ivfdec -y -o - INPUT | ...
$ vpxdec INPUT | ...

* The output file has additional flexibility for formatting the
filename. It supports escape characters for constructing a
filename from the width, height, and sequence number. This
replaces the -p option. To get the equivalent:

$ ivfdec -p frame INPUT
$ vpxdec --i420 -o frame-%wx%h-%4.i420 INPUT

vpxenc
* The output file must be specified with -o, rather than as the
last argument.

$ ivfenc <options> INPUT OUTPUT
$ vpxenc <options> -o OUTPUT INPUT

* The output defaults to webm. To get IVF output, use the --ivf
option.

$ ivfenc <options> INPUT OUTPUT.ivf
$ vpxenc <options> -o OUTPUT.ivf --ivf INPUT


- Enhancements:
ivfenc and ivfdec have been renamed to vpxenc, vpxdec.
vpxdec supports .webm input
vpxdec writes .y4m by default
vpxenc writes .webm output by default
vpxenc --psnr now shows the average/overall PSNR at the end
ARM platforms now support runtime cpu detection
vpxdec visualizations added for motion vectors, block modes, references
vpxdec now silent by default
vpxdec --progress shows frame-by-frame timing information
vpxenc supports the distinction between --fps and --timebase
NASM is now a supported assembler
configure: enable PIC for shared libs by default
configure: add --enable-small
configure: support for ppc32-linux-gcc
configure: support for sparc-solaris-gcc

- Bugs:
Improve handling of invalid frames
Fix valgrind errors in the NEON loop filters.
Fix loopfilter delta zero transitions
Fix valgrind errors in vp8_sixtap_predict8x4_armv6().
Build fixes for darwin-icc

- Speed:
20-40% (average 28%) improvement in libvpx decoder speed,
including:
Rewrite vp8_short_walsh4x4_sse2()
Optimizations on the loopfilters.
Miscellaneous improvements for Atom
Add 4-tap version of 2nd-pass ARMv6 MC filter.
Improved multithread utilization
Better instruction choices on x86
reorder data to use wider instructions
Update NEON wide idcts
Make block access to frame buffer sequential
Improved subset block search
Bilinear subpixel optimizations for ssse3.
Decrease memory footprint

Encoder speed improvements (percentage gain not measured):
Skip unnecessary search of identical frames
Add SSE2 subtract functions
Improve bounds checking in vp8_diamond_search_sadx4()
Added vp8_fast_quantize_b_sse2

- Quality:
Over 7% overall PSNR improvement (6.3% SSIM) in "best" quality
encoding mode, and up to 60% improvement on very noisy, still
or slow moving source video

Motion compensated temporal filter for Alt-Ref Noise Reduction
Improved use of trellis quantization on 2nd order Y blocks
Tune effect of motion on KF/GF boost in two pass
Allow coefficient optimization for good quality speed 0.
Improved control of active min quantizer for two pass.
Enable ARFs for non-lagged compress

[LigH]

... so someone who understands libvpx could write his very own WebM encoder, instead of "simply" patching the vpxenc source to support VfW input? -- But I would be happy about the second option already.

[Kurtnoise]

you can create fake avis within makeAVI tool from FFdshow to test the last release if you want to...This tool is able to create avi from avs input.

[oibaf]

More info on 0.9.5 release: VP8 Codec SDK "Aylesbury" Release (http://blog.webmproject.org/2010/10/vp8-codec-sdk-aylesbury-release.html).

Some images from the post:
http://1.bp.blogspot.com/_t-XchACWDN0/TMieWyMrIhI/AAAAAAAAADU/9lB0XGyAvuI/s1600/speed.pnghttp://3.bp.blogspot.com/_t-XchACWDN0/TMie_0MtVMI/AAAAAAAAADY/LvwcKNkKcg4/s1600/psnr.pnghttp://1.bp.blogspot.com/_t-XchACWDN0/TMifY2n19iI/AAAAAAAAADc/AFzqutWgMII/s1600/ssim.png

[LigH]

I know makeAVIS ... but it might not help. The help file only mentions Y4M or raw YV12/I420, so not even AVI support. I would have to pipe video from ffmpeg into vpxenc, I fear.

Furthermore, the output of vpxenc is really stupid: Captions are sent to stderr, parameters to stdout. Let's shuffle the deck?!

I have a feeling that Google does not really care about getting it used by amateur video authors.
__

Maybe people will use the VfW codec by Optima SC (http://www.optimasc.com/products/vp8vfw/index.html) once it is updated to libvpx 0.9.5; then they could convert the resulting AVI with mkvmerge. Provided that mkvmerge detects the video source. If it expects raw *.ivf though ... another dead end.

[hajj_3]

i wonder what Dark Shikari's opinion of the 0.9.5 version of VP8 are and if any benefits will be added to the version in FFmpeg

[iwod]

While i love the idea of a No Patents Video Codec that offer decent quality. There are so many things lacking that i think forcing MPEG-LA to lower or get free loyalty would be a easier solution. MPEG - LA and those companies has earned enough on those patents anyway.

No Hardware Acceleration being the worst disadvantage.

[Sharktooth]

HW acceleration for WebM is planned by major companies... including AMD and Nvidia....

[Sirber]

I updated BENCOS with webm support (via ffmpeg). The presets are in fact only playing with the "-level" param.

http://code.google.com/p/bencos/

[zambelli]

While i love the idea of a No Patents Video Codec that offer decent quality
That should really be changed to "patent free until challenged in court". There's no such thing as a patent free DCT-based video codec.

[oibaf]

That should really be changed to "patent free until challenged in court". There's no such thing as a patent free DCT-based video codec.

Until someone files and wins a lawsuit the There's no such thing as a patent free DCT-based video codec is only and nothing more than FUD (http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt).

And until now (6 months after initial open source release of patent free VP8 (May 2010), over 9 years after initial open source release of patent free VP3 (September 2001), now theora and over 10 years after the finalization of the patent free vorbis bitstream) no one filed any lawsuit as promised so that's indeed just FUD. On top of that MPEG-LA and Apple rather then suing Xiph.org and Google (after spreading FUD that they use their patents) on 2010-08-26 they removed the fees for distributing H.264 files (http://www.mpegla.com/Lists/MPEG%20LA%20News%20List/Attachments/231/n-10-08-26.pdf), so one could argue that they really fear VP8 but still didn't/can't sue.

Obliviously nobody can predict what will happen in the future. In the meantime please stop spreading more FUD. Thanks.