Google VP9 "Next Generation Open Video" information posted

[zerowalker]

Same thought occurred to me, was hoping that wasn't true -_-.
Talk about a mess, you get better audio quality, but playback breaks it. Why do they want to force 44.1 on playback?
Is Hardware limited to playing that or what?
Cause all Hardware i know that has any access to Youtube should be able to play 48khz, as either it's a TV (DVD = 48khz) or it's a Phone/Media player thing which can often play up to 96khz.

[Nintendo Maniac 64]

Same thought occurred to me, was hoping that wasn't true -_-.
Talk about a mess, you get better audio quality, but playback breaks it. Why do they want to force 44.1 on playback?

You're jumping to conclusions, nobody actually said that they actually do that; we're just theorizing that it is technically possible.

BTW, turns out that YouTube livestreams are 48KHz AAC.

[zerowalker]

You're jumping to conclusions, nobody actually said that they actually do that; we're just theorizing that it is technically possible.

BTW, turns out that YouTube livestreams are 48KHz AAC.

Oh, nice. It's good to be wrong (hopefully) ;)

Ah, that's at least a bonus, Good Job Youtube!

[sneaker_ger]

At least Chromium should always use 48 kHz for Opus decoding, a patch was applied last year for that.

[NikosD]

Oh hmmmm.

That page assumes compatibility whenever a certain API call returns either 'probably' or 'maybe'. You can see how that's troublesome in a pre-beta browser (relevant (http://gph.is/Z5SBTA) ;)).

Edit: This page (http://www.quirksmode.org/html5/tests/video.html) has videos to explicitly determine support.

Edit 2: Microsoft will not include VP8/VP9 support in the foreseeable future (https://twitter.com/jacobrossi/status/560918042821918720).

The page you posted is similar to an older one I used to test which is from Microsoft and it's here:
http://ie.microsoft.com/testdrive/Graphics/VideoFormatSupport/Default.html

Well, using IE11 of Win 10, it couldn't play the WebM videos of both pages, so it's a bug of Win 10 reporting "probably" for VP8/VP9 support as you posted above.

Let's hope that Microsoft will at least support a DXVA device decoder for VP8/VP9, for HW decoding acceleration.

[xooyoozoo]

libvpx just added (http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=commit;h=9a1ce7be7d4a3056b9da1df64cb7d5115a513dd9) the foundation for a psyrd-like feature. So far it's only activated in very specific situations and seems conservatively tuned even when it's on.

[benwaggoner]

It's great to see some psychivisual optimizations coming. Hopefully this will migrate to VP9 proper with interframe support.

[soresu]

They also just prepped a release candidate for libvpx 1.4.0, "Indian Runner Duck" http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=commit;h=bb5a39c1a7ff4544c55a29c2ad34c5d391acb713

Seems to have multi threaded VP9 decode and encode, 10 and 12 bit support in VP9, aswell as enhanced ARMv8 support.
All round good update, if a bit late coming.

[Fantasy]

hello,
I try to build vpxenc.exe for windows 64 bit but it is too complicated for me.
Can some one build the latest version and then upload it pls?
Thank you!

[Kurtnoise]

http://www.mediafire.com/download/rs1j8hzhesouskl/vpx_x64_20150329.7z

I enabled high bitdepth in this build...

[Fantasy]

Thank you again, it works.
I try out 10 bit but no player can play it.

I have question about speed vs quality.

I read this: http://wiki.webmproject.org/ffmpeg/vp9-encoding-guide

but -speed 4 is not a command used in vpxenc.exe.
I think it is a combination of -deadline and -cpu-used.
-deadline: best, good and rl are easy to understand.
But I don't understand what -cpu-used values mean?

[vivan]

http://www.webmproject.org/docs/encoder-parameters/#2-encode-quality-vs-speed
Those are for VP8, but for VP9 it should be the same:
--best is like placebo (why does it even need a special option?)
--good --cpu-used 0 is like veryslow
...
--good --cpu-used 5 is like ultrafast

And https://www.ffmpeg.org/ffmpeg-codecs.html#Options-17
-speed sets VP8E_SET_CPUUSED

[Kurtnoise]

I try out 10 bit but no player can play it.
It depends on which players, which filters used, libraries used etc...and how the players and the filters/libraries have been compiled.


I have question about speed vs quality.

I read this: http://wiki.webmproject.org/ffmpeg/vp9-encoding-guide

but -speed 4 is not a command used in vpxenc.exe.
I think it is a combination of -deadline and -cpu-used.
-deadline: best, good and rl are easy to understand.
But I don't understand what -cpu-used values mean?
You have some explanations from here (http://www.webmproject.org/docs/encoder-parameters/)...it's for vp8 but it's the same idea.

[Fantasy]

wow I readed so much!
I have a question about -crf
"crf is the quality value (0-63 for VP9). To trigger this mode, you must use a combination of crf <q-value> and b:v 0. bv MUST be 0."

I find out about -crf: VPX_CQ, VP8E_SET_CQ_LEVEL

VPX_CQ can be used as: --end-usage=qc
VP8E_SET_CQ_LEVEL can be used as: --cq-level=<arg>

I think -crf 10 is similar to --cq-level=10

I find out about -b:v: -b:v can be used as --target-bitrate=<arg>
But what is "b:v 0", they said "bv MUST be 0", does it means --target-bitrate=0?
I think it is not bacause if i set I set:
--end-usage=qc --cq-level=10 --target-bitrate=0
quality is very bad.
What can i do to get -crf (is to achieve a constant (perceptual) quality level without regard to bitrate)?

[Fantasy]

hello, I try --end-usage=q but it doesn't work.
The ffmpeg-version I found in internet is compiled with libvpx-1.3.0, so the new features are not in and multi threads works not pefectly.
I hope they will release vpx-1.4.0 / libvpx-1.4.0 soon.

[Fantasy]

hello, I try --end-usage=q but it doesn't work.
The ffmpeg-version I found is compiled with libvpx-1.3.0, so the new features are not in and multi threads works not pefectly.
I hope they will release vpx-1.4.0 / libvpx-1.4.0 soon.

[dapperdan]

Latest version of libvpx, 1.4 "Indian Runner Duck" is out. Announcement email:

https://groups.google.com/a/webmproject.org/forum/#!topic/codec-devel/2zYWenmdUM8

[Motenai Yoda]

wow I readed so much!
I have a question about -crf
"crf is the quality value (0-63 for VP9). To trigger this mode, you must use a combination of crf <q-value> and b:v 0. bv MUST be 0."

I find out about -crf: VPX_CQ, VP8E_SET_CQ_LEVEL

VPX_CQ can be used as: --end-usage=qc
VP8E_SET_CQ_LEVEL can be used as: --cq-level=<arg>

I think -crf 10 is similar to --cq-level=10

I find out about -b:v: -b:v can be used as --target-bitrate=<arg>
But what is "b:v 0", they said "bv MUST be 0", does it means --target-bitrate=0?
I think it is not bacause if i set I set:
--end-usage=qc --cq-level=10 --target-bitrate=0
quality is very bad.
What can i do to get -crf (is to achieve a constant (perceptual) quality level without regard to bitrate)?

I think u should use -b:v as max average bitrate

[Kurtnoise]

Latest version of libvpx, 1.4 "Indian Runner Duck" is out. Announcement email:

https://groups.google.com/a/webmproject.org/forum/#!topic/codec-devel/2zYWenmdUM8
x86 Windows build available here (http://www.mediafire.com/download/3sd9rr33x3e1hwu/vpx-1.4_x86_20150404.7z) and x64 available there (http://www.mediafire.com/download/wj9czojjc9jfmcb/vpx-1.4_x64_20150404.7z).

2015-04-03 v1.4.0 "Indian Runner Duck"
This release includes significant improvements to the VP9 codec.

- Upgrading:
This release is ABI incompatible with 1.3.0. It drops the compatibility
layer, requiring VPX_IMG_FMT_* instead of IMG_FMT_*, and adds several codec
controls for VP9.

- Enhancements:
Faster VP9 encoding and decoding
Multithreaded VP9 decoding (tile and frame-based)
Multithreaded VP9 encoding - on by default
YUV 4:2:2 and 4:4:4 support in VP9
10 and 12bit support in VP9
64bit ARM support by replacing ARM assembly with intrinsics

- Bug Fixes:
Fixes a VP9 bitstream issue in Profile 1. This only affected non-YUV 4:2:0
files.

- Known Issues:
Frame Parallel decoding fails for segmented and non-420 files.

[mzso]

x86 Windows build available here (http://www.mediafire.com/download/3sd9rr33x3e1hwu/vpx-1.4_x86_20150404.7z) and x64 available there (http://www.mediafire.com/download/wj9czojjc9jfmcb/vpx-1.4_x64_20150404.7z).

2015-04-03 v1.4.0 "Indian Runner Duck"
This release includes significant improvements to the VP9 codec.

- Upgrading:
This release is ABI incompatible with 1.3.0. It drops the compatibility
layer, requiring VPX_IMG_FMT_* instead of IMG_FMT_*, and adds several codec
controls for VP9.

- Enhancements:
Faster VP9 encoding and decoding
Multithreaded VP9 decoding (tile and frame-based)
Multithreaded VP9 encoding - on by default
YUV 4:2:2 and 4:4:4 support in VP9
10 and 12bit support in VP9
64bit ARM support by replacing ARM assembly with intrinsics

- Bug Fixes:
Fixes a VP9 bitstream issue in Profile 1. This only affected non-YUV 4:2:0
files.

- Known Issues:
Frame Parallel decoding fails for segmented and non-420 files.


Interesting. So now you can encode 444. Can it encode in full range too too?
How does it fare compared to x264 these days efficiency wise. Decoding was a fair bit slower when I last messed with it for similar quality, judging by youtube (I guess even worse at equal bitrates). Encoding was painfully slow.

[Motenai Yoda]

Interesting. So now you can encode 444. Can it encode in full range too too?
Seems no, there aren't any switch to set full or limited range.

[BadFrame]

But what is "b:v 0", they said "bv MUST be 0", does it means --target-bitrate=0?
I think it is not bacause if i set I set:
--end-usage=qc --cq-level=10 --target-bitrate=0
quality is very bad.
What can i do to get -crf (is to achieve a constant (perceptual) quality level without regard to bitrate)?

Hmm, what is --end-usage=qc ? And why are you setting --target-bitrate at all ? And to zero ?

If I want crf style encoding when testing vp9 I use the following:

'vpxenc --end-usage=q'

that is 'q', not 'qc' for 'end-usage', here's a full parameter example:

vpxenc --good --cpu-used=0 --codec=vp9 --end-usage=q --cq-level=10 --lag-in-frames=25 -o clip.webm clip.y4m

[vivan]

And why are you setting --target-bitrate at all ? And to zero ?
Because that's what official VP9 encoding guide told him to do. It even highlights it in all caps.

[Nintendo Maniac 64]

Decoding was a fair bit slower when I last messed with it for similar quality, judging by youtube

Be wary of using YouTube as a test since, by default, h.264 in the web browser will use your GPU's hardware accelerated decoder if it's available, which is present on pretty much any GPU made since 2009.

[mzso]

Be wary of using YouTube as a test since, by default, h.264 in the web browser will use your GPU's hardware accelerated decoder if it's available, which is present on pretty much any GPU made since 2009.

I'm comparing videos from youtube, not how it's played on youtube.
Actually the difference was quite little now when I tested it with latest mpc-hc. Though for some reason VP9 playback wasn't completely smooth. (Not because of cpu usage because it didn't get near max.)

[Selur]

Small question, does VP9 (or VP8) nowadays hit a specified average bitrate when using 2pass? (last time I did some testing it was still totally off target)

[Nintendo Maniac 64]

I'm comparing videos from youtube, not how it's played on youtube.
Actually the difference was quite little now when I tested it with latest mpc-hc.

Well the same issue still can apply - MPC-HC can take advantage of LAVfilter's DXVA decoding, so you'd want to make sure LAV's "Hadware decoder" is set to "None".

[BadFrame]

Because that's what official VP9 encoding guide told him to do. It even highlights it in all caps.

Could you point me to the official VP9 encoding guide ?

[vivan]

http://wiki.webmproject.org/ffmpeg/vp9-encoding-guide#TOC-Constant-Quality-Recommended-Settings

[dapperdan]

Actually the difference was quite little now when I tested it with latest mpc-hc.

The measurements done for the ffmpeg vp9 decoder seemed to suggest that vp9 and h264 were roughly tied when it came to decoder complexity (they gave a slight lead to vp9 if comparing at same-quality rather than same-bitrate).

https://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastest-vp9-decoder-ffvp9/

At that point the libvpx decoder was trailing both ffmpeg decoders by a fair margin, I believe they've been focussing on speed since then, though ffmpeg probably haven't been sitting still either (notably extending support for 32 bit processors).

Be interesting to see how things stand now.

[BadFrame]

http://wiki.webmproject.org/ffmpeg/vp9-encoding-guide#TOC-Constant-Quality-Recommended-Settings

What you point me to are ffmpeg mappings which in turn have pretty much nothing in common with parameters of the official encoder, which is vpxenc.

And since 'fantasy' used vpxenc specific parameters as '--cq-level', '--target-bitrate', '--end-usage', I can only assume he was using vpxenc.

Now when using constant quality (--end-usage=q) in vpxenc, --target-bitrate has no effect (unless you set it to zero which gave me a floating point exception.

And since there is no 'qc' option in vpxenc I can only assume that 'fantasy' meant 'cq' which stands for 'constrained quality' which is using --target-bitrate as an upper bound (which explains very poor quality when set to 0), but that is obviously the wrong option for him if he wants --crf style encoding with vpxenc, which again is '--end-usage=q', '--cq-level=X' .

[sneaker_ger]

If I do vpxenc.exe --end-usage=q --cq-level=X -o output.vp9 - (y4m input via pipe) it does not matter what I choose for X. It's always the same bitrate and same crappy quality.

[BadFrame]

If I do vpxenc.exe --end-usage=q --cq-level=X -o output.vp9 - (y4m input via pipe) it does not matter what I choose for X. It's always the same bitrate and same crappy quality.

That's weird, '--cq-level=X' gives me a corresponding quality (and of course file size) variation relating to 'X'.

vpxenc --good --cpu-used=0 --codec=vp9 --end-usage=q --cq-level=X --lag-in-frames=25 -o clip.webm clip.y4m

I build vpxenc from the development branch, perhaps you are using an old version ?

[sneaker_ger]

It seems it was encoding to vp8 because I missed the --codec parameter. But if I add it it tries to do 2pass encoding. Looks like it also needs --passes=1.

What a shame the documentation is as bad as the ffmpeg one.

[BadFrame]

It seems it was encoding to vp8 because I missed the --codec parameter. But if I add it it tries to do 2pass encoding. Looks like it also needs --passes=1.

What a shame the documentation is as bad as the ffmpeg one.

I agree it's poorly documented, I'm guessing this is because parameters are still very much in flux, basically I just look at the parameters vpxenc lists as any web documentation is likely very outdated.

[stax76]

Is anybody else using piping? No matter what I try, it's crashing at the last frame, my command line is:

ffmpeg.exe -i test.avs -f yuv4mpegpipe - | vpxenc.exe --codec=vp9 -w 1120 -h 688 --limit=300 --good --cpu-used=0 -o test_out.webm -

I also tried avs2yuv.

[sneaker_ger]

I think it's because it's trying automatic multi-pass encoding. It cannot rewind the pipe like it could re-read a file so it crashes after the first pass.

[stax76]

Problem solved, thanks!

[Nintendo Maniac 64]

Here's an intesting article that tested the quality and encoder performance testing between VP9 and HEVC:
http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/The-Great-UHD-Codec-Debate-Googles-VP9-Vs.-HEVC-H.265-103577.aspx

However, these tests were supposedly ran back in December.

They also did playback performance testing, but the choice of software wasn't the greatest (no MPC-HC?)...though admittedly the web browser is very likely to be the most common "player" for VP9 content. I tried to leave a comment mentioning the lack of a player like MPC-HC which can play both formats out-of-the-box, but it seems their commenting system's support for Microsoft accounts is broken, and I don't have an AOL of Facebook account (I have an old Yahoo account though, but I've no idea what it even is).

[dapperdan]

He uses the University of Moscow tool to measure objective quality, which reminds me that they're doing an HEVC evaluation this year and including VP9. Results are due in a month or so.

Tangentially related, I noticed libvpx pulled in code to output some other objective metric from daala, I think they only outputted PSNR before.

[leonccyiu]

Here's an intesting article that tested the quality and encoder performance testing between VP9 and HEVC:
http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/The-Great-UHD-Codec-Debate-Googles-VP9-Vs.-HEVC-H.265-103577.aspx

However, these tests were supposedly ran back in December.

They also did playback performance testing, but the choice of software wasn't the greatest (no MPC-HC?)...though admittedly the web browser is very likely to be the most common "player" for VP9 content. I tried to leave a comment mentioning the lack of a player like MPC-HC which can play both formats out-of-the-box, but it seems their commenting system's support for Microsoft accounts is broken, and I don't have an AOL of Facebook account (I have an old Yahoo account though, but I've no idea what it even is).

Thank you for the link, this is something I have been looking at. I would like to take screenshots at 1080p of encodes in 4k between h264 and vp9 on youtube, unfortunately this would be downscaled. I would like to do the comparison at 4k as for most 4k videos, the vp9 bit-rate is higher, some as high as 60 for time-lapses whereas the h264 versions are around 22. For older vp9 4k encoders (circa sep 2014) I have seen bit-rates as low as 8 which was lower than 16 for the same video.

By comparison to 1080p, I have only seen one video where the vp9 bitrate was higher. The bit-rates on many 1080p vp9 videos are only around 2.5mbps and imo should not qualify as 1080p, I have no qualms about streaming the 4k versions wherever available despite the wastefulness as the difference is night and day even on just a 1080p monitor

[Nintendo Maniac 64]

Thank you for the link, this is something I have been looking at. I would like to take screenshots at 1080p of encodes in 4k between h264 and vp9 on youtube, unfortunately this would be downscaled.

I'm not quite understanding what it is exactly you're trying to achieve, but never-the-less any YouTube-specific discussion relating to VP9 or the like would be better off discussed in the other VP9 thread that is located in this subforum:
http://forum.doom9.org/showthread.php?t=170682

[Kurtnoise]

VP10 code has been merged to the main branch (https://github.com/webmproject/libvpx/commits/master) few days ago...

Here are some fresh windows builds for testing : x86 (http://www.mediafire.com/download/7z88x93rtk4tkgg/vpx-1.4-1119_x86_20150815.7z)|x64 (http://www.mediafire.com/download/cdjkpvoaa7olxko/vpx-1.4-1119_x64_20150815.7z)

[SeeMoreDigital]

VP10 code has been merged to the main branch (https://github.com/webmproject/libvpx/commits/master) few days ago...

Here are some fresh windows builds for testing : x86 (http://www.mediafire.com/download/7z88x93rtk4tkgg/vpx-1.4-1119_x86_20150815.7z)|x64 (http://www.mediafire.com/download/cdjkpvoaa7olxko/vpx-1.4-1119_x64_20150815.7z)
How about creating a new topic for these VP10 builds ;)

[zerowalker]

I am confused, VP10 is merged into VP9 or what?

[Reel.Deel]

I am confused, VP10 is merged into VP9 or what?

libvpx now includes 3 encoders/decoders, before VP10 was merged it only included VP8 and VP9.

vpxenc.exe:
Included encoders:

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

Use --codec to switch to a non-default encoder.

[zerowalker]

oh, didn't know it was combined.

Well VP10 is very interesting.
How far has it comes, i am guessing it's like when x265 was released or something, as they just merged the code?

Anyone know what VP10 has in store though, what's the features etc?

[Jamaika]

It's nice that there is something new. I did a test and decided that it doesn't have to be now codec VP10.
Too much bitrate, change colorspace, worse quality of the X264, there are no decoder and adapt to anything. Screenshots watched in Honeyview 5.12.

Video
ffmpeg.exe -y -loglevel warning -i "orginal.MP4" -s 1920x1080 -r 25000/1000 -an -sn -f yuv4mpegpipe -strict -1 -pix_fmt yuv420p -color_primaries bt709 -color_trc bt709 -colorspace bt709 -color_range mpeg - |
x264.exe --demuxer y4m --input-depth 8 --input-csp i420 --input-res 1920x1080 --threads 4 --output-csp i420 --preset slower --fps 25000/1000 --bitrate 4500 --vbv-maxrate 10000 --vbv-bufsize 10000 --keyint 25 --min-keyint 1 --open-gop --ref 1 --bframes 0 --aq-mode 1 --tune stillimage --me dia --colorprim bt709 --transfer bt709 --colormatrix bt709 --range tv --output x264.h264 -
ffmpeg.exe -y -loglevel warning -i "orginal.MP4" -s 1920x1080 -r 25000/1000 -an -sn -f yuv4mpegpipe -strict -1 -pix_fmt yuv420p -color_primaries bt709 -color_trc bt709 -colorspace bt709 -color_range mpeg - |
x265.exe --y4m --input-depth 8 --input-csp i420 --input-res 1920x1080 --preset slower --output-depth 8 --fps 25000/1000 --bitrate 4500 --vbv-maxrate 10000 --vbv-bufsize 10000 --keyint 25 --min-keyint 1 --open-gop --ref 1 --bframes 0 --aq-mode 1 --me dia --colorprim bt709 --transfer bt709 --colormatrix bt709 --range limited --output x265.h265 -
ffmpeg.exe -y -loglevel warning -i "orginal.MP4" -s 1920x1080 -r 25000/1000 -an -sn -f yuv4mpegpipe -strict -1 -pix_fmt yuv420p -color_primaries bt709 -color_trc bt709 -colorspace bt709 -color_range mpeg - |
vpxenc.exe -v --i420 -w 1920 -h 1080 --threads=4 --passes=1 --pass=1 --profile=0 --cq-level=63 --good --codec=vp9 --fps=25000/1000 --cpu-used=3 --target-bitrate=4500 --color-space=bt709 --kf-min-dist=0 --kf-max-dist=25 --drop-frame=100 --aq-mode=1 - -o "vp90_420p08le.webm"
ffmpeg.exe -y -loglevel warning -i "orginal.MP4" -s 1920x1080 -r 25000/1000 -an -sn -f yuv4mpegpipe -strict -1 -pix_fmt yuv420p -color_primaries bt709 -color_trc bt709 -colorspace bt709 -color_range mpeg - |
vpxenc.exe -v --i420 -w 1920 -h 1080 --threads=4 --passes=1 --pass=1 --profile=0 --cq-level=63 --good --codec=vp10 --fps=25000/1000 --cpu-used=3 --target-bitrate=4500 --color-space=bt709 --kf-min-dist=0 --kf-max-dist=25 --drop-frame=100 --aq-mode=1 - -o "vp100_420p08le.webm"
vpxdec.exe --codec=vp10 --i420 --progress --rawvideo vp100_420p08le.webm -o 111.yuv
Screenshot
ffmpeg.exe -i "orginal.mp4" -q:v 1 -vframes 1 -f image2 -ss 00:00:00.155 -pix_fmt rgb24 -s 1920x1080 screenshot_original.bmp
ffmpeg.exe -i "x264.h264" -q:v 1 -vframes 1 -f image2 -ss 00:00:00.155 -pix_fmt rgb24 -s 1920x1080 screenshot1.bmp
ffmpeg.exe -i "x265.h265" -q:v 1 -vframes 1 -f image2 -ss 00:00:00.155 -pix_fmt rgb24 -s 1920x1080 screenshot2.bmp
ffmpeg.exe -i "vp90_420p08le.webm" -q:v 1 -vframes 1 -f image2 -ss 00:00:00.155 -pix_fmt rgb24 -s 1920x1080 screenshot3.bmp
ffmpeg.exe -s 1920x1080 -pix_fmt yuv420p -i "111.yuv" -q:v 1 -vframes 1 -f image2 -ss 00:00:00.155 -pix_fmt rgb24 -s 1920x1080 screenshot4.bmp
Examples of how someone is interested to "pass=1":
https://www.sendspace.com/file/d33dri

PS. Are there too codecs VP9/VP10 for WebP?

[easyfab]

I have the same pnsr for vp9 and vp10.
It's more like a copy-paste vp9->vp10 preparation for the moment.

To see what vp10 should be the nextgen branch is more appropiate IMO : https://github.com/webmproject/libvpx/commits/nextgen

configure with --enable-experimental --enable-supertx --enable-ext-tx ... and all the experiments you will try

the complete list : https://github.com/webmproject/libvpx/blob/nextgen/configure#L280

[Kurtnoise]

How about creating a new topic for these VP10 builds ;)
Im lazy to do that...if a moderator may split the discussion, that would be great, indeed.

It's nice that there is something new. I did a test and decided that it doesn't have to be now codec VP10.
Too much bitrate, change colorspace, worse quality of the X264, there are no decoder and adapt to anything. Screenshots watched in Honeyview 5.12.

Video
[I]ffmpeg.exe -y -loglevel warning -i "orginal.MP4" -s 1920x1080 -r 25000/1000 -an -sn -f yuv4mpegpipe -strict -1 -pix_fmt yuv420p -color_primaries bt709 -color_trc bt709 -colorspace bt709 -color_range mpeg - |
x264.exe --demuxer y4m --input-depth 8 --input-csp i420 --input-res 1920x1080 --threads 4 --output-csp i420 --preset slower --fps 25000/1000 --bitrate 4500 --vbv-maxrate 10000 --vbv-bufsize 10000 --keyint 25 --min-keyint 1 --open-gop --ref 1 --bframes 0 --aq-mode 1 --tune stillimage --me dia --colorprim bt709 --transfer bt709 --colormatrix bt709 --range tv --output x264.h264 -
ffmpeg.exe -y -loglevel warning -i "orginal.MP4" -s 1920x1080 -r 25000/1000 -an -sn -f yuv4mpegpipe -strict -1 -pix_fmt yuv420p -color_primaries bt709 -color_trc bt709 -colorspace bt709 -color_range mpeg - |
x265.exe --y4m --input-depth 8 --input-csp i420 --input-res 1920x1080 --preset slower --output-depth 8 --fps 25000/1000 --bitrate 4500 --vbv-maxrate 10000 --vbv-bufsize 10000 --keyint 25 --min-keyint 1 --open-gop --ref 1 --bframes 0 --aq-mode 1 --me dia --colorprim bt709 --transfer bt709 --colormatrix bt709 --range limited --output x265.h265 -
ffmpeg.exe -y -loglevel warning -i "orginal.MP4" -s 1920x1080 -r 25000/1000 -an -sn -f yuv4mpegpipe -strict -1 -pix_fmt yuv420p -color_primaries bt709 -color_trc bt709 -colorspace bt709 -color_range mpeg - |
vpxenc.exe -v --i420 -w 1920 -h 1080 --threads=4 --passes=1 --pass=1 --profile=0 --cq-level=63 --good --codec=vp9 --fps=25000/1000 --cpu-used=3 --target-bitrate=4500 --color-space=bt709 --kf-min-dist=0 --kf-max-dist=25 --drop-frame=100 --aq-mode=1 - -o "vp90_420p08le.webm"
ffmpeg.exe -y -loglevel warning -i "orginal.MP4" -s 1920x1080 -r 25000/1000 -an -sn -f yuv4mpegpipe -strict -1 -pix_fmt yuv420p -color_primaries bt709 -color_trc bt709 -colorspace bt709 -color_range mpeg - |
vpxenc.exe -v --i420 -w 1920 -h 1080 --threads=4 --passes=1 --pass=1 --profile=0 --cq-level=63 --good --codec=vp10 --fps=25000/1000 --cpu-used=3 --target-bitrate=4500 --color-space=bt709 --kf-min-dist=0 --kf-max-dist=25 --drop-frame=100 --aq-mode=1 - -o "vp100_420p08le.webm"


why such poor command lines ?


I have the same pnsr for vp9 and vp10.
It's more like a copy-paste vp9->vp10 preparation for the moment.

To see what vp10 should be the nextgen branch is more appropiate IMO : https://github.com/webmproject/libvpx/commits/nextgen

configure with --enable-experimental --enable-supertx --enable-ext-tx ... and all the experiments you will try

the complete list : https://github.com/webmproject/libvpx/blob/nextgen/configure#L280
yes, the merge is ongoing...it's not yet finished of course.