YouTube now adding VP9 option to popular videos

[NikosD]

Using latest Chrome v47.0.2526.27 beta-m (64-bit) and my Core i7-4790 on FTTC+VDSL2 50Mbps line, it is impossible to play in real-time Youtube 4K60fps VP9 clips.

I tried both Window and Full Screen mode and I had stuttering, crippled sound and dropped frames.
The same thing happened with 4K50fps clips, but 4K30fps and 1440p60 fps had <50% CPU utilization and played fine.

I thought that I have to blame the VP9 decoding engine of Chrome 64bit because I supposed the same 4K60fps clip from Youtube could easily be decoded by MPC-HC x64 v1.7.9 off-line.

Guess what...It can't.

Using latest nightly x64 v1.7.9.190 and EVR-CP renderer, I have almost the same CPU utilisation and dropped frames on a 4K60fps 18Mbps VP9 clip, with crippled sound and no realtime decoding capability (I get around ~50fps)

I managed to play that file in realtime with no dropped frames and normal sound only using EVR renderer.

It is possible that with a discrete GPU could play that file in EVR-CP, but I'm not sure if I don't try it.

My full specs:
Win 10 x64 - MPC-HC x64 v1.7.9.190 - Core i7 4790 - iGPU HD 4600

Clip:
3840 x 2160@60fps VP9 at 18Mbps

I think we need HW acceleration for those clips.

[nevcairiel]

If changing the video renderer allows them to play, it sounds like the processing/scaling of the video caused the problems, not the decoding alone, so having hardware acceleration wouldn't necessarily help. Default EVR uses the built-in Hardware Scaler in the GPU - EVR-CP cannot use that and uses Pixel Shaders instead, which may have overwhelmed the GPU.
What Chrome uses to process and scale the video I couldn't tell you.

Speaking of Hardware Acceleration - unfortunately Haswell systems won't get VP9 acceleration from the looks of it, only Broadwell and up.

[NikosD]

The behavior of the whole Intel based system changes, when you put a discrete card and performance rises significantly as tests show, mainly because of system memory been used by iGPU.

That kind of performance increase is separated from the discrete GPU performance alone, which is added to the equation.

The EVR - CP performance drops for all Intel iGPU I have tested so far (from Sandy to Haswell) and it's not so easily explained by GPU load of the pixel shaders.

Because GPU load is always very, very low on Haswell HD4600 even when scaling 4K to a small window.

Also 4K30 fps has no problem at all.

I haven't managed to explain it yet, so I take it as just a fact.

All I know is that it comes critical only for clips pushing the decoding performance to the edge.

Regarding HW acceleration, judging by similar cases for H.264 like 4K120fps, it might couldn't help.

Because for 4K@120fps H.264 I have exactly the same problem with EVR CP vs EVR like 4K60 fps VP9.

It seems that frame rate and not resolution causes issues with iGPU and EVR-CP with or without HW acceleration.

But H.264 4K60 fps is a piece of cake for Haswell.

Regarding HW acceleration of VP9 for Haswell, I have already told you that is not in Intel's intentions to do it - in hybrid mode of course.

Because I'm not sure if there is any chip of PC used GPUs, that has native HW VP9 support inside - not hybrid which is driver based.

I wrote about HW acceleration of VP9 in general, because I see that VP9's CPU decoders don't look optimised even for 64bit.

[MoSal]

Originally Posted by Nintendo Maniac 64

Anyway, something else I discovered - it seems YouTube's AAC encoder on that video is using a very recent version of ffmpeg (read: not even a month old).

Therefore, I believe it includes the considerable quality improvements that were mentioned during the VideoLAN Dev Days AAC presentation: https://www.youtube.com/watch?v=QiV60eGY11o

In particular, I find that the 192kbps AAC sounds noticably better than the Opus encode even though the source audio was even uploaded at 32KHz which would resample much more nicely into the 48KHz that Opus uses rather than the 44.1KHz used by AAC.

Oh boy.

1- YouTube never used lavc's still experimental AAC encoder.

2- Even with all the improvements. lavc's encoder is still not a very high-quality one.
Apple's encoder is considered the best. Fraunhofer's offerings (both open and closed source) are competitive. No other encoder comes close.

3- Opus has one (known) encoder*. And it's considered better than Apple's AAC encoder. Both are considered transparent for most people with the majority of samples at the bitrates > 128kbps. The quality of MP3s from the 90s is long gone!

4- If you use a blind testing tool. You would realize how powerful the placebo effect can be.

5- Resampling from 32KHz to either 48KHz or 44.1KHz should be transparent with any half-decent resampler.


* Note: libopus provides speed profiles (complexity from 0 to 10). 10 (high-complexity) is the default. It's fast. And I don't think anyone ever felt the need to lower that complexity.

[Nintendo Maniac 64]

Originally Posted by NikosD

Using latest nightly x64 v1.7.9.190 and EVR-CP renderer, I have almost the same CPU utilisation and dropped frames on a 4K60fps 18Mbps VP9 clip, with crippled sound and no realtime decoding capability (I get around ~50fps)

Enable "D3D Fullscreen" - that will give you the lowest CPU utilization possible and is light enough on the GPU that it is in fact the only way to get 1080p 60fps to run smoothly on nearly 10-year old Intel integrated GPUs (like the Intel 965GMA).

Also, you may want to check the Windows task manager and see if the VP9 decoder used by MPC-HC is not running at less than 50% CPU utilization, because if it is then it means the VP9 decoder simply isn't taking full advantage of your 4 CPU cores and that could explain the performance (in particular I get ~42fps with 3840x2160 60fps VP9 videos on "only" my dual core Pentium G3258 @ 4.6GHz with ~100% CPU utilization).


If you want, you could try to update the LAVfilters in MPC-HC 64bit to v0.66; first make sure MPC-HC is closed, navigate to your MPC-HC 64bit program folder, then go into the "LAVFilters64" folder and delete everything in it - don't close the folder window, you'll need it again. Now download the LAVFilters-0.66-x64.zip from the link below and extract all the files from the ZIP into the "LAVFilters64" folder that you left open - make sure you extract the files directly and not into a sub folder. That's it, no configuration or anything needed.

https://github.com/Nevcairiel/LAVFil...eases/tag/0.66

----------------------------------------------------------------

Originally Posted by MoSal

4- If you use a blind testing tool. You would realize how powerful the placebo effect can be.

I did do a blind test - it's definitely not placebo because until I turned my monitor back on, I thought the track that sounded higher quality even with lower volume was for sure going to be the Opus track, but when I turned my monitor back it was revealed that the track that I thought sounded better was actually the AAC track, not the Opus one.

For reference, my configuration is to use foobar2000 + ASIO (so no resampling on my Xonar DS), both tracks have replaygain metadata, playback order set to "Repeat (track)"; from there I put both audio tracks into a single playlist in foobar2000, start playing one of the audio tracks, turn off my monitor, then press the "Page Down" key (keyboard shortcut for "next track") a bajillion times until I've completely lost count of what track is playing at a given time and then I just press "Page Down" again to switch between tracks, once I've chosen which one sounds better I let it play and then turn the monitor back on and see which track is actually playing.


After that blind test I compared the AAC and Opus tracks to the original FLAC via Audacity by lining up the waveforms, doing an invert, and mixing the waveforms together, and the 192kbps AAC track was definitely more similar to the original FLAC than the Opus version was to the same FLAC; in other words, the AAC track when inverted and mixed with the FLAC gave a considerably quieter resulting waveform than when I mixed the inverted Opus track with the FLAC.

[wanezhiling]

Originally Posted by NikosD

Using latest nightly x64 v1.7.9.190 and EVR-CP renderer, I have almost the same CPU utilisation and dropped frames on a 4K60fps 18Mbps VP9 clip, with crippled sound and no realtime decoding capability (I get around ~50fps)

What's your memory? single or dual channel? That's maybe the point. On my laptop, the channel has an enormous impact on video playback...

example
single: 99% cpu load, 3840x2160_h264_8-bit_40m_30fps, sw decoding, evr-cp
dual: 15% cpu load, 3840x2160_h264_8-bit_40m_30fps, sw decoding, evr-cp

[NikosD]

Originally Posted by Nintendo Maniac 64

Enable "D3D Fullscreen" - that will give you the lowest CPU utilization possible and is light enough on the GPU that it is in fact the only way to get 1080p 60fps to run smoothly on nearly 10-year old Intel integrated GPUs (like the Intel 965GMA).

It does make a little difference, but still dropped frames and lower than 60fps.

Originally Posted by Nintendo Maniac 64

Also, you may want to check the Windows task manager and see if the VP9 decoder used by MPC-HC is not running at less than 50% CPU utilization, because if it is then it means the VP9 decoder simply isn't taking full advantage of your 4 CPU cores and that could explain the performance

I have a Windows gadget always open, monitoring CPU, GPU, HDD, SSD etc.
The CPU utilization is about 40% - 60% for all 8 threads.

Originally Posted by Nintendo Maniac 64

If you want, you could try to update the LAVfilters in MPC-HC 64bit to v0.66; first make sure MPC-HC is closed, navigate to your MPC-HC 64bit program folder, then go into the "LAVFilters64" folder and delete everything in it - don't close the folder window, you'll need it again. Now download the LAVFilters-0.66-x64.zip from the link below and extract all the files from the ZIP into the "LAVFilters64" folder that you left open - make sure you extract the files directly and not into a sub folder. That's it, no configuration or anything needed.

https://github.com/Nevcairiel/LAVFil...eases/tag/0.66

MPC-HC v64 1.7.9.190 has LAV filters 0.66 built-in.

Also, I always grab the latest official nightly build from here:
http://files.1f0.de/lavf/nightly/

Latest nightly is 0.66.31 right now.

Originally Posted by wanezhiling

What's your memory? single or dual channel? That's maybe the point. On my laptop, the channel has an enormous impact on video playback...

example
single: 99% cpu load, 3840x2160_h264_8-bit_40m_30fps, sw decoding, evr-cp
dual: 15% cpu load, 3840x2160_h264_8-bit_40m_30fps, sw decoding, evr-cp

Dual channel of course

Originally Posted by Nintendo Maniac 64

(in particular I get ~42fps with 3840x2160 60fps VP9 videos on "only" my dual core Pentium G3258 @ 4.6GHz with ~100% CPU utilization).

It's time for a small test.

For anyone interested, I downloaded this 4K60fps VP9 clip from YouTube.
The first 70s is here:
https://www.sendspace.com/file/o0oe5t

Using my system above Win 10 x64 - MPC-HC x64 v1.7.9.190 - Core i7 4790 - iGPU HD 4600, I always get a few (1 to 4) dropped frames in the first 70s, the CPU utilization goes up to 70% (8 threads), the sound silences a few times and the frame rate drops to ~52fps a few times.

What are your results using EVR-CP?

[MoSal]

I did do a blind test - it's definitely not placebo because until I turned my monitor back on, I thought the track that sounded higher quality even with lower volume was for sure going to be the Opus track, but when I turned my monitor back it was revealed that the track that I thought sounded better was actually the AAC track, not the Opus one.

For reference, my configuration is to use foobar2000 + ASIO (so no resampling on my Xonar DS), both tracks have replaygain metadata, playback order set to "Repeat (track)"; from there I put both audio tracks into a single playlist in foobar2000, start playing one of the audio tracks, turn off my monitor, then press the "Page Down" key (keyboard shortcut for "next track") a bajillion times until I've completely lost count of what track is playing at a given time and then I just press "Page Down" again to switch between tracks, once I've chosen which one sounds better I let it play and then turn the monitor back on and see which track is actually playing.

That'a not how you do (double-)blind tests. For starters, the levels must be matched.

You can use this component in foobar2000:
http://www.foobar2000.org/components/view/foo_abx

After that blind test I compared the AAC and Opus tracks to the original FLAC via Audacity by lining up the waveforms, doing an invert, and mixing the waveforms together, and the 192kbps AAC track was definitely more similar to the original FLAC than the Opus version was to the same FLAC; in other words, the AAC track when inverted and mixed with the FLAC gave a considerably quieter resulting waveform than when I mixed the inverted Opus track with the FLAC.

That's not a valid way to evaluate lossy codecs. You wouldn't use PSNR to evaluate
video quality, would you?

[wanezhiling]

Originally Posted by NikosD

For anyone interested, I downloaded this 4K60fps VP9 clip from YouTube.
The first 70s is here:
https://www.sendspace.com/file/o0oe5t

Using my system above Win 10 x64 - MPC-HC x64 v1.7.9.190 - Core i7 4790 - iGPU HD 4600, I always get a few (1 to 4) dropped frames in the first 70s, the CPU utilization goes up to 70% (8 threads), the sound silences a few times and the frame rate drops to ~52fps a few times.

What are your results using EVR-CP?

Similarly here, can't watch it fluently at all. http://i.imgur.com/Aymeu6T.png

But PotPlayer x64 seems just fine, stable 60 all the time. http://i.imgur.com/HaQNOlT.png


i7 4710MQ@2.5G
HD 4600 with latest 4294 driver
16g(8*2) Dual channel
win 8.1 with up3
MPC-HC x64 1.7.9.190
PotPlayer x64 1.6.56209

[NikosD]

Originally Posted by wanezhiling

Similarly here, can't watch it fluently at all. http://i.imgur.com/Aymeu6T.png

But PotPlayer x64 seems just fine, stable 60 all the time. http://i.imgur.com/HaQNOlT.png

Can you enable everything from the View menu of MPC-HC like statistics, information etc and watch dropped frames and framerate.

My experience is very smooth, but I see occasionally dropped frames and framerate, the sound silences at moments and the CPU utilization never goes more than 70%.

The VP9 decoder probably is not optimized for 8 threads.

[wanezhiling]

Originally Posted by NikosD

Can you enable everything from the View menu of MPC-HC like statistics, information etc and watch dropped frames and framerate.

terrible. http://i.imgur.com/cRjsY4t.png

[wanezhiling]

Originally Posted by wanezhiling

Similarly here, can't watch it fluently at all. http://i.imgur.com/Aymeu6T.png

But PotPlayer x64 seems just fine, stable 60 all the time. http://i.imgur.com/HaQNOlT.png

Found the reason, PotPlayer outputs YV12 by default on iGPU and MPC-HC(LAV) outputs NV12 by default on all GPUs.

@NikosD, try to disable LAV's NV12(then will auto use YV12) and you will get something surprised

[NikosD]

Originally Posted by wanezhiling

@NikosD, try to disable LAV's NV12(then will auto use YV12) and you will get something surprised

I really, really can't believe in my own eyes!

This is something unbelievable, it's the first time that I can play everything in EVR-CP without problem using my iGPU.

By disabling NV12, LAV video uses YUY2 and the 4K60fps VP9 clip above can be played at around 20-30% CPU usage using only 2 to 4 cores, depending on the bitrate.

But when seeking, I can see just for a sec, the CPU usage going even 70% using all 8 threads.

During normal playback, it's always a steady 60fps realtime playback with no problem in sound at all.

I can even decode those 4K120fps H.264 using EVR-CP I was complaining in my previous post.

You solved an issue I had for the last 2 years!

I owe you a favor, at least!

I don't know if LAV Video can or should do something about it, like disabling NV12 for iGPU.

Or Intel.

[nevcairiel]

NV12 is the correct format to use for perfect unmolested quality, and its in general the most GPU friendly 8-bit 4:2:0 format. Its also the same format that a hardware accelerator decodes to.
My guess is that disabling it forces the GPU (or something inside EVR-CP) to do something different, like using a lower quality scaling algorithm, which boosts performance at the expense of quality, or something like that.

YUY2 is a 4:2:2 format, which means LAV has to upsample chroma, which is never good for quality.
Perfect bit-exact quality is always LAVs primary goal, and NV12 ensures that.

If it only affects EVR-CP, and normal EVR works fine, it might as well be a problem in MPC-HCs renderer code.
Might make sense to start poking there.

[wanezhiling]

Originally Posted by NikosD

By disabling NV12, LAV video uses YUY2

Hmmm.. YV12 should be automatically used when NV12 is disabled only, at least here.



@nevcairiel, YV12 won't lose quality in such situation, right?

[Nintendo Maniac 64]

Originally Posted by wanezhiling

@NikosD, try to disable LAV's NV12(then will auto use YV12) and you will get something surprised

O_o What the crap, this let's me play 3840x2160 VP9 videos at 56fps - that's a 33% increase over my previous 42fps! I'm a beta tester for SVP, and any and all extra CPU headroom on video playback is very important for such a program, so I'm definitely going to have to do more testing regarding this with various different hardware and possibly report this back to the SVP devs...

For reference I'm also using Haswell integrated graphics.

Originally Posted by wanezhiling

@nevcairiel, YV12 won't lose quality in such situation, right?

I would definitely like to know this as well since SVP currently can only handle 8bit 4:2:0 video signals as an input.


----------------------------------------------------------------

MoSal, just want to let you know that, several months ago (maybe even a year?) an audio-focused discussion got removed from one of the VP9 threads on Doom9 because the mods deemed it as off-topic. I had a lengthy post typed up and even posted, but I've since edited it out due to the fear of off-topic-ness.


I will at least say the following quick things:

1. That utility it does not work well with ASIO without a hardware volume control and also doesn't account for AAC's extra bit of silence at the beginning.

2. Even with a successful ABX test it only tells you that I can tell the difference, not which is higher quality than the other.

3. I said I applied ReplayGain to both tracks via foobar2000.

4. I mentioned volume because humans perceive louder volumes as sounding better.

5. Of course the inverted waveform comparison isn't really valid, that's why I did it after my testing.

[NikosD]

Originally Posted by nevcairiel

My guess is that disabling it forces the GPU (or something inside EVR-CP) to do something different, like using a lower quality scaling algorithm, which boosts performance at the expense of quality, or something like that.

It is true that when the camera zooms in from 28 sec to 39 sec, the picture in windows mode looks like a little weird around the grass, like transparent water floating around.

In full screen (1920x1080), everything looks good.

Originally Posted by nevcairiel

If it only affects EVR-CP, and normal EVR works fine, it might as well be a problem in MPC-HCs renderer code.
Might make sense to start poking there.

Using EVR and disabling NV12, nothing really changes.
There are no artifacts around the grass, like in EVR-CP and no performance increase.

I can't see what is the output type, because EVR doesn't allow Ctrl-J option of MPC-HC which needs a layer over the image.

Is there any other way to see what output type MPC-HC uses with EVR renderer ?

[MoSal]

Originally Posted by Nintendo Maniac 64

MoSal, just want to let you know that, several months ago (maybe even a year?) an audio-focused discussion got removed from one of the VP9 threads on Doom9 because the mods deemed it as off-topic. I had a lengthy post typed up and even posted, but I've since edited it out due to the fear of off-topic-ness.

Okay.
We can stop here, or move the discussion to HydrogenAudio if you like.

I will at least say the following quick things:

1. That utility it does not work well with ASIO without a hardware volume control and also doesn't account for AAC's extra bit of silence at the beginning.

Maybe.
I don't personally use foobar2000, or Windows for that matter.

2. Even with a successful ABX test it only tells you that I can tell the difference, not which is higher quality than the other.

The mere presence of an audible difference would be surprising to me at those bitrates.

3. I said I applied ReplayGain to both tracks via foobar2000.

But why did you need to do this. They both come from the same source and their loudness is very close (1.74 dB vs. 1.72 dB using loudness-scanner). There could be something wrong with foobar2000 or the way you use it!

4. I mentioned volume because humans perceive louder volumes as sounding better.

Not in the presence of clipping. And if your Opus stream plays much louder than the AAC stream, then there is a huge gain applied that could be causing clipping.

[wanezhiling]

Originally Posted by NikosD

I can't see what is the output type, because EVR doesn't allow Ctrl-J option of MPC-HC which needs a layer over the image.

Is there any other way to see what output type MPC-HC uses with EVR renderer ?

You did a totally wrong way to see the output type, and now I knew why you said 'YUY2'
Correct way: step1, step2

Originally Posted by nevcairiel

If it only affects EVR-CP, and normal EVR works fine, it might as well be a problem in MPC-HCs renderer code.

No.
It doesn't matter which renderer is used.
'NV12+vanilla EVR' is much better than 'NV12+EVR-CP', that's true.
But 'NV12+vanilla EVR' is still much heavier than 'YV12+vanilla EVR', and 'NV12+vanilla EVR' is even a litte heavier than 'YV12+EVR-CP'!!
The 'NV12' colorspace is just horrible for iGPUs.....



==========
With Nintendo Maniac 64's another verification, now we can make a conclusion: all media player should use YV12 by default instead of NV12 on Intel platform in order to avoid significant performance loss.

[Aleksoid1978]

Originally Posted by wanezhiling

The 'NV12' colorspace is just horrible for iGPUs.....

Maybe you try to write about this "trouble" to Intel developers/engineers