Google VP9 "Next Generation Open Video" information posted

[Tommy Carrot]

Ah, i see, thanks. I know vp9 is mostly developed for youtube, it's not really intended for end-users, but i hope they'll improve the documentation a bit. It's kinda hard to find info about basic stuffs.

[Selur]

I know vp9 is mostly developed for youtube,...
didn't know that :), but yes their way to document&share stuff really is lacking

[Tommy Carrot]

I played around with the vp9 encoder a bit, and i've never thought i would say this, but i'm actually quite impressed with the quality of it. I've tried almost all available vpx codec since vp3, and they were always overhyped, but ultimately lackluster, so i thought this is the case with vp9 as well. In my opinion currently it beats x265 quality-wise in most cases, even though hevc should be a more advanced format with more powerful tools for compression.

[Selur]

Problem is, that it simply is too slow for normal usage. The single threading really is a pain.

[Tommy Carrot]

Yep, it's too slow, but at least it has the quality advantage we'd expect from a "next gen" codec (unlike x265), and it just got multi-threading support, and i'm sure the encoding speed will be improved a lot in the future.

[Selur]

.. and i'm sure the encoding speed will be improved a lot in the future.
it's slow since the beginning and even http://wiki.webmproject.org/vp9/known-issues (which hasn't been updated for ages notes "Expect slow performance.")
-> the hope that vp9 will be faster any time soon was abandoned by my 1+ year ago :/

[Tommy Carrot]

That's too bad. I'd like to have a more efficient codec than x264, but the only real contender, x265 just doesn't seem to go anywhere. They are trying to improve speed, but often with shortcuts at the cost of quality. In fact the coding efficiency seems to be getting worse and worse instead of improving, as the development progresses. What's the point of improving the encoding speed, if it's still many times slower than x264, while the quality is not really any better in most cases?

[mzso]

it's slow since the beginning and even http://wiki.webmproject.org/vp9/known-issues (which hasn't been updated for ages notes "Expect slow performance.")
-> the hope that vp9 will be faster any time soon was abandoned by my 1+ year ago :/

It's a funny thing to say right after multithreading was implemented...

[easyfab]

It's funny thing to say right after multithreading was implemented...

yes between 2x and 2.5 X for me.
But I hope it's only a first step in multithreading because i'm only at 30% of CPU usage .

[Selur]

It's a funny thing to say right after multithreading was implemented...
Hopefully only for a small fraction of the code,...

Using a fresh compiled vpxenc (64bit) with:
vp8 - WebM Project VP8 Encoder v1.3.0-5001-g547cb14
vp9 - WebM Project VP9 Encoder v1.3.0-5001-g547cb14

Settings I used:
1st pass:
ffmpeg -y -loglevel fatal -threads 8 -i "F:\TestClips&Co\test.avi" -map 0:0 -an -sn -vsync 0 -r 25000/1000 -pix_fmt yuv420p -f yuv4mpegpipe - | vpxenc --codec=vp9 --passes=2 --pass=1 --target-bitrate=1500 --end-usage=vbr --fpf="H:\Temp\test_09_50_38_5810_02.stats" --best --cpu-used=0 --min-q=0 --max-q=63 --bias-pct=70 --minsection-pct=15 --maxsection-pct=10000 --lag-in-frames=25 --drop-frame=0 --undershoot-pct=0 --buf-sz=6 --buf-initial-sz=4 --buf-optimal-sz=5 --drop-frame=0 --resize-allowed=0 --kf-min-dist=0 --kf-max-dist=250 --auto-alt-ref=0 --noise-sensitivity=0 --sharpness=0 --static-thresh=0 --tile-columns=2 --tile-rows=1 --threads=16 --width=640 --height=352 -o NUL -
2nd pass:
ffmpeg -y -loglevel fatal -threads 8 -i "F:\TestClips&Co\test.avi" -map 0:0 -an -sn -vsync 0 -r 25000/1000 -pix_fmt yuv420p -f yuv4mpegpipe - | vpxenc --codec=vp9 --passes=2 --pass=2 --target-bitrate=1500 --end-usage=vbr --fpf="H:\Temp\test_09_50_38_5810_02.stats" --best --cpu-used=0 --min-q=0 --max-q=63 --bias-pct=70 --minsection-pct=15 --maxsection-pct=10000 --lag-in-frames=25 --drop-frame=0 --undershoot-pct=0 --buf-sz=6 --buf-initial-sz=4 --buf-optimal-sz=5 --drop-frame=0 --resize-allowed=0 --kf-min-dist=0 --kf-max-dist=250 --auto-alt-ref=0 --noise-sensitivity=0 --sharpness=0 --static-thresh=0 --tile-columns=2 --tile-rows=1 --threads=16 --width=640 --height=352 -o "H:\Temp\test_09_50_38_5810_03.vp9" -
I get 25% cpu usage which is better than the previous 12%, but still if that's what the speed of VP9 will stay at for again a year or more it's not really worth my time.

I'm using VP9 since spring of 2013 and this is the first time the speed got better and it's nice to see that something is happening in the multi-threading department, but still not enough to make it usable and pardon me, that after a year of knowing that vp9 is really slow and comparing how other codecs evolve in 1+ year (without a 'small' company like Google behind it) I'm still disappointed.
When I then read that Google plans to throw out another codec every 2 years, I'm not really confidant that VP9 will be usable till VP10 get's released.

[dapperdan]

When I then read that Google plans to throw out another codec every 2 years, I'm not really confidant that VP9 will be usable till VP10 get's released.

A quote on their mailing list suggested that's not the actual plan and they'd been misquoted.

Apparently VP10 work has started and there's a couple of branches available that have various experiments in them, details here:

https://groups.google.com/a/webmproject.org/forum/?fromgroups#!topic/codec-devel/cp4E8q3TjEo

And in a reply later in that thread someone says:

"The 2015 timeline for VP10 was misquoted.
A more realistic timeline is ~3 years, but also subject to the technical uncertainty of being able to achieve a substantial compression gain over VP9 at reasonable complexity."

[BadFrame]

I would suggest not using --best and --cpu-used=0 for anything other than to do an extreme test to see the absolute maximum the codec can produce (like more extreme than placebo on x264/x265), for something practical in terms of speed, use --good and --cpu-used=1, and I must say they do very well against --preset=slower on x264/x265 quality-wise in my tests.

I don't know if it is because I use --good and --cpu-used=1, but I get between 75-90% cpu utilization on my 2.67ghz core i5 using the following:

vpxenc --good --cpu-used=1 --codec=vp9 --end-usage=q --cq-level=15 --lag-in-frames=25 -o clip.webm clip.y4m --tile-columns=2 --threads=4

other things to try out are the different aq-modes, --aq-mode=2 (complexity) seems to give me the best results in terms of size/quality, also setting --arnr-maxframes=15 --arnr-strength=6 helps with better compression ration with no visible loss of quality as far as I can tell.

looking at the commandline you posted, you are manually setting a lot of parameters, like tile rows etc, why not cut down on parameters to make sure that they are not interfering with the possibility to do multithreading encoding ? try the settings I posted, (two pass is default so I don't set that), and also if you don't get good results through ffmpeg, try using vpxenc directly ?

[dapperdan]

Also, am I missing something, or would you expect tile-based multithreading with two tiles to only double CPU usage? Several people seem to report that result as if they expected something different to happen?

About a year ago Youtube suggested they were using 4 tiles for 1080p, though I think it was multithreaded decode they were talking about at that time.

[Selur]

@dapperdan:
Also, am I missing something, or would you expect tile-based multithreading with two tiles to only double CPU usage? Several people seem to report that result as if they expected something different to happen?
Using a higher tile count doesn't change the cpu usage.
About a year ago Youtube suggested they were using 4 tiles for 1080p, though I think it was multithreaded decode they were talking about at that time.
at least I used SD content (--width=640 --height=352)

looking at the commandline you posted, you are manually setting a lot of parameters, like tile rows etc, why not cut down on parameters to make sure that they are not interfering with the possibility to do multithreading encoding ?
I'm not manually setting the parameters and most of them should be at their default values. :)

I don't know if it is because I use --good and --cpu-used=1, but I get between 75-90% cpu utilization on my 2.67ghz core i5 using the following
I'm using a i7 quad core, so my 25% might be similar to you 75%, but still if far away from using the available cpu power. ;)

Using:
ffmpeg -y -loglevel fatal -threads 8 -i "F:\TestClips&Co\test.avi" -map 0:0 -an -sn -vsync 0 -r 25000/1000 -pix_fmt yuv420p -f yuv4mpegpipe - | vpxenc --codec=vp9 --passes=2 --pass=1 --target-bitrate=1500 --end-usage=vbr --fpf="H:\Temp\test_11_15_49_0510_02.stats" --good --cpu-used=1 --min-q=0 --max-q=63 --bias-pct=70 --minsection-pct=15 --maxsection-pct=10000 --lag-in-frames=25 --drop-frame=0 --undershoot-pct=0 --buf-sz=6 --buf-initial-sz=4 --buf-optimal-sz=5 --drop-frame=0 --resize-allowed=0 --kf-min-dist=0 --kf-max-dist=250 --auto-alt-ref=0 --noise-sensitivity=0 --sharpness=0 --static-thresh=0 --tile-columns=4 --tile-rows=1 --threads=16 --width=640 --height=352 -o NUL -
and
ffmpeg -y -loglevel fatal -threads 8 -i "F:\TestClips&Co\test.avi" -map 0:0 -an -sn -vsync 0 -r 25000/1000 -pix_fmt yuv420p -f yuv4mpegpipe - | vpxenc --codec=vp9 --passes=2 --pass=1 --target-bitrate=1500 --end-usage=vbr --fpf="H:\Temp\test_11_15_49_0510_02.stats" --good --cpu-used=1 --min-q=0 --max-q=63 --bias-pct=70 --minsection-pct=15 --maxsection-pct=10000 --lag-in-frames=25 --drop-frame=0 --undershoot-pct=0 --buf-sz=6 --buf-initial-sz=4 --buf-optimal-sz=5 --drop-frame=0 --resize-allowed=0 --kf-min-dist=0 --kf-max-dist=250 --auto-alt-ref=0 --noise-sensitivity=0 --sharpness=0 --static-thresh=0 --tile-columns=4 --tile-rows=1 --threads=16 --width=640 --height=352 -o NUL -
encoding is slower, but the cpu usage is lower (< 23%).

.. try using vpxenc directly ?
Since I always decode through ffmpeg or mencoder and then pipe the output of those to the encoder of my choosing. Creating humongous intermediate files isn't really an option for me.

--arnr-maxframes=15 --arnr-strength=6 helps with better compression ration with no visible loss of quality as far as I can tell.
I normally prefer to do the noise reduction before the encoding. :)

Cu Selur

[BadFrame]

I'm using a i7 quad core, so my 25% might be similar to you 75%, but still if far away from using the available cpu power. ;)

Using:
...
encoding is slower, but the cpu usage is lower (< 23%).

Are you saying you get slower encoding with --good and --cpu-used=1 than --best and --cpu-used=0 ???? That makes no sense at all.


Since I always decode through ffmpeg or mencoder and then pipe the output of those to the encoder of my choosing. Creating humongous intermediate files isn't really an option for me.

But in order to easily see if there is something in using ffmpeg to encode which gives you such poor results, how about just testing with a 'humongous intermediate file' just this once ? You realise you don't have to encode an entire movie, right ?


I normally prefer to do the noise reduction before the encoding. :)
Cu Selur

It's an alternate method of creating a reference frame, by temporally filtering a specific frame against a set of other frames, I don't see how it has anything to do with noise reduction ?


When --auto-alt-ref is enabled the default mode of operation is to either populate the buffer with a copy of the previous golden frame when this frame is updated, or with a copy of a frame derived from some point of time in the future (the choice is made automatically by the encoder). The --lag-in-frames parameter defines an upper limit on the number of frames into the future that the encoder can look.

However, many other options are possible and one alternative that has been implemented uses a temporally filtered image derived from a group of future frames. The extra control parameters for this are:

--arnr-maxframes=<arg> (number of frames to filter over 0-25)
--arnr-strength=<arg> (strength of the temporal filter 0-6)
--arnr-type=<arg> (not currently supported)

[Kurtnoise]

There is a fork on github using openCL (https://github.com/ittiamvpx/libvpx)...That should be faster.

[Selur]

Are you saying you get slower encoding with --good and --cpu-used=1 than --best and --cpu-used=0 ???? That makes no sense at all.
No I'm saying I get lower cpu usage. (speed is, as expected, faster)

[qutoe] I don't see how it has anything to do with noise reduction ?[/quote]
You are right haven't used vp9 for so long that I mixed up some stuff. :)

how about just testing with a 'humongous intermediate file' just this once ?
will to later, but I don't expect it to change anything (I'm using SD here so, decoder should be really fast and not really need much resources)

There is a fork on github using openCL...That should be faster.
didn't know that, will try it if someone can make a win 64bit build of it.

[dapperdan]

@dapperdan:

Using a higher tile count doesn't change the cpu usage.



I'm confused then. I assumed it was breaking the video up into independant tiles and using a thread to encode each one individually. So 2 tiles, 2 cpus used, 4 tiles 4 cpus used to their full extent.

Can someone explain what it's actually doing?

[Selur]

That is what I assumed too, but since the cpu usage didn't change that doesn't seem to be what the option (or the multithreading support) is doing

[mandarinka]

Yep, it's too slow, but at least it has the quality advantage we'd expect from a "next gen" codec (unlike x265), and it just got multi-threading support, and i'm sure the encoding speed will be improved a lot in the future.

If it is tile-based multithreding, then that is a fairly cheap-to-write but very bad-for-quality method. Basically it splits the frame into parts (vertical slices iirc) and encodes them separately. Really blows compared to WPP or frame-threads.

And are you sure VP9 is better than x265? AFAIK it was the other way around, and x265 keeps improving actually.

-------------------------------------
https://groups.google.com/a/webmproject.org/forum/?fromgroups#!topic/codec-devel/cp4E8q3TjEo

From the linked thread:
Currently for the playground branch, you can try configuring with any combination of these options in bold:
--enable-experimental --enable-supertx --enable-copy-coding --enable-ext-tx --enable-filterintra --enable-interintra --enable-masked_interintra --enable-masked_interinter
You will get about 4% gain over baseline VP9. There was an ICIP talk recently which talks briefly about these tools, which should be available online sometime.

Currently for the nextgen branch the available tools are:
--enable-experimental --enable-ext-tx --enable-tx64x64 --enable-filterintra --enable-txskip
where ext-tx is a better version of the tool in the playground branch, and txskip is only used in lossless mode. The stable tools from the playground branch are in the process of being promoted to nextgen currently.

Does anybody have a link/pointer to the mentioned ICIP talk information? It would be nice to get an idea of the experimental compression tools that they evaluate.

[Tommy Carrot]

And are you sure VP9 is better than x265? AFAIK it was the other way around, and x265 keeps improving actually.

Yep, x265 tends to blur out the fine details. Maybe some extreme psy-rd settings can negate that, but that causes other issues. Vp9 retains more detail without causing any really perceptible artifacts. X265 only has advantage at ridiculously low bitrates (above crf 40 or so).

And yes, in my opinion the older versions produced better quality. The newer versions tend to produce less detailed, smoother output. Hell, an ancient 0.3 build, which i use as a comparison standard, often beats the latest build quality-wise without having any adaptive quantization, cutree and psy-rd (which should improve the perceptual quality quite a bit).

[mandarinka]

To me it seemed that VP9 blurs even more, while having no psy-rd at all, so you can't prevent that at all, unlike with x265.

[Kurtnoise]

x86 (http://www.mediafire.com/download/iqr945djdc5h7jl/vpx_x86_20141101.7z) & x64 (http://www.mediafire.com/download/3aieuvqlgkvgap9/vpx_x64_20141101.7z) binaries from today...
x86 (http://www.mediafire.com/download/fwdmfhna2ala97a/vpx_x86_20141214.7z) & x64 (http://www.mediafire.com/download/6lmjqi1dnk2uau9/vpx_x64_20141214.7z) binaries from today...

[benwaggoner]

x86 (http://www.mediafire.com/download/fwdmfhna2ala97a/vpx_x86_20141214.7z) & x64 (http://www.mediafire.com/download/6lmjqi1dnk2uau9/vpx_x64_20141214.7z) binaries from today...


Any notable new features or changes?

I keep hoping VP9 will get something to start closing the gap with x265, which is improving quite rapidly in speed and quality, as are other HEVC encoders.

I don't think I've seen a compelling real-world example of VP9 beating x264 yet for a practical scenario. I believe the bitstream itself to be capable of better than H.264 quality, but encoder refinement is a HUGE factor.


-Ben Waggoner (via TapaTalk)

[mandarinka]

The ffvp9 encoder only has the full set of assembly optimised code in x86-64bit mode. The developers chose to not care about 32bit performance, so it won't ever perform very well on non-64bit OSes/playback environments.

(see here (http://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastest-vp9-decoder-ffvp9/))

Just a quick note since this was discussed earlier.
Seems that the things are changing, VP9 is getting some SSE2 level assembly also for 32bit mode.
https://github.com/rbultje/ffmpeg/commits/vp9-32bit
I think that some parts at least already hit the official tree of FFmpeg.

[Kurtnoise]

Any notable new features or changes?

Mainly bugfixes but devs are also starting multithreading support for the vp9 encoder...

[easyfab]

I see a Multiframe Quality Enhancement (MFQE) commit but I don't know what it is ? for encoding or decoding ?

[Kurtnoise]

It's for decoding...

The aim for MFQE is to replace pixel blocks in the current frame with the correlated pixel blocks (with higher quality) in the last frame. The replacement can only be taken in stationary blocks by checking the motion of the blocks and other conditions such as the SAD of the current block and correlated block, the variance of the block difference, etc.

From the commit message :
* Multiframe Quality Enhancement(MFQE) in VP9.

It is the first version of MFQE in VP9. There are a few TODOs included
in this version.
Usage: Add flag --enable-vp9-postproc to config the project.
In decoder, use flag --mfqe in the command line to enable
MFQE in postproc.
Note: Need to have key frame with low quality to see the effect of this
new patch. In my experiment, I fixed the qindex to 200 in key frame.

I'm rebuilding binaries w/ the post-proc flag...

x86 (http://www.mediafire.com/download/qn0nb19bwb2rpuv/vpx_x86_20141215.7z) & x64 (http://www.mediafire.com/download/lqrns8hbtgq0agt/vpx_x64_20141215.7z) binaries from today...

[Nintendo Maniac 64]

I wonder if the last several performance improvements are related to why there haven't been any VP9/WebM encodes on YouTube for a week now...? Like, maybe they're tweaking their encoding setup or something.

Just a quick note since this was discussed earlier.
Seems that the things are changing, VP9 is getting some SSE2 level assembly also for 32bit mode.
https://github.com/rbultje/ffmpeg/commits/vp9-32bit
I think that some parts at least already hit the official tree of FFmpeg.

Now the real question is, when will this hit LAV and when will it hit MPC-HC?

[easyfab]

Now the real question is, when will this hit LAV and when will it hit MPC-HC?

The best chance is when nevcairiel make an update of his ffmpeg tree for LAV filters.
Peharps a little faster if you ask him nicely in the LAV filters thread :p

[nevcairiel]

Building those new optimizations on Windows is currently broken in some configurations, certainly not before that is fixed.

[Selur]

Probably fixed now, at least the problem I had (and reported the last days) was fixed yesterday. :)

[Nintendo Maniac 64]

Seems that the things are changing, VP9 is getting some SSE2 level assembly also for 32bit mode.

It just hit me - that's SSE2. AFAIK, all optiimizations for SSE2 and below are coded for both 32bit and 64bit; it's only optimizations using SSSE3 and above that are 64bit only.

[nevcairiel]

It just hit me - that's SSE2. AFAIK, all optiimizations for SSE2 and below are coded for both 32bit and 64bit; it's only optimizations using SSSE3 and above that are 64bit only.

There is not really any relation between which SSE version is used and 32-bit or 64-bit.

Truth is that many newer optimizations are written to take advantage of the newer instructions for even more speed, and at the same time are written for 64-bit only because thats much easier to deal with, which may give someone this impression.
However, there is no rule that says I couldn't write 64-bit only SSE2 code, or SSSE3 32-bit code (or AVX2 32-bit code for that matter).

[Nintendo Maniac 64]

I didn't mean for code in general, I meant specifically for what is being developed for ffvp9:

http://lists.ffmpeg.org/pipermail/ffmpeg-devel-irc/2014-July/002201.html[/url]"]<nevcairiel> both ssse3 and avx optimizations, and most of those are only available on 64-bit on top, so if you run on 32-bit or on a CPU without ssse3, it'll be quite a bit slower

<jamrial> the optimizations up to sse2 are all for both x86 and x64. it's only ssse3 and above that (most) require x64

The point was that, because the new optimization being implemented for 32bit was SSE2, their policy of focusing on 64bit has not changed since SSE2 optimizations were already stated to be implemented for both 32bit and 64bit.

[benwaggoner]

It's for decoding...

I'm rebuilding binaries w/ the post-proc flag...
Wow. The "standardized but optional post-processing filter" was NOT the feature from VC-1 I expected to see in modern codecs.

Unless it's really fast, software decoders tend to leave out the optional post-processing in my experience. Even HW as well. That certainly happened in lots of VC-1 ports. Even Silverlight, although that was more a case of lameness than thoughtful design.

The way they should work is to turn off with the codec is under decoder performance stress, but that can be surprisingly hard to measure and tune in real-time.

[mandarinka]

[03:16] <BBB> https://raw.githubusercontent.com/rbultje/public/master/vp9-32bit.png

It seems I'll have to find a different thing to bash VP9 about ;) , 32bit and/or SSE2 decoding performance in FFVP9 seems to have closed the gap with 64bit / SSSE3+. Solidly trounces libvpx, too (lol @ libpx essentially being single-threaded...).

Edit: Thanks to the devs (mainly Ronald S. Bultje, I think)! This will come handy on those 32bit Wintel tablets or on Athlon/Phenom machines. Also when one is forced to 32bit playback components by MadVR.

[Nintendo Maniac 64]

Also when one is forced to 32bit playback components by MadVR.

And SVP which also requires 32bit - the extra performance will really come in handy considering that SVP can pretty much take advantage of as much CPU performance as you can throw at it.

[Kurtnoise]

Spartan Project supports WebM (http://www.anandtech.com/show/8932/internet-explorer-project-spartan-shows-large-performance-gains)...awesome !!!

[Nintendo Maniac 64]

Spartan Project supports WebM (http://www.anandtech.com/show/8932/internet-explorer-project-spartan-shows-large-performance-gains)...awesome !!!

Needs more info whether this means VP8 or VP9, because for all we know this could just be an integration of the previously-existing VP8/WebM IE plugin... it also needs more info whether this includes actual vorbis support or if they're kind of cheating and only supporting Opus for audio (I mean, it is partially built off Skype's SILK codec)

However, if it does mean actual VP9 support along with actual vorbis audio, then that would definitely pretty big news and may very well mean that VP9 will beat HEVC to the punch for browser-based streaming purposes.


(though Opus is better than vorbis anyway, which begs the question, "Why is YouTube still using vorbis audio for its VP9 WebM encodes?")

[dapperdan]

I thought I'd seen Opus on Youtube? There's some discussion here: http://www.hydrogenaud.io/forums/index.php?showtopic=107481

Also, is this actually confirmed? When I read it on Anandtech earlier and googled for more info, the only thing that came back was Anandtech, and a whole bunch of scummy sites that republish Anandech's articles in full without their permission.

Assuming it is actually true, confirmation of whether this is just for WebRTC or not would be good, as well as the points made above about VP8 and/or VP9 and what audio codecs supported alongside which video codecs etc.

[Nintendo Maniac 64]

I thought I'd seen Opus on Youtube? There's some discussion here: http://www.hydrogenaud.io/forums/index.php?showtopic=107481

Oh, that's a new development! That's great to see since it means YouTube also now officially support 48KHz audio. I'll have to contact the developer of CompleteYoutubeSaver so he can add them in...

[zerowalker]

Well this is indeed nice.
Always hated that Youtube uses 44.1khz for everything as my favorite is 48khz (it looks nicer, but primarily it's what pretty much every standard use except CD).
And Opus instead of super fast AAC encoding is most certainly going to be a quality gain:)

Weird how old that Topic is though, thought i would notice if Opus and 48khz was added:S

[NikosD]

Spartan Project supports WebM (http://www.anandtech.com/show/8932/internet-explorer-project-spartan-shows-large-performance-gains)...awesome !!!

Needs more info whether this means VP8 or VP9, because for all we know this could just be an integration of the previously-existing VP8/WebM IE plugin...


I tried latest Windows 10 Preview Build 9926 and IE11 with Spartan project enabled, already supports VP8 but not VP9 yet.

I think Microsoft's browser (IE12 ?) is going to support VP9 within the final Windows 10 product.

[xooyoozoo]

I tried latest Windows 10 Preview Build 9926 and IE11 with Spartan project enabled, already supports VP8 but not VP9 yet.

Does this also apply to Opus?

Was this through drag-n-drop into a window? If so, can you check whether FLAC, HEVC, and/or MKVs can play?


I think Microsoft's browser (IE12 ?) is going to support VP9 within the final Windows 10 product.

Whatever's stopping Spartan from including VP9, it's probably a holdup at the decision level rather than the implementation level. VP9 is activated by default in libvpx (I doubt they handrolled their own decoder or used LGPL libav), so they must have manually disabled library support for it.

Microsoft has already committed to incorporating a future version of WebRTC (ORTC/WebRTC 1.1), where both VP8 and Opus are mandatary codecs for full support. In that sense, including VP8 isn't entirely unexpected, but I assumed Microsoft would just ignore the VP8 requirement and glibly go for "webrtc-compatible", so this is a nice surprise.

[Nintendo Maniac 64]

Always hated that Youtube uses 44.1khz for everything as my favorite is 48khz (it looks nicer, but primarily it's what pretty much every standard use except CD)

48KHz is particularly nice for my uses since 99.99% of music and audio in games on Nintendo platforms are 32KHz.

(yes I know it's 32006Hz on the N64, but that can be losslessly slowed down to 32000Hz flat via Audacity)

[mandarinka]

Inb4 they still convert everything to 44.1khz, then Opus internally resamples it to 48khz when encoding and then during playback, the player resamples to 44.1khz again.

[NikosD]

Does this also apply to Opus?

Was this through drag-n-drop into a window? If so, can you check whether FLAC, HEVC, and/or MKVs can play?


IE doesn't look to work that way, with drag&drop.

Whenever I do that with any sample, a pop-up message asks me if I want to save it or open it and it opens that with the default program set by Windows default programs.

I tested IE11 (Spartan) by hitting this page:
https://www.youtube.com/html5

[xooyoozoo]

I tested IE11 (Spartan) by hitting this page:
https://www.youtube.com/html5

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).

[Nintendo Maniac 64]

Inb4 they still convert everything to 44.1khz, then Opus internally resamples it to 48khz when encoding and then during playback, the player resamples to 44.1khz again.

I had thought of that...but I didn't want to suggest it until I actually tested it myself.