Google VP9 "Next Generation Open Video" information posted

[zerowalker]

Alright, well tried it, with some modifications, and well went pretty much the same as before.
Took along time to compile though.

And well, it became less in size, guess thanks to no vp8.

But damn, i still get the artifact problem.

4 frames work, then the rest is just blended colors in a mess:S

[easyfab]

Problably a latest commit broke something.

If you want to build an old version you can do a :
git checkout <HASH>
for <HASH> you need to know the commit hash look here http://git.chromium.org/gitweb/?p=webm/libvpx.git under commit (h=XXX)
or git checkout HEAD~<number>
for example HEAD~20 gives you an old version of 20 commits back

[BadFrame]

Originally Posted by Rumbah

You need --passes=2 --pass=1 for first pass and --passes=2 --pass=2 for second pass.

Hmm... all I do is set --passes=2 and the encoder does two passes automatically without me having to do anything (no --pass x needed), the first pass is fast and the second pass (where it does the actual encoding) is very slow.

You can see which pass it's on when it's encoding as it is displayed with the current frame:

Pass 1/2 frame x
...
Pass 2/2 frame x

[zerowalker]

Probably, if someone could test the latest commit, just encode like 10 frames, and watch it with chrome (you can watch while encoding, though it´s FPS isn´t correct so it plays to fast, but you see the artifacts anyway).

Hmm... all I do is set --passes=2 and the encoder does two passes automatically without me having to do anything (no --pass x needed), the first pass is fast and the second pass (where it does the actual encoding) is very slow.

I think i have seen that as well, not actually sure though. However i haven´t seen any "stats" file being created.

[BadFrame]

Originally Posted by zerowalker

I think i have seen that as well, not actually sure though. However i haven´t seen any "stats" file being created.

Well here is how I understand it, when you use '--passes 2' without specifying a '--pass X', there is no need for a 'statistics' file as the whole 2 pass encode is done in 'one go' (in other words, the encoder doesn't exit after a pass).

And in this 'mode' the statistics which would normally be stored in a file (-fpf=<file>) during the first pass is instead stored in allocated memory and from there used in the automatically started second pass.

If you specify a pass using '--pass N' however, it will exit after each pass and store the statistics in the file you specify using '--fpf=<file>', just the way it works in x264 for example.

I also verified this by encoding a clip using only '--passes=2' and then the same clip using '--pass=1' followed by '--pass=2' and the webm files created where bit identical (confirmed by md5sum).

So in other words, if you have no interest/use of the statistical data generated, you can supply only '--passes=2' (without --pass N) and it will automatically do the two passes after eachother with no manual intervention.

[zerowalker]

It seems like what you are saying is true.
Saves a line of code;P

But is anyone able to encode with vp9?
I still get the artifacts.

It seems weird that it still hasn´t been solved, i am starting to suspect something on my side.

[BadFrame]

Originally Posted by zerowalker

But is anyone able to encode with vp9?
I still get the artifacts.

It seems weird that it still hasn´t been solved, i am starting to suspect something on my side.

I did some tests just yesterday with no problems at all.

Given that I have no problems and I am using vpxdec to losslessly decode the vp9 video to watch it rather than use Chrome which you've stated you are using, I dare say that the problem lies with your version of Chrome not being compatible with the vp9 stream generated by the latest vpxenc builds and that this is what is causing problems for you during playback.

[zerowalker]

I see, probably true.
But i find it weird, doesn´t a bitstream freeze mean that decoders will be compatible forever with the codec?

[BadFrame]

Originally Posted by zerowalker

I see, probably true.
But i find it weird, doesn´t a bitstream freeze mean that decoders will be compatible forever with the codec?

Yes I suppose it should, however are you sure that the version of Chrome you have includes a version of vp9 that is after the bitstream freeze?

[zerowalker]

Pretty sure, it´s the latest Chrome Canary (Test build).

http://www.sendspace.com/file/96oly0

there is a file, see if you can play it

[BadFrame]

Originally Posted by zerowalker

Pretty sure, it´s the latest Chrome Canary (Test build).

Hmm... maybe they aren't that gung-ho about keeping the bitstream compability in the middle of development and will instead fix it in time for a final release?

I don't use Chrome so I don't have it installed and thus haven't tried it with VP9, but decoding the vp9 streams with vpxdec works perfectly fine for me.

edit: missed that you added a vp9 file, it decoded just fine and I then encoded it using x264 and it played fine aswell when I watched it.

steps I took if you are interested:

vpxdec --i420 -o i420.mkv dead.webm
x264 --crf 0 --input-res 1920x1080 i420.mkv -output h264.mkv

[zerowalker]

That worked great for me aswell.

Weird that they aren´t keeping the decoding of chrome the same, i was sure they had frozen the bitstream last month.

[hajj_3]

chrome 29 beta is out now btw, vp9 decoding is enabled by default.

[iwod]

Do VP9 Encoder or the spec adds some pre filter to video and default post filter when playback.

I seems to get a sense of Rmvb 'work in there.

[Monarc]

Originally Posted by zerowalker

http://www.sendspace.com/file/96oly0

Plays fine ... tested with self compiled mpv (linux)

[Nintendo Maniac 64]

Originally Posted by BadFrame

I don't use Chrome so I don't have it installed and thus haven't tried it with VP9

I don't have Chrome installed either but you can use this instead which doesn't require installation (the "installer" is just a fancy archive unpacker):
http://portableapps.com/apps/interne...hrome_portable

Scroll down for the beta versions.

The only thing missing is the auto-updater service, which depending on the person may actually be a good thing.

[IgorC]

BTW, some news from Opus codec.
Opus 1.1 beta. A new WebM audio codec (Opus+VP9)

[foxyshadis]

Originally Posted by iwod

Do VP9 Encoder or the spec adds some pre filter to video and default post filter when playback.

I seems to get a sense of Rmvb 'work in there.

RMVB, H.264, and VP6 to 9 all have inloop filtering. It's much better than pre or post filtering, but it becomes much more obvious the lower the bitrates go. RMVB and the VP family will more aggressively soften and smooth the video than H.264, but I see a great deal of promise in VP9 despite not having been a fan of previous generations (and the exaggerated claims that went with them).

If vendors don't move quickly on HEVC, VP9 may well steal their thunder for a few years.

[mandarinka]

I doubt that. It's Google who will be moving slowly (as with VP8), because they will probably again be the sole provider of VP9 encoders.

On the other hand, handful companies already announced or even offer H.265 encoders, and the competition is bound to push quality and speed of them up. Basically, it's open environment (somebody might find it paradoxical, but the MPEG stuff really is open in all ways but the royalty requirement).

[BadFrame]

Originally Posted by mandarinka

Basically, it's open environment (somebody might find it paradoxical, but the MPEG stuff really is open in all ways but the royalty requirement).

Not following the 'open environment' argument, there's a HEVC specification and to implement the specification and sell the implementation you need to pay royalites to cover the patent licencing, VP9 afaik is entirely royalty free and also licenced permissively so in terms of 'open environment' it wins hands down there.

I still think you are right as far as the actual result though, given that Google gives away a free fully open source codec which is the 'standard', I think there's very little commercial opportunity to compete.

Compare that to HEVC where it's unlikely to be any quality open source and free offering until the x264 devs get a mature h265 encoder out (go guys go! ), that situation leaves a lot of room for commercial closed source h265 encoders.