Log in

View Full Version : Google VP9 "Next Generation Open Video" information posted


Pages : 1 2 3 4 5 [6] 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

BadFrame
9th July 2013, 23:05
BadFrame
thx.
I am not familiar with reference HEVC encoder.
I want to try Strongene HEVC latest beta version (http://xhevc.com/en/downloads/downloadCenter.jsp).
Ok, I've only tried the fraunhofer reference encoder, that commercial encoder you linked looks interesting but I'm on Linux, perhaps it runs under wine though.

zerowalker
9th July 2013, 23:06
Yes indeed, at high bitrates, the only Real difference was that x264 wasnīt able to keep the image "accurate", it tried it best to keep the bits at the right places, but you can clearly see that it doesnīt do to well.
While VP9 have alot more balance, and is able to produce a much more detailed and accurate image.

Though, the difference isnīt Day and Night, but itīs still there.
And thinking that VP9 will be better and better makes this very interesting!

mindwin
9th July 2013, 23:10
BadFrame
but I'm on Linux, perhaps it runs under wine though.
I think it will not work, becouse it is a DirectShow filter.
I am using it with GraphStudioNext utility.

zerowalker
9th July 2013, 23:10
mindwin, will maybe try it later, currently VP9 is so slow, that it takes like 1-2 hours for 2-3 secs, which isnīt that fun;P

schweinsz
10th July 2013, 04:41
Is there any configuration to use the vp9 to get the max PSNR using the fixed QP coding? I want to do a comparison between the HEVC HM and the vp9 reference software.

guada2
10th July 2013, 13:59
Hello midwin,
The installation went well. But i have a small problem:
VFW_E_CANNOT_ CONNECT (0x80040217)


how can i do to solve it.

Thanks

zerowalker
11th July 2013, 08:32
Well letīs try to keep it towards VP9. Comparing VP9 with HEVC is a good thing though, they should be compared as they are combating about the "throne".

But i would like to know, why canīt i make a .webm file with VP9?

mkvtoolnix doesnīt allow this for some reason, i thought the VP9 in Webm was a standard for a while now, or has it been changing alot, making them wait?

Guest
11th July 2013, 13:02
OT posts have been removed. This thread is about VP9. Start a new thread for HEVC. Thank you.

mzso
11th July 2013, 13:55
Well letīs try to keep it towards VP9. Comparing VP9 with HEVC is a good thing though, they should be compared as they are combating about the "throne".

But i would like to know, why canīt i make a .webm file with VP9?

mkvtoolnix doesnīt allow this for some reason, i thought the VP9 in Webm was a standard for a while now, or has it been changing alot, making them wait?

I'm assuming it wasn't updated to do so with vp9.

Did vp9 made it into the main ffmpeg branch?

zerowalker
11th July 2013, 13:58
Probably, would like to see it though, but as there is no decoder to play the videos, it doesnīt really matter at this time.

From when i last checked, No.

ffmpeg seems to go after the git version 1.2.0 instead of Master for some reason.

Nintendo Maniac 64
12th July 2013, 02:42
Probably, would like to see it though, but as there is no decoder to play the videos, it doesnīt really matter at this time.

Chrome doesn't count? :P

zerowalker
12th July 2013, 09:26
Whatīs Chrome?

Just kidding, well sure it works, but i wouldnīt actually call it a player;P

benwaggoner
12th July 2013, 17:16
Is there any configuration to use the vp9 to get the max PSNR using the fixed QP coding? I want to do a comparison between the HEVC HM and the vp9 reference software.
I think an unconstrained VBR encode at the same bitrate as a HEVC encode would be a fine initial comparison. Unless you're trying to compare the relative strengths of the codecs without any rate control.

I seem to recall that VP9 defaults to tuning for PSNR.

Rumbah
13th July 2013, 00:57
First of all thanks for the compiling help, I just got vpxenc compiled with an up to date MSYS 64 and Yasm.
Unfortunately, PSNR is probably the worst available objective metric available. I'd like to see 3SSIM or MOVIE at least. I really don't understand why anyone focusing on a real-world codec would spend much time on PSNR.Are 3SSIM and MOVIE freely available anywhere for HD resolutions?I seem to recall that VP9 defaults to tuning for PSNR.Well, according to the vpxenc command line help you have --tune=psnr,ssim to choose from. If it defaults to any of this I do not know.

zerowalker
13th July 2013, 15:55
Okay need to ask these, how do you get 2 Passes to work?

If i set passes 2, it will just do the fast first pass.
How can i make it do the second pass?

Rumbah
13th July 2013, 16:15
You need --passes=2 --pass=1 for first pass and --passes=2 --pass=2 for second pass.

zerowalker
13th July 2013, 16:17
ah, that make sense, thanks.

Okay, well it doesnīt work for me.

ffmpeg -i "Z:\Dead Space 2\deadspace2.avs" -f yuv4mpegpipe -| vpxenc --best --cpu-used=0 --threads=0 --profile=0 --lag-in-frames=25 --min-q=0 --max-q=63 --end-usage=vbr --auto-alt-ref=1 --passes=2 --pass=1 --kf-

max-dist=9999 --kf-min-dist=0 --drop-frame=0 --static-thresh=0 --bias-pct=50 --minsection-pct=0 --maxsection-pct=2000 --arnr-maxframes=7 --arnr-strength=5 --arnr-type=3 --sharpness=0 --undershoot-pct=100 --

codec=vp9 --target-bitrate=1000 -o dead.webm -

ffmpeg -i "Z:\Dead Space 2\deadspace2.avs" -f yuv4mpegpipe -| vpxenc --best --cpu-used=0 --threads=0 --profile=0 --lag-in-frames=25 --min-q=0 --max-q=63 --end-usage=vbr --auto-alt-ref=1 --passes=2 --pass=2 --kf-

max-dist=9999 --kf-min-dist=0 --drop-frame=0 --static-thresh=0 --bias-pct=50 --minsection-pct=0 --maxsection-pct=2000 --arnr-maxframes=7 --arnr-strength=5 --arnr-type=3 --sharpness=0 --undershoot-pct=100 --

codec=vp9 --target-bitrate=1000 -o dead.webm -

easyfab
13th July 2013, 16:58
And with --fpf=name.ext -> first pass statistics file name ?

and pehraps also -w and -h for the resolution ?

Rumbah
13th July 2013, 16:58
I always used --fpf=filename
to give a filename for the first pass statistics file, i don't know if the encoder creates it automatically if you omit it (for both passes, the only difference is pass=1 and pass=2)

zerowalker
13th July 2013, 16:59
Just read about that command, and that solved it.
Or well, i also skipped the pipeline by just adding the yuv file in the same folder as i encode.

But got it working at last:)

Itīs still super slow though, would like them to do some optimization to speed it up a bit atleast XD

Rumbah
13th July 2013, 17:13
Well, if you look at the git it changes very fast. If you need a new version compile just say so ;)

zerowalker
13th July 2013, 17:20
Yeah, i am following it:)

And am encoding now, using the latest, and itīs still super slow XD

But, when you compile, do you get the an error in the "make" command?
I get it everytime, and i have to rename Libvpx_g.a to Libvpx.a (or well i have to copy it and have both those files). then rerun make to make it work.

Itīs just irritating:S

Rumbah
13th July 2013, 17:25
I use the patch form here:

http://forum.doom9.org/showpost.php?p=1633729&postcount=6

So after the ./configure I use the patch with
patch Makefile libvpx-makefile.diff
in the libvpx main directory. Then the following make works without a problem.

This is the script I use with libvpx-makefile.diff in the main libvpx directory:
cd libvpx
git pull
./configure
patch Makefile libvpx-makefile.diff
make

zerowalker
13th July 2013, 17:28
Ah, think i read about that before, didnīt know how to use it though.

Where can i put the script and use it?
I always write everything from scratch in Mingw?

Also, i use standard mingw, should i use mingw64 or something like that?

EDIT:

Got the script and patch to work, Thanks:)

Rumbah
13th July 2013, 17:43
well, I have used git clone http://git.chromium.org/webm/libvpx.git
in my home folder so it created the libvpx sub folder.

To get a new version of the source just switch in the libvpx main folder with cd libvpx and use git pull to get the latest version.

I copied the libvpx-makefile.diff in that main folder and patch it after the configure with patch Makefile libvpx-makefile.diff.

So just copy the libvpx-makefile.diff into the main libvpx folder.

Then you can create a text file example.sh and if you put it in the main libvpx folder just inset in the text file:
git pull
./configure
patch Makefile libvpx-makefile.diff
make

Or if you place it anywhere else just insert a "cd to libvpx folder" at the beginning.

zerowalker
13th July 2013, 17:45
Yeah got it to work, had a bit different folder setup, but it all went well.
Needed to experiment to get Patch working, but now all is well!

Thanks, saves time and frustration:)

zerowalker
13th July 2013, 18:30
Does the latest encoder work for you?
For me, it produces like 1 frame that looks good (the first frame, maybe some more), then itīs just artifacts and messed up:S

easyfab
13th July 2013, 20:11
Zerowalker, Rumbah,

Here an example of my little script if it can help you to build vp9 more easily .
In my example, first create a folder build in home and src in build, put libvpx-makefile.diff in the build folder and create a vp9.sh like this :

MY_BUILD=${HOME}/build
cd ${MY_BUILD}/src/
git clone http://git.chromium.org/webm/libvpx.git
cd ${MY_BUILD}/src/libvpx
git pull
patch -p1 < ../../libvpx-makefile.diff
./configure --disable-vp8
make clean && make -j4 && make install

zerowalker
13th July 2013, 20:12
what does the -j4 command do?

easyfab
13th July 2013, 20:15
It use multithread, a lot faster if you have a multi-core processor, I use -j4 but you can also use more like -j8 but it could be more unstable.

zerowalker
13th July 2013, 20:21
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
13th July 2013, 20:40
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
13th July 2013, 21:57
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
14th July 2013, 09:21
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
14th July 2013, 16:11
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
17th July 2013, 00:05
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
17th July 2013, 00:53
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
17th July 2013, 00:56
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
17th July 2013, 01:28
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
17th July 2013, 01:29
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
17th July 2013, 01:40
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
17th July 2013, 04:28
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
17th July 2013, 08:04
chrome 29 beta is out now btw, vp9 decoding is enabled by default.

iwod
17th July 2013, 13:08
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
17th July 2013, 13:23
http://www.sendspace.com/file/96oly0

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

Nintendo Maniac 64
17th July 2013, 23:22
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/internet/google_chrome_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
18th July 2013, 18:15
BTW, some news from Opus codec.
Opus 1.1 beta. A new WebM audio codec (Opus+VP9) (http://forum.doom9.org/showthread.php?t=168270)

foxyshadis
19th July 2013, 02:04
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
20th July 2013, 15:27
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
20th July 2013, 19:53
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! :D), that situation leaves a lot of room for commercial closed source h265 encoders.