Google VP9 "Next Generation Open Video" information posted [Archive] - Page 15

dapperdan

26th September 2015, 20:50

http://x265.org/wp-content/uploads/2015/09/Figure-145-Ripping.png

Sneak peak of the MSU results, posted by x265 in another thread http://forum.doom9.org/showthread.php?t=168814&page=136

Makes me wonder how well an xvp9 encoder would do.

MoSal

26th September 2015, 21:31

Sneak peak of the MSU results, posted by x265 in another thread http://forum.doom9.org/showthread.php?t=168814&page=136

Are we going to pretend that those results are somehow relevant subjectively?

Makes me wonder how well an xvp9 encoder would do.

Why would this imaginary encoder be significantly better? libvpx is already tuned for SSIM.

Using different parameters in libvpx might give interesting results, if you are really keen on micro-tuning for SSIM.

This generation of codecs will probably be skipped by those of us who are looking for subjectively transparent results.

mandarinka

27th September 2015, 02:44

Does VP9 encoding in libvpx have any significant psyopts now? (x265 does though, so if anything, objective metrics should be helping VP9)

MoSal

27th September 2015, 09:49

Does VP9 encoding in libvpx have any significant psyopts now? (x265 does though, so if anything, objective metrics should be helping VP9)

IIUC, developers were asked to provide their tuning parameters for each metric. Those parameters were used as long as they didn't break speed constraints.

So, the claim that x265's results were crippled somehow by their psy opts is false, IMHO.

mandarinka

27th September 2015, 15:50

IIUC, developers were asked to provide their tuning parameters for each metric. Those parameters were used as long as they didn't break speed constraints.

So, the claim that x265's results were crippled somehow by their psy opts is false, IMHO.

But that is not what I meant. SSIM/PSNR is something like a base tuning of the codec that is easier to achieve quality in, because all your experimenting has easily evaluatable results. But the psyopts add quality on top of that, so when two codecs are tied on metrics but one has psy that can be enabled on top of that and the other has not, the first is going to be much better perceptually.

MoSal

27th September 2015, 19:17

But that is not what I meant. SSIM/PSNR is something like a base tuning of the codec that is easier to achieve quality in, because all your experimenting has easily evaluatable results. But the psyopts add quality on top of that, so when two codecs are tied on metrics but one has psy that can be enabled on top of that and the other has not, the first is going to be much better perceptually.

And we are back to square one!

The claim of added value implies the relevance of the common base. And metrics are irrelevant in the context of subjective quality.

Subjective quality should be judged visually. Preferably with double-blind tests if the lossy result is thought to be visually transparent. There is no need to promote other factors into relevance here.

dapperdan

28th September 2015, 20:32

Blog post that corresponds to the video talk posted a few days ago:

https://blogs.gnome.org/rbultje/2015/09/28/vp9-encodingdecoding-performance-vs-hevch-264/

CruNcher

29th September 2015, 10:31

Are we going to pretend that those results are somehow relevant subjectively?

Why would this imaginary encoder be significantly better? libvpx is already tuned for SSIM.

Using different parameters in libvpx might give interesting results, if you are really keen on micro-tuning for SSIM.

This generation of codecs will probably be skipped by those of us who are looking for subjectively transparent results.

I wouldn't say that even grain retention looks in some pretty decent for the bitrate in Motion :)

but to reach that you have to invest x orbitant of more speed/power currently, though some invested those already before in their preconstruction so now they have it more efficient in 1 step ;)

The more interesting question will be how efficient will be the upcoming Hardware Encoder/Decoder for each Codec compared to the CPU results, we are seeing now ;)

FPGA,DSP,HSA you name it ;)

Jamaika

1st October 2015, 09:29

I have a question. Where to download the plugin WebM VPX for quicktime?
https://github.com/webmproject/webmquicktime/commits/master

How to correctly perform the conversion yuv4mpegpipe on ffmpeg for depth 10bit? (http://forum.videohelp.com/threads/374452-The-problem-with-converting-ffmpeg)

iwod

2nd October 2015, 07:40

I haven''t been following the codec development, But in my (gosh) old days, VP8 were suppose to be slightly better then H.263 and VP9 would rival H.264, then VP10 or VPx they are working on to compete against H.265. VP8 wasn't good enough, and VP9 never matched x.264 despite all the marketing tell you otherwise.

Now i am seeing many proclaim VP9 is better then x.264 and is competing against H.265. What ever VP10 / x?
And has VP9 really gotten that much better? Most site still uses PNSR or SSIM which to me is like benchmarks number that you cant trust without context.

Any one has done any recent Picture quality testing? I did google search and nothing new came up.

Tommy Carrot

2nd October 2015, 14:13

LigH

2nd October 2015, 19:23

^ A similar opinion existed years ago between MPEG-2 and MPEG-4 Part 2 (ASP as e.g. DivX). Coincidence or logical? ... Well, x265 is not yet "final". Neither is VP10. Stay curious! :)

Nintendo Maniac 64

3rd October 2015, 03:37

Maybe iwod is confusing MPEG-4 Part 2 with h.263 due to the fact that the former used the latter as a basis? If you had a player that could only decode MPEG-4 Part 2, you would be able to play an h.263 video stream just fine, but a player that could only decode h.263 cannot decode MPEG-4 Part 2.

Anyway, it was my understanding that VP8 was more on level with VC-1 or h.264 baseline.

especially for game footages

For one thing, when VP9 doesn't have enough bitrate it becomes blurry while when AVC doesn't have enough bitrate it becomes blocky or pixelated, and for motion content the blurriness looks much more natural than the blockiness for obvious reasons.

One can kind of compare it between MP3 and Vorbis at low bitrates - MP3 will have distinctly digital-sounding artifacts while Vorbis just sounds muffled.

leonccyiu

4th October 2015, 06:45

Blog post that corresponds to the video talk posted a few days ago:

https://blogs.gnome.org/rbultje/2015/09/28/vp9-encodingdecoding-performance-vs-hevch-264/

Firstly, I can confirm on the latest windows insider build the internal video player plays back vp9, however judging from cpu usage, it's using the libvpx decoder. So is Microsoft Edge and Firefox.

This is highly frustrating as looking at Ronald's graph, it's clear to see ffvp9 is light years ahead of libvpx on fps, it makes an absolute huge difference. So many people are using older computers and while 1080p is easily decoded by my cpu, for others it can slow down their systems. 4k30 doesn't play back with libvpx, 1440p is stuttery on my pentium g3258 at 4.3ghz, but with ffvp9, 4k60 videos play back at around 35-60fps, a minor stutter here and there but such an amazing difference compared to the libvpx decoder. 4k30 plays back smoothly with the exception of scenes which reach 50mbps according to potplayer, these are more likely to be 4k videos shot on smartphones which have a very deep depth of field from their small sensors.

I reported the issue to google, but as expected got no reply. They really badly need to do something about their decoder if uptake of vp9 is to become more widespread.

NikosD

13th October 2015, 07:38

Latest Windows 10 Build 10565 has removed temporarily WebM and VP9 support .

WebM and VP9 have been temporarily removed from the flight builds.
We continue to develop a VP9 implementation that we intend to ship in Windows.
Expect VP9 to return soon in a future release.

NikosD

13th October 2015, 10:22

Meanwhile, Microsoft released 6 days ago the specifications for HW DXVA acceleration of VP8 and VP9 profile 0 (8bit , 4:2:0)

Details here:
http://www.microsoft.com/en-us/download/details.aspx?id=49188&WT.mc_id=rss_windows_allproducts

Nintendo Maniac 64

14th October 2015, 03:12

Compression.ru's 2015 video encoder test results were released:
http://compression.ru/video/codec_comparison/hevc_2015/

Included and most likely to be of interest are VP9, x265, and x264.

dapperdan

14th October 2015, 23:08

Is there not usually a download link for a free report too?

edit: the free version is there now

LigH

15th October 2015, 07:08

Has it not already been discussed here in the x265 thread? I remember that luminance only values were displayed with images. — There (http://forum.doom9.org/showthread.php?p=1740028#post1740028).

Nintendo Maniac 64

15th October 2015, 21:43

Has it not already been discussed here in the x265 thread? I remember that luminance only values were displayed with images. — There (http://forum.doom9.org/showthread.php?p=1740028#post1740028).

That was actually before the report was officially released; the x265 guys basically were given a sneek preview that they were allowed to share.

dapperdan

15th October 2015, 22:33

I've just read the free report, is there an explanation as to why VP9 only appeared in the "ripping" test, and not the others?

CruNcher

16th October 2015, 02:37

Pretty sad that Ateme is not contributing anymore their Titan Broadcast encoder seems pretty popular :D

foxyshadis

16th October 2015, 09:57

I've just read the free report, is there an explanation as to why VP9 only appeared in the "ripping" test, and not the others?

Because VP9 couldn't hit the 30+fps targets that the other profiles required, apparently. VP9 doesn't massively scale in an individual encode, it relies on massive scale of many encodes. Their statement: "It is definitely possible to incorporate more computing resources to significantly speedup the VP9 encoding process while achieving the same compression statistics. As an open source project, we certainly welcome contributions from the video coding community to make it happen."

Obviously, having 4-5 videos running at once on the 32-core test system probably would have been a better approximation of Youtube's workload, but that's not very applicable for many users.

dapperdan

16th October 2015, 22:05

I'm not sure 32-cores encoding a single video is particularly representative for many users either.

It would be nice to have some official confirmation on what exactly happened, e.g. did Google provide settings that just failed to hit the target they were set and so were disqualified, or did Google simply refuse to compete in that category because they thought the quality they would get would be embarrassing until they'd done more tuning for that use case, or ... ?

I can't quite figure out how they can have done so well in terms of speed/ssim for the ripping comparison if the number of cores was the fundamental issue.

Motenai Yoda

17th October 2015, 05:43

Because VP9 couldn't hit the 30+fps targets that the other profiles required, apparently.

But it does with high cpu-used or with deadline on realtime
It can be even faster than x265 on ultrafast

Jamaika

20th October 2015, 10:32

I wanted to ask is there any viewer to codec VP10?

LigH

20th October 2015, 10:37

There is not even a complete encoder yet, I believe; only source code adapted from VP9 and prepared to contain VP10 code later on, during its development and release... The last time I tried to build vpxenc, disabling the VP10 encoder was enforced by the configure scripts, one would have to manually patch configuration files in between configuring and making.

Jamaika

20th October 2015, 11:42

Some manufacturers add to their codec and I thought that here also find some primitive vpxview.exe.
I don't understand why the colormatrix vpxenc sRGB is equal to the BT709? At least in HEX it looks like that.
I don't understand why the vpxdec a record --rawvideo is equal to the --i420?
I understand that these features will only be created in future.

BadFrame

24th October 2015, 14:47

There is not even a complete encoder yet, I believe; only source code adapted from VP9 and prepared to contain VP10 code later on, during its development and release...

Actually development on VP10 is ongoing and the encoder is up and running, for example Ronald Bultje (of ffmpeg, x264 fame) is working for Google on it:

https://chromium.googlesource.com/webm/libvpx/+log/HEAD?5ce15400

Also it's in the main development branch now, but you still need to enable it with '--enable-vp10' when configuring.

LigH

24th October 2015, 14:57

If that's the case, then the media-autobuild_site team may try to insert a config patch when desired... I'll notify them.
__

Too late, vpxenc built with media-autobuild_site already contains VP10.

Included encoders:

vp10 - WebM Project VP10 Encoder v1.4.0-1579-gd162934
vp8 - WebM Project VP8 Encoder v1.4.0-1579-gd162934
vp9 - WebM Project VP9 Encoder v1.4.0-1579-gd162934 (default)

Motenai Yoda

28th October 2015, 20:56

If that's the case, then the media-autobuild_site team may try to insert a config patch when desired... I'll notify them.
http://forum.doom9.org/member.php?u=48461

LigH

28th October 2015, 21:16

Too late, vpxenc built with media-autobuild_site already contains VP10.

Everything is fine. :cool:

Jamaika

6th November 2015, 10:07

Where can I download a codec VPX v1.4.0-1579 or newer?

LigH

6th November 2015, 10:44

While I do so, you may as well use the media-autobuild_suite (https://github.com/jb-alvarado/media-autobuild_suite/) and configure it so that only VPX binaries will be built (to re-configure, delete or rename build\media-autobuild_suite.ini).
__

vpx v1.4.0-1652-gd7bbe1a (https://www.mediafire.com/download/677k1iqbaw360rc/vpx_v1.4.0-1652-gd7bbe1a.7z) (MSYS2 GCC 5.2.0, Win32+Win64)

Included encoders:

vp10 - WebM Project VP10 Encoder v1.4.0-1652-gd7bbe1a
vp8 - WebM Project VP8 Encoder v1.4.0-1652-gd7bbe1a
vp9 - WebM Project VP9 Encoder v1.4.0-1652-gd7bbe1a (default)

Jamaika

6th November 2015, 14:56

Thanks. Do somewhere is manual as it compile? I install media-autobuild_suite and don't know what to do next.

LigH

6th November 2015, 15:09

Run the batch file: media-autobuild_suite.bat; that should guide you through a first time setup (select which kind of environment to install and which tools to compile in which flavours), download and install an MSYS / MinGW environment with GCC, download sources, compile them, copy results to local32 or local64 subdirectories ... full automatic success, as long as there are no source code bugs.

mindwin

11th November 2015, 00:16

Javan Whistling Duck Release v1.5.0
https://groups.google.com/a/webmproject.org/forum/#!topic/codec-devel/0rjNpFerYs8

What's new?
- The above codec controls
- Substantially improved VP9 encoding speed and quality
- Improvements to VP9 decode speed including algorithmic changes to the multi threaded decoder.

What's not in this release?
- VP10. The vp10/ directory has been removed from the release branch. Please explore the master and nextgenv2 branches if you are interested in VP10 development.
- While many improvements have been made for vp9 realtime encoding there are many more ongoing and so we encourage people interesting in this use-case to submit changes to the master branch.

Jamaika

13th November 2015, 14:48

My thoughts on the codec VP9 1.5.0 included in ffmpeg.
http://ffmpeg.zeranoe.com/builds/win64/static/ffmpeg-20151111-git-edd0c1d-win64-static.7z
ffmpeg.exe -loglevel verbose -i "input.mts" -s 1920x1080 -r 50000/1000 -an -sn -f webm -c:v libvpx-vp9 -vb 4700k -cpu-used 1 -aq-mode 0 -threads 4 -deadline best -quality 100 -g 25 -pix_fmt yuv420p "output_vp90_v1.5.0.webm"
I don't like the codec description for function "verbose". It isn't known which performs converter ffmpeg.
[libvpx-vp9 @ 000000750a6900a0] v1.5.0
[libvpx-vp9 @ 000000750a6900a0] --target=x86_64-win64-gcc --prefix=/home/kyle/software/ffmpeg/pkgs/libvpx/libvpx-1.5.0-win64 --enable-runtime-cpu-detect
Output #0, webm, to 'output_vp90_v1.5.0.webm':
Metadata:
encoder : Lavf57.14.100
Stream #0:0: Video: vp9 (libvpx-vp9), 1 reference frame, yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=-1--1, 4700 kb/s, 50 fps, 1k tbn, 50 tbc
In the end can set the "-quality" using percentages:
Good = 75%
Best = 100%
The problem is that I don't see quality improvements. The converter acts as if nothing has changed.

markanini

14th November 2015, 01:18

Just a heads up for firefox users, you have to toggle enable for media.mediasource.webm.enabled in about:config to view youtube videos as VP9.

foxyshadis

14th November 2015, 02:41

My thoughts on the codec VP9 1.5.0 included in ffmpeg.

Are the speed improvements vs 1.4.0 true? Also, any improvements in rate control? I can't test right now.

Nintendo Maniac 64

14th November 2015, 05:45

Just a heads up for firefox users, you have to toggle enable for media.mediasource.webm.enabled in about:config to view youtube videos as VP9.

This is not new...also we have a dedicated thread regarding VP9 videos on YouTube.

Jamaika

14th November 2015, 07:56

In the end can set the "-quality" using percentages:
Good = 75%
Best = 100%
The problem is that I don't see quality improvements. The converter acts as if nothing has changed.
These functions aren't working. You should only use these with the specifications vpxenc.:!:
http://i64.tinypic.com/2mqmc81.jpg
-quality <int> E..V.... (from INT_MIN to INT_MAX) (default good)
best E..V....
good E..V....
realtime
I don't see changes in improving the speed for quality equal best. Computer practically stands.):

MoSal

14th November 2015, 11:52

I don't see changes in improving the speed for quality equal best. Computer practically stands.)

What were your expectations?

VPx developers explicitly recommend against using 'best'. All it does is slowing things down. And it's not even guaranteed to improve quality.

I can tell you with confidence that (almost) zero testing went into 'best' while developing VP9.

Increase '-speed' if you want faster encodes with less compression efficiency.

Jamaika

14th November 2015, 13:06

What were your expectations?
Hmm..., better sharpen the image, quick conversion and a lack the checkered in frames B.
http://i68.tinypic.com/2ypdlvt.jpg
Photo for the "good" and "cpu-used=1", fullhd, 4700kbps. Lack of intermediate option between "good" and "best".

MoSal

14th November 2015, 17:12

Hmm..., better sharpen the image, quick conversion and a lack the checkered in frames B.
...
Photo for the "good" and "cpu-used=1", fullhd, 4700kbps. Lack of intermediate option between "good" and "best".

For starters, why are you passing '-g 25'?
You know what that option means, right?

Jamaika

14th November 2015, 17:32

It's GOP (https://en.wikipedia.org/wiki/Group_of_pictures).
Why don't I use a long GOP?
I wanted to have a better opportunity to scroll 1 minute video in the player.
Intra frames, also known as "I" frames, are sometimes described as key frames because they are suitable for navigation points in the video. In order to skip forwards or backwards the user only has to decode the I frames. For inter coded frames, the user must find the most recent I frame, decode it, decode any other reference frames, then decode all the inter frames up to the desired frame. (http://www.tiliam.com/Blog/2015/07/06/effective-use-long-gop-video-codecs)

MoSal

14th November 2015, 18:22

LigH

15th November 2015, 18:28

Short GOPs will be useful for compatibility with consumer devices like Blu-ray players. But VPx has no consumer player target, and GOPs of 25 frames for 50 fps material will cause half-second GOPs, that's certainly not very efficient. The more I frames a video contains, the less bitrate can be spared by predictions (I frames need a magnitude more space than P or even B frames).

mzso

15th November 2015, 18:35

You realize that value is in frames, not seconds, right?

What makes you think he doesn't? Going above 30 starts to suck for seeking even for h264 here.
The typical big GOPs can be really annoying if you tend to seek a lot.

25 second would be just ridiculous and horrible. (With very little gain)