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

wiak

15th June 2010, 09:34

I'm pretty sure they are just gunna fix the bugs and clean up the code for the next few weeks atleast, hopefully then they will try to improve speed and quality.
they are doing a rewrite of the crappy current decoder as its said in the code review post

btw dont underestimate google, have you seen how android went from what to wow in around year?

hajj_3

15th June 2010, 09:44

yeah android is very nice indeed, its hard to guess how much they can improve VP8 without violating patents, only time will tell i guess. Judging from the issues list on google's bug tracker it seems that there are quite alot of bugs in the current code with new flaws found daily, i'm sure in 2 months time there will be a stable version of VP8 with cleaner code and then they can start improving the speed and quality.

wiak

15th June 2010, 12:05

hajj_3

15th June 2010, 15:35

new blog update from google: http://webmproject.blogspot.com/2010/06/vp8-codec-optimization-update.html#more

Astrophizz

15th June 2010, 22:13

IgorC

16th June 2010, 03:37

Don't know nothing of the level of complexity and realizability as to do a workaround to support both older streams and future clean specification but it looks enough optimal.

oibaf

16th June 2010, 09:09

hellfred

16th June 2010, 12:28

looks like google is working on a new decoder
No need to wait for google to finish their decoder #2. FFmpeg already got a (patch for a) native VP8 decoder, which out-performs the (classic) decoder of libvpx! It will be avail in all FFmpeg powered applications very soon (see reply of Mr. FFmpeg aka Michael Niedermayer)...
Announcement of FFmpeg devel list (http://article.gmane.org/gmane.comp.video.ffmpeg.devel/111538)
Patch history (http://github.com/yuvi/ffmpeg/commits/vp8)

dapperdan

16th June 2010, 13:15

Hopefully they will open up to making fixes that change the bitstream :/ I'm sure you've seen their statement that they don't want to implement some fixes/improvements because they've already encoded a number of videos...

Could you point me to that statement?

While it was portrayed that way in the x264 developer's write up, if you actually followed the link provided you'll see that they didn't want to implement a fix found within 48 hours of the launch until after the launch so that they had time to do the re-encode.

Astrophizz

17th June 2010, 00:12

Hmm, well I know I spotted the email in the mailing list a few weeks back but I can't seem to find it. I think it was in regards to the MV bounds issue From what I've seen with the implementation of a branch for bitstream changes you might be right. Of course this will cause an issue with hardware developers...

Edit: Here it is https://groups.google.com/a/webmproject.org/group/codec-devel/msg/e10111e2f5ba0660
I don't know how waiting made it any easier to resolve but I guess they didn't want to look like fools. That whole thread is interesting. The issue with hardware developers and already encoded streams poses a big issue I think.

foxyshadis

17th June 2010, 03:13

I would think hardware developers go into these kinds of arrangements expecting to be thrown under the bus at some point. It always happens that someone implements a broken creator, silently fixes it, and then the reader has to put up with multiple unofficial "extensions" of the spec, the same way that the creators know they'll eventually have to code around bugs & limitations in readers.

buzzqw

17th June 2010, 07:02

@Nic

would be possible to add to official ivfenc trunk the avs support sending a patch to webm developers ?

if so we will have a working avs support out of the box

thanks

BHH

wiak

17th June 2010, 07:50

@Nic

would be possible to add to official ivfenc trunk the avs support sending a patch to webm developers ?

if so we will have a working avs support out of the box

thanks

BHH
:stupid:
should be simple just add the code to report ;)
http://code.google.com/p/webm/issues/entry

hajj_3

17th June 2010, 22:44

great news: http://webmproject.blogspot.com/2010/06/future-of-vp8-bitstream.html

They are accepting improvements to create a VP9, great news:) Can't see it beating x264 anytime soon but if they can make it beat h264 that would be fantastic:)

Atak_Snajpera

17th June 2010, 23:07

Can't see it beating x264 anytime soon but if they can make it beat h264 that would be fantastic
x264 is implementation of h.264 standard ;) Also they have to omit any patents.

wiak

17th June 2010, 23:20

x264 is implementation of h.264 standard ;) Also they have to omit any patents.
WebM needs a army of lawyers to avoid patents

x264 dont need a army of lawyers, and can basicly just implement without regard

there is a reason why there is no official x264 binaries out, why? they cant redistribute precompiled binaires due to royalties/lisense/patents

hajj_3 old news if you have checked the http://review.webmproject.org site in the last week or so :P

CruNcher

18th June 2010, 02:20

http://groups.google.com/a/webmproject.org/group/webm-discuss/browse_thread/thread/5b841bce1c4e4948#

Midzuki

18th June 2010, 02:46

Question:

there is a reason why there is no official x264 binaries out, why? they cant redistribute precompiled binaires due to royalties/lisense/patents

Answer:

The reason there are no official binaries is that I haven't bothered to figure out how to make a .deb or .rpm, and if you're not using a packaging system you can just compile it yourself. It has nothing to do with licensing.

:) :p :D

Selur

18th June 2010, 12:31

Looking at ivfenc I wonder is there some overview somewhere which states which min, max and defaults values are set?

wiak

18th June 2010, 12:33

Looking at ivfenc I wonder is there some overview somewhere which states which min, max and defaults values are set?
some of them says it at http://www.webmproject.org/tools/encoder-parameters/ , but there are also sample parameters at http://www.webmproject.org/tools/encoder-parameters/

CruNcher

19th June 2010, 01:17

Though you shouldn't trust the Encode Parameters Especially the 1 pass examples are wrong :P

Selur

19th June 2010, 08:12

Was anyone successful in feeding ivfenc via pipe from mencoder?
I tried:
mencoder -dvd-device "D:\ElephantsDream\VIDEO_TS" dvd://1 -ovc raw -noskip -vc mpeg12 -vf scale,format=i420 -forcedsubsonly -nosound -mc 0 -lavdopts threads=8 -really-quiet -fps 25 -aspect 1.7775:1 -of rawvideo -o - \
| ivfenc --passes=1 --pass=1 --target-bitrate=1500 --width=720 --height=576 --timebase=1/25 --i420 - "D:\Encoding Temp\Title_1_1-8.vp8"
but ivfenc keeps complaining about: Error in piped Y4M input - not recognised as Y4M
(using the ivfenc version from Nic: IVFEnc - VP8 Encoder - Nic's AviSynth Input Mod v1.5 (Jun 7 2010))

Cu Selur

Gser

20th June 2010, 13:43

Google adds 'experimental' branch to VP8 source code tree

Google is encouraging developers to work on the next incarnation of its now-open sourced VP8 video codec, acquired from On2 technologies last year in a $124.6 million deal and an integral part of Google's WebM project.

"To maintain codec stability while also allowing for quality and performance improvements in VP8, we have added an experimental branch to the VP8 source tree," said Google codec engineering manager Jim Bankoski.

"The WebM community can use this unstable branch to propose changes to VP8 that will produce the best video codec possible, but without the constraints of a frozen bitstream. At some point in the future, when the experimental branch proves significantly better than the stable branch, we will create a new version of the codec."

Mozilla and Opera have officially put their weight behind the WebM royalty-free format, while Microsoft has said Internet Explorer 9 will support WebM once a user installs VP8. Apple's Steve Jobs has hinted that Safari will stick to H.264 video content.

Various Google partners are currently working on hardware acceleration for VP8, and Bankoski said they are committed to providing the hardware sometime next year.

"Devices that use hardware acceleration for video are a very small percentage of overall web traffic today, but they are a rapidly growing segment of the market and our project must be mindful of these vendors' needs," Bankoski wrote.

rernst

20th June 2010, 23:31

At the danger of being redundant - same here.

Was anyone successful in feeding ivfenc via pipe from mencoder?
I tried:
mencoder -dvd-device "D:\ElephantsDream\VIDEO_TS" dvd://1 -ovc raw -noskip -vc mpeg12 -vf scale,format=i420 -forcedsubsonly -nosound -mc 0 -lavdopts threads=8 -really-quiet -fps 25 -aspect 1.7775:1 -of rawvideo -o - \
| ivfenc --passes=1 --pass=1 --target-bitrate=1500 --width=720 --height=576 --timebase=1/25 --i420 - "D:\Encoding Temp\Title_1_1-8.vp8"
but ivfenc keeps complaining about: Error in piped Y4M input - not recognised as Y4M
(using the ivfenc version from Nic: IVFEnc - VP8 Encoder - Nic's AviSynth Input Mod v1.5 (Jun 7 2010))

Cu Selur

valgor

21st June 2010, 06:48

Mencoder do not produces yuv4mpeg.
"-of rawvideo" gives you the just raw video stream, without y4m skeleton. and ivfenc tells you this fact.

Selur

21st June 2010, 15:44

Thanks, got it working with:
mencoder -dvd-device "D:\ElephantsDream\VIDEO_TS" dvd://1 -ovc raw -noskip -vc mpeg12 -vf scale,format=i420 -forcedsubsonly -nosound -mc 0 -lavdopts threads=8 -really-quiet -fps 25 -aspect 1.7775:1 -of rawvideo -o - | \
ffmpeg -v -10 -threads 8 -r 25 -pix_fmt yuv420p -s 720x576 -f rawvideo -i - -an -r 25 -f yuv4mpegpipe - | \
ivfenc --passes=1 --pass=1 --target-bitrate=1500 --width=720 --height=576 --timebase=1/25 --i420 - "D:\Encoding Temp\Title_1_1-8.vp8"

rernst

21st June 2010, 15:48

In that case - why don't you cut mencoder out altogether? ffmpeg has native VP8 support in 0.6 (and it works, I tried it).

Selur

21st June 2010, 16:21

This was maily a small test, normally I do some filtering&Co with mencoder (e.g. deinterlacing) but that aside if you can tell me how to open a dvd with ffmpeg I would probably use it more but afaik ffmpeg doesn't support DVD input.
I could drop ivfenc, but first for that I would need some infos how the ivfenc settings match to ffmpeg. (to be frank I will probably stick with infenc since it's easier and faster to compile a new ivfenc build than a ffmpeg, but a ivfcenc->ffmpeg mapping would be interesting)

rernst

21st June 2010, 17:01

This from the patch that implements it into ffmpeg:

+{"spatial_rsmpl", "Enable spatial resampling (VP8)", OFFSET(spatial_rsmpl), FF_OPT_TYPE_INT, 0, 0, 1, V|E},
+{"spatial_rsmpl_up", "Spatial resampling up watermark, percentage of target data buffer. (VP8)", OFFSET(spatial_rsmpl_up), FF_OPT_TYPE_INT, 60, 0, 100, V|E},
+{"spatial_rsmpl_down", "Spatial resampling down watermark, percentage of target data buffer. (VP8)", OFFSET(spatial_rsmpl_down), FF_OPT_TYPE_INT, 30, 0, 100, V|E},
+{"vbr_bias", "Two-pass mode CBR/VBR bias, 0-100 (VP8)", OFFSET(vbr_bias), FF_OPT_TYPE_INT, 50, 0, 100, V|E},
+{"lag", "Allow lagged encoding, given as frames (VP8)", OFFSET(lag), FF_OPT_TYPE_INT, 0, 0, INT_MAX, V|E},
+{"sharpness", "[0-7] (VP8)", OFFSET(sharpness), FF_OPT_TYPE_INT, 0, 0, 7, V|E},
+{"altref", "Allow use of alternate reference frame", OFFSET(altref), FF_OPT_TYPE_INT, 0, 0, 1, V|E},
+{"ar_max_frames", "Max frames used in creating alt. ref. [0,25]", OFFSET(ar_max_frames), FF_OPT_TYPE_INT, 0, 0, 25, V|E},
+{"ar_type", "Filter type used in creating alt. ref.", OFFSET(ar_type), FF_OPT_TYPE_INT, 0, 0, INT_MAX, V|E},
+{"ar_strength", "Filter strength used in creating alt. ref. [0,6]", OFFSET(ar_strength), FF_OPT_TYPE_INT, 0, 0, 6, V|E},
+{"mb_static_threshold", "", OFFSET(mb_static_threshold), FF_OPT_TYPE_INT, 800, 0, INT_MAX, V|E},
+{"rc_opt_occupancy", "number of bits which should be kept in the rc buffer during decoding", OFFSET(rc_optimal_buffer_occupancy), FF_OPT_TYPE_INT, DEFAULT, INT_MIN, INT_MAX, V|E},
+{"token_partitions", "Number of sub-streams in bitstream (1,2,4,8).*Used for parallelized decoding.", OFFSET(token_partitions), FF_OPT_TYPE_INT, 1, 1, INT_MAX, V|E},

CruNcher

21st June 2010, 17:13

don't they use the --level --cpu-used combined maping anymore ? and is --cpu-used default still 3 ?

rernst

21st June 2010, 17:28

Not sure. I don't know whether you read code but should be able to be gleaned from the patch files - but I haven't perused them all.

ricardo.santos

21st June 2010, 20:33

In that case - why don't you cut mencoder out altogether? ffmpeg has native VP8 support in 0.6 (and it works, I tried it).

3 reasons:

1- ffmpeg doesnt handle external subs
-sub teste.srt -font "arialbd.ttf" -subcp ISO-8859-15 -subfont-autoscale 2 -subfont-text-scale 4 -subpos 85

2- ffmpeg doesnt respect the bitrate choosen by the user, theres 2 threads here on doom9 about it, did you manage to fix it or get a way for it not to oversize?

3- mencoder has some resizing magic, (-vf scale=480:-10 - i used this when i needed to convert to flv), if i "tell" it that i want the width to be 480 it it will automatically get the height and maintain the aspect ratio

@Selur

can you give an example on to pipe to ivfenc from mencoder with a mp4 or avi file as source?
Ps: just noticed your example uses ffmpeg...so you're piping from mencoder to ffmpeg that then pipes to ivfenc? i guess i'll wait for a "proper" mencoder build with vp8 for windows, i've seen some linux ones while googling.

rernst

21st June 2010, 21:50

Well, 1.) isn't really an issue for me but if it is for you, of course. Since I really don't use ffmpeg but mencoder I am not aware of particular bugs. Mind you, I am not the coder or one of the coders, I just compile the stuff from source and occasionally fix a couple of lines... For 3.) I wrote my own frontend so that sort of calculation wasn't an issue as my GUI does it.

As for the MP4 or AVI - I used ffmpeg pure for the whole conversion. Since it uses libvpx for the conversion altogether it should respect bitrate for that just like ivfenc because both hand it off to the same encoder with the same parameters.

I had an email exchange with Reimar (mencoder) and would like to find out why they don't use the webm patch that integrates libvpx into mencoder which would make the whole thing superfluous.

rernst

21st June 2010, 21:58

Btw, Reimar came back and said that the VP8 support as patched (CFR) should work in native mencoder (which I so far could not get to work using acodec=libvpx) but he indicated it would be a bug if it didn't so I presume they would accept a bug report against it.

rernst

22nd June 2010, 20:33

There was a small bug in the ./configure script and now mencoder natively encodes vpx (-ovc lavf -lavcopts vcodec=libvpx). Right now it isn't in svn (at least in the last 20 minutes) so I think you can save yourself the whole piping just by running mencoder as is. If you need a windows binary, let me know.

Selur

22nd June 2010, 20:36

Nice, will wait until it hits svn before I try it. :)

ricardo.santos

23rd June 2010, 00:25

If you need a windows binary, let me know.

Altough the comment wasn't directed at me, i'm interested (and a whole lot of mencoder fans outhere) in a windows build, can you share it?

Thanks

hellfred

23rd June 2010, 07:24

The native VP8 decoder was added (http://git.ffmpeg.org/?p=ffmpeg;a=commit;h=49fb632ffa43a44f2e339362ffaa844eef11fbea) to the FFmpeg codebase.
It is bitexact compared to libvpx unless the bilinear filter feature is used in the clip. The reason for this is that the feature is not covered in the VP8 specifications provided by google. The feature will be added (http://article.gmane.org/gmane.comp.video.ffmpeg.devel/112027) as soon as the specification are extended accordingly.
SMD optimizations to get the decoder even faster are already in review process.

hajj_3

23rd June 2010, 08:08

WebM/VP8 has been added to MPC-HC now as of build 2071: http://www.xvidvideo.ru/media-player-classic-home-cinema-x86-x64/media-player-classic-homecinema-x86-x64-svn-2071.html

buzzqw

23rd June 2010, 08:24

i have missed announcing the AutoWebM gui !

http://forum.doom9.org/showthread.php?t=155256

BHH

rernst

23rd June 2010, 18:32

Altough the comment wasn't directed at me, i'm interested (and a whole lot of mencoder fans outhere) in a windows build, can you share it?

Thanks

I just posted a rush build here (http://24hourloop.com/downloads/cat_view/18-code). I will look at the mentioned outstanding issue as I just was told how to pass the encoding options. You can pass mencoder using -lavcopts o= all ffmpeg options, such as bt=, threads= and what not.

Again, this is experimental and I will have something solid later. I will also add webm support to YAMF in the next couple of days. Personally and for myself I prefer to multiplex into Matroska which plays back fine if you have the Directshow codec installed plus splitter, etc.

I have not tested this under Linux and normally don't post Linux builds as they are much more trivial to produce. VP8 ffmpeg builds here: http://ffmpeg.arrozcru.org/builds/

I don't think the ones at sourceforge support it, yet.

dott

23rd June 2010, 18:59

Altough the comment wasn't directed at me, i'm interested (and a whole lot of mencoder fans outhere) in a windows build, can you share it?

Thanks

http://oss.netfarm.it/mplayer-win32.php

It has been there for some days

I don't test mencoder yet...

rernst

23rd June 2010, 19:20

http://oss.netfarm.it/mplayer-win32.php

It has been there for some days

I don't test mencoder yet...
I don't think that build has a working *encoder* yet. There was a bug in the ./configure script which only built the decoder but not the encoder.

ricardo.santos

23rd June 2010, 21:03

@rernst
can´t download the file

if possible can anyone help me "translate" the following but using vp8 as the encoder, this is what i used for FLV.

mencoder.exe video.avi -o out.flv -af resample=22050:0:0 -sws 9 -vf scale=480:-3 -of lavf -ovc lavc -lavcopts vcodec=flv:vbitrate=400:trell:v4mv:mv0:mbd=2:cbp:aic:cmp=3:subcmp=3 -oac mp3lame -lameopts abr:br=48:mode=3

@dott
theres a reference to vp8 but it doesnt work

Thanks

rernst

23rd June 2010, 21:51

@rernst
can´t download the file

if possible can anyone help me "translate" the following but using vp8 as the encoder, this is what i used for FLV.

@dott
theres a reference to vp8 but it doesnt work

Thanks

Try again. This is the full build, official although I haven't changed the name.

littleD

24th June 2010, 13:45

IE9 Platform release 3 is out and what we've got

<video>
* MP4 H.264 playback support, using hardware or software decoding
* Support for WebM software is not included in this release

So, is webm including planned for next release?

wiak

24th June 2010, 15:31

IE9 Platform release 3 is out and what we've got

So, is webm including planned for next release?
they did say it, btw microsoft is horrible slow to release anything, so, and am sure the release 3 is kinda out of date allready

ricardo.santos

24th June 2010, 20:39

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

mencoder.exe 1234.mp4 -o out.mkv -af resample=22050:0:0 -sws 9 -vf scale=480:-3 -of lavf -ovc lavc -lavcopts vcodec=libvpx:0="threads=2" -nosound

hellfred

27th June 2010, 14:17

The VP8 decoder of the FFmpeg project recently got some important extensions:

1. Support for the bilinear filter feature missing up to now was added (http://git.ffmpeg.org/?p=ffmpeg;a=commit;h=340674b22b220e41923c51a2f1d1606d14ea2491). Now all test vectors decode without flwas.
2. The first set of SIMD optimizations for the x86 platform (http://git.ffmpeg.org/?p=ffmpeg;a=commit;h=d9295da5f58bec75e1231833224ca5b2222f69ed) wer committed.

Features known to be missing: Upscaling (http://git.ffmpeg.org/?p=ffmpeg;a=commitdiff;h=7ef9d23a121fc6fe343b76a08a15b47fa7ebfe05)
There is some WIP for Altivec SIMD optimizations (http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-June/091562.html).
The main author of the FFmpeg VP8 decoder has refined his statement about the speed of his decoder compared to the on in libvpx:
I meant 40-50% faster than libvpx without any SIMD; with SIMD it's ~2x faster than we are right now. (http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-June/091549.html) So the pure C decoder code is faster than the one in libvp8.