SSSE3 optimizations for VP9 support in 64bit Pale Moon 31?

[__NM64__]

UPDATE: I have gotten confirmation from the ffmpeg-devel IRC channel that ffvp9 includes several SSSE3 optimizations that also mostly require 64-bit. Unfortunately the public IRC logs haven't updated yet so I cannot give the complete quote nor any of the direct mentions to VP9.

<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

UPDATE 2: The IRC logs are up:
http://lists.ffmpeg.org/pipermail/ffmpe ... 02201.html

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

From testing I've done over at doom9 (more details at end of post), VP9 decoding seems to take great benefit from using SSSE3 - I see around a 3x speedup in decoding just due to SSSE3. Without SSSE3, even my friend's semi-modern 2.4GHz i5-520M cannot decode YouTube's new 60fps footage at 1920x1080 in VP9 without noticeable frame-drops and the CPU fan turning into a jumbo jet taking off.

The thing is though, neither Firefox nor Chrome seem to support SSSE3 in their VP9 decoder (UPDATE: At the time of this post Chrome 64bit didn't exist). By contrast, MPC-HC's VP9 decoder seems to support SSSE3.

Considering that part of Pale Moon's features is that it actually takes advantage of semi-modern instruction sets like SSE3, it doesn't seem like much of a stretch to get those SSSE3 optimizations into future Pale Moon's VP9 decoder, especially with how demanding 60fps 1080p VP9 is.



===== SSSE3 Testing =====

I have a 2.5GHz Athlon 64 x2 4800+ Brisbane G2 and a 2GHz Core 2 Duo T5800 Merom. Most real-world CPU tests I've run show that these two CPUs have nearly identical performance if they have a level playing field (i.e. no SSSE3 optimizations). The following CPU review also leads credence to the similar performance of these CPUs: LINK (other than their Windsor Athlon having twice the L2 cache, which Tom's Hardware shows only helps K8 a bit (LINK, source), their 4800+ and E6300 are essentially slighly lower-clocked versions of my two CPUs)

On the Brisbane, MPC-HC's VP9 decoding performance is also extremely similar to the performance I get with Chrome's VP9 decoder - around 60-70% CPU utilization for 1280x720 30fps. On the Merom however, decoding the exact same VP9 video in MPC-HC is much less - only around 20-30% CPU utilization. And yet, when I play back the very same 1280x720 30fps VP9 video in Chrome on the Merom, I get 60-70% CPU utilization. In fact, my Brisbane cannot even play 1920x1080 30fps VP9 at all without major framedrops, and playing the same VP9 video in Chrome and/or Firefox 31 beta on the Merom also results in tons of frame-dropping. Of course though, in MPC-HC, the Merom manages to only have around 50% CPU usage for 1920x1080 30fps VP9; heck the Merom can just manage to even play back 1920x1080 60fps VP9 in MPC-HC.

Now consider that the Brisbane PC has a Radeon HD4200 iGP while the Merom PC only has an Intel X3100 iGP. The only thing the Merom system really has over the Brisbane system is SSSE3, and according to another doom9 user, SSSE3 has been very useful lately (LINK) (technically the Merom has twice the L2 cache, but it also lacks the integrated memory controller that the Brisbane has).

To clarify, the video decode performance of MPC-HC v1.7.5 was not noticeably different between 32bit and 64bit on the Brisbane, though admittedly I did not test MPC-HC 32bit on the Merom (which I totally should do). Also I use the exact same copies of the portable versions of Chrome, Firefox 31 beta, and MPC-HC.


UPDATE: Just did a new test on an AMD E-350 (1.6GHz). With only a 1280x720 30fps VP9 video, there were framedrops in 32bit MPC-HC and I had ~100% CPU utilization but 64bit MPC-HC played the video just fine with around 55-75% CPU utilization.

[__NM64__]

I didn't find anything that said bumping wasn't allowed, so considering that Pale Moon 25 is now a known thing and is in public testing, this is more relevent now.

For reference, Pale Moon 25 has seemingly identical VP9 decoding performance between the 32bit and the 64bit versions.

It also should be noted that Google claims that Chrome 64bit has around ~15% faster VP9 decoding compared Chrome 32bit.


(the thread title says Pale Moon 31 because it wasn't known at that time that the version after Pale Moon 24 was going to be named 25 rather than 31)

[New Tobin Paradigm]

As the person who ported VP9 to Pale Moon I wonder why we get nearly if not identical performance for 32bit and 64bit but Google has such a difference. Could you try and see if there is a performance difference between Pale Moon and Chrome?

[__NM64__]

As the person who ported VP9 to Pale Moon I wonder why we get nearly if not identical performance for 32bit and 64bit but Google has such a difference. Could you try and see if there is a performance difference between Pale Moon and Chrome?

You can test Chrome 32bit and 64bit via the PortableApps versions, which is what I'm using.
32bit
64bit

This is the video I test with:
http://www.mediafire.com/watch/o3k5anw98h584l0/A_-_720p_(1280x720_@_30fps).webm

Which was ripped/downloaded from here:
https://www.youtube.com/watch?v=BLxHjixnf3c

All testing was done in fullscreen at 1280x1024, mainly due to Firefox and Pale Moon Bug 1011390 (HTML5 video fullscreen is downscaled by a few pixels if the video and the desktop resolution are the same)


While Google says the VP9 decoder performance is better, it certainly doesn't seem to be enough. FYI my CPU is a measly AMD E-350.

Firefox, Pale Moon 32bit/64bit, Chrome 32bit/64bit: maxed out CPU, frame drops and stutters
MPC-HC 32bit: maxed out CPU, video falls behind audio, stutters in audio
MPC-HC 64bit CPU ~70% utilization, perfect video playback

[New Tobin Paradigm]

So at the end of the day.. at 720p and higher web browsers suck at playing back video where as a program specifically designed and sole purpose is to playback video works better?

Why does this not shock me..

[__NM64__]

So at the end of the day.. at 720p and higher web browsers suck at playing back video where as a program specifically designed and sole purpose is to playback video works better?

I think you missed the results for MPC-HC 32bit performing just as bad as the web browsers, yet the 64bit version of MPC-HC performed way better.

But you realize the issue is just that my CPU is too wimpy to test accurately. I've done tests on my HTPC before which has a 2.4GHz Core 2 Duo, and I know that's enough to run my test video even without SSS3 optimizations (spolier: MPC-HC 32bit performs similarly to Chrome 32bit).

However, I'll have to give you those results tomorrow because it's 4am here.


For reference, the reason I don't just test at a smaller resolution is because at those small resolutions the difference in CPU utilization between 32bit and 64bit with SSSE3 seems to be considerably dimminished.

[New Tobin Paradigm]

But you realize the issue is just that my CPU is too wimpy to test accurately. I've done tests on my HTPC before which has a 2.4GHz Core 2 Duo, and I know that's enough to run my test video even without SSS3 optimizations (spolier: MPC-HC 32bit performs similarly to Chrome 32bit).

Code: Select all

ifeq (64,$(findstring 64,$(OS_TEST)))
ASFILES += \
  vp9_quantize_ssse3.asm \
  $(NULL)
endif

I am kinda surprised that 32 and 64 bit show no real difference.

[__NM64__]

I don't think the scaling would really make much of a difference, but it's possible I derped up and didn't use a vertical resolution larger than 720 when I tested Pale Moon 25 x64, which I had tested initially and separately from everything else. Again, Bug 1011390 and all.

(the thing is, by default I have MPC-HC change my resolution to 1280x720, so I may have been running at that when I did the preliminary comparisons)

[Moonchild]

This thread is about all the wrong things.

• There is no Pale Moon 31 (well, not for a few years at the very least)
• SSSE3 is already in use, as Tobin pointed out, when x64 is used, in libvpx.
• Pale Moon is not a dedicated media player. It is a web browser.

This suggestion will get exactly 0 of my time, sorry

[__NM64__]

There is no Pale Moon 31 (well, not for a few years at the very least)

Pale Moon 25 was not announced when this thread was created, and I can no longer edit the first post and therefore the thread title.

in libvpx

Ooooooooooooh. I think that's the key right there. Everything I was referencing was ffvp9, which has noticably faster decoding than libvpx.

if you are on x64, your system will have enough oomph for it not to make a difference that you can notice in actual playback resulting from SSSE3 vs. standard optimizations already in place by the compiler.

As my epiphany just showed, that's due to it being libvpx, which has only minimal performance gains with 64bit and SSSE3.

[*]Pale Moon is not a dedicated media player. It is a web browser.

And yet if it's VP9 performance is anything like Firefox, it performs similarly to 32bit media players...

This suggestion will get exactly 0 of my time, sorry

Well of course not, it's libvpx afterall. As a reference implementation it's hardly the fastest decoder around.

[Moonchild]

Pale Moon is not a dedicated media player. It is a web browser.

And yet if it's VP9 performance is anything like Firefox, it performs similarly to 32bit media players...

Well, that's a great bonus then, isn't it?

[__NM64__]

And yet if it's VP9 performance is anything like Firefox, it performs similarly to 32bit media players...

Well, that's a great bonus then, isn't it?

Umm... 32bit media players (such as 32bit MPC-HC) peform like crap with VP9. My HTPC (T8300 Core 2 Duo) uses like 50-60% CPU utilization just for 1280x720 30fps VP9, while 1080p 30fps VP9 is too much and maxes out the CPU and has stutters and the like.

By comparison I can run 1080p 60fps VP9 with ffvp9 in 64bit MPC-HC with around 90-95% CPU utilization. Also 1280x720 30fps VP9 only uses like 20-30% CPU utilization.

[New Tobin Paradigm]

Hey.. we support VP9 like Firefox and like Chrome.. If doing something using the same code as those two with similar performance isn't enough for people.. Then maybe THEY should be reevaluating why they are watching MULTIMEDIA in a WEB BROWSER and not a MEDIA PLAYER designed expressly for that use..

Regardless.. It was a pain in the ass to port and implement and frankly and personally I don't think this should even BE the responsibility of the browser to do this but of a proper plugin.. But hey! HTML5 and all that... Remind me to --disable-* all the media codecs on my next personal build

[Moonchild]

I use a 32-bit media player and it performs perfectly fine (for the record, also MPC-HC) since it can offload video decoding and scaling to the GPU. So, different frame of reference then! Hence my expression of joy.

Even so, unless you really have an underpowered CPU to handle the decoding task, any desktop or HTPC should be able to decode up to full HD at full frame rate without any issue. If VP9 is that heavy on decoding video, then it just shows you another drawback of that particular codec.
For reference: the video in VP9 you tested with uses 10-15% CPU in 32-bit Pale Moon 25 beta. That's definitely acceptable.

(As a side note: VP9 has a really crappy visual quality as far as I can tell, anyway. So many artifacts in that video! Probably because of Google recoding? if so, YouTube isn't even a consideration to support HD video )

[__NM64__]

Hey.. we support VP9 like Firefox and like Chrome.. If doing something using the same code as those two with similar performance isn't enough for people.. Then maybe THEY should be reevaluating why they are watching MULTIMEDIA in a WEB BROWSER and not a MEDIA PLAYER designed expressly for that use..

No it's fine, I just didn't realize you guys were using libvpx, which in case you couldn't tell I have low expectations of performance-wise. I don't expect some kind of miracle like implementing ffvp9 into Pale Moon.

Regarding my remarks about performance being crap, I was just trying to establish that Firefox's VP9 decoding performance matching a 32bit media player isn't saying much - it's like saying a snail is faster than a worm.

For reference: the video in VP9 you tested with uses 10-15% CPU in 32-bit Pale Moon 25 beta. That's definitely acceptable.

You must be running a 3+ GHz Sandy Bridge or something. Try running a 60fps 1080p VP9 video instead (requires a YouTube downloader because I haven't uploaded a mirror yet):
https://www.youtube.com/watch?v=T3ny9zIckP0

(As a side note: VP9 has a really crappy visual quality as far as I can tell, anyway. So many artifacts in that video!)

It's not VP9 but the lack of bitrate. For reference, the AVC versions, both DASH and non-DASH, look worse (and the non-DASH version has a higher bitrate than the VP9 version). The problem is that video footage of F-Zero GX (the game in the video) is known to be very demanding on video codecs, which is why I used it.

If you want to see the original upload, I have it here (note that it's 3x the filesize):
http://www.mediafire.com/watch/s525ycmc ... _30fps.mp4

[Moonchild]

You must be running a 3+ GHz Sandy Bridge or something. Try running a 60fps 1080p VP9 video instead:

Nope, I'm on an old Phenom II.

Also, playing your '1080p' example on Youtube in Flash is a slideshow (and not because of CPU use @~7%) like I've never seen before. So I'm not even sure if that's a good reference? I don't have "leeching" extension to grab the webm specifically, either, so I can't verify.

[__NM64__]

Nope, I'm on an old Phenom II.

"Old". Their IPC is similar to the Core 2 Duo but they clock considerably higher (not counting overclocking), and in several cases have the highest IPC of any AMD CPU. Your Phenom II could very well have a clockrate that's 50% higher than my HTPC's Core 2 Duo.

Also Phenom II lacks SSSE3, so you actually wouldn't be able to see any performance improvements with ffvp9 if you tested it anyway (64bit without SSSE3 resulted in no improvement with ffvp9 decoding when I tested with an Athlon 64 x2 4800+).

Also, playing your '1080p' example on Youtube in Flash is a slideshow (and not because of CPU use @~7%) like I've never seen before. So I'm not even sure if that's a good reference? I don't have "leeching" extension to grab the webm specifically, either, so I can't verify.

My internet connection is only 3Mbps down/768Kbps up, so my mediafire mirror of the 60fps VP9 video was still is uploading, and as I'm typing this it's still not done even though the video is only 30MB. Guess I'll wait for it to finish before I submit this post...


*15 minutes later* The upload is done:
https://www.mediafire.com/watch/?o4o3m2em1l6i54d

[Moonchild]

Yes "old", the lack of SSSE3 should be an indicator? Also, I never overclock my components; I prefer to get normal lifetime out of my hardware, thanks.
Regardless, if you want to decode a HD movie using software only, your hands are going to be tied in any case and you will need a lot of processor power. VP9, as far as I can tell, will never be able to use DXVA techniques because of the way it's implemented, but I may be wrong and someone may actually be able to do it in the future. This means it will always be a pure-CPU codec.

Playing the 1080p VP9 video in Pale Moon 25 beta shows about 25% frame loss (in chunks because it needs to resync) on my system. The main reason for that is that, unlike MPC-HC, it doesn't use parallel threads to decode video (and before you ask: no, I'm not going to implement video decoding parallelization in a web browser). MPC-HC does use parallel threads (I had to update the player to play VP9, actually), and plays the video with no loss @~75% CPU usage distributed over 4 cores (so still pushing my hardware close to its capacity), which is comparable to what Pale Moon can do. If MPC had only one core to play with it would actually perform worse by these numbers
So.. implementations don't matter much since libvpx as-compiled in Pale Moon holds its own compared to the non-reference implementation you pitted it against. Compared to other codecs, VP9 is obviously extremely expensive for the CPU; no real surprise considering the higher compression ratio used in it. A higher compression ration that, by the way, also painfully showed itself in your 1080p video with tons and tons of artifacts the moment you don't have high contrast, with additional color bleeding. IMHO, VP9 is inferior to other codecs out there in terms of quality - it's good for saving bandwidth (providers) and bad for consumers (the users watching). I guess it shows the bias for who made the implementation.

Bottom line: MPC plays HD videos better than Pale Moon, which was to be expected. Pale Moon does, however, play VP9 videos with acceptable speed and quality for web use. if you want to fully transform your browser into a media player, then media player plugins will be your route to take.

[__NM64__]

Yes "old", the lack of SSSE3 should be an indicator?

Well the Core 2 Duo had SSSE3 back in 2006...

Also, I never overclock my components; I prefer to get normal lifetime out of my hardware, thanks.

I don't blame you, I undervolt and/or underclock.

VP9, as far as I can tell, will never be able to use DXVA techniques because of the way it's implemented, but I may be wrong and someone may actually be able to do it in the future. This means it will always be a pure-CPU codec.

I'm used to this, I've had to live with software h.264 decoding until only 2 years ago, and even then I only have a single PC with hardware h.264 decoding.

The main reason for that is that, unlike MPC-HC, it doesn't use parallel threads to decode video (and before you ask: no, I'm not going to implement video decoding parallelization in a web browser). MPC-HC does use parallel threads (I had to update the player to play VP9, actually), and plays the video with no loss @~75% CPU usage distributed over 4 cores (so still pushing my hardware close to its capacity), which is comparable to what Pale Moon can do. If MPC had only one core to play with it would actually perform worse by these numbers

Hmm, I had prevously seen Firefox seemingly using two threads for VP9 decoding, that is the CPU usage was around 70% and/or higher but was in single digit percents when the video was paused. Considering that I don't own any quad-core CPUs, this may be why I saw similar performance between it and 32bit MPC-HC.

(that was with 1280x720 30fps on an Athlon 64 X2 4800+)

A higher compression ration that, by the way, also painfully showed itself in your 1080p video with tons and tons of artifacts the moment you don't have high contrast, with additional color bleeding. IMHO, VP9 is inferior to other codecs out there in terms of quality - it's good for saving bandwidth (providers) and bad for consumers (the users watching). I guess it shows the bias for who made the implementation.

But you're in Sweden, the land of uber-internet. I'm personally on a measly 3Mbps (372 KB/s) down DSL connection. I also recall watching an hour long video where a YouTube dev stated that something like 70% of connections accessing YouTube do not originanate from what are traditinally classified as "industrialized nations".

[Moonchild]

Please don't assume you know what kind of connection I have. I'm in a small village on a DSL with an absolutely ancient DSLAM. I can be happy to have the ADSL2 standard, here. I had to pull some strings to get the ISP to mangle my port into giving me decent upstream for what I need for my dev work.
At the same time, streaming 300KB/s (that's 2400kbps which is a good rate for full HD (1080p) H.264 with 5.1 sound, for example), is certainly sufficient for streaming video in a decent resolution, even if you don't stoop to artifact-heavy codecs. No, I'm fairly sure this bitrate bias is to save large streaming sites money on bandwidth.