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

[__NM64__]

even if you don't stoop to artifact-heavy codecs.

...you are aware that h.264 breaks down even worse than VP9 at low bitrates, right? You would need something like possibly h.265 or the upcoming dalaa.

[New Tobin Paradigm]

Off-topic:

Code: Select all

--disable-opus
--disable-webm
--disable-wmf
--disable-wav

That will solve bitrate and decoding problems

[JensRex]

I've followed this thread with interest, and I just want to chime in with a point regarding the web browser vs. media player argument. While I understand the sentiment, I think the web browser today has evolved into a defacto media player. Consider YouTube, Netflix, Vimeo et.al. which (outside of dedicated apps or hacks) are not accessible using standard media players, while also being wildly popular. HTML5 being wrangled into media player duties with <video> and <audio> is also nod in that direction. Personally I think media decoding and rendering should be shipped off to the OS backend, since MF (Windows) and QT (OS X)^[*] are excellent at these things, but until that becomes reality, I think it's prudent to implement some concessions towards media playback in-browser.

[*] I don't know what Linux uses for media backend. Gstreamer?[/size]

[Moonchild]

These "concessions" are already made by providing pretty good HTML5 playback up to near-HD on average systems without problems. And providing plugin-driven HD content (Flash and Silverlight) as well as off-loading video tasks to the OS back-end where possible (Pale Moon on Windows uses the WMF back-end (on vista and later) and Gstreamer on Linux, etc.). The issue here is Google's codecs and WebM not being off-loadable in that way and the browser not being originally designed specifically for media playback (even though a lot has been done to make it possible) resulting in fully CPU-dependent decoding and rendering and as a result requiring more powerful hardware. It is also the reason why it has been high priority for Pale Moon to incorporate VP9 support - once the legal issues surrounding the codec patents were addressed. It doesn't mean, however, that the browser's focus should shift away from its core function: being a web browser. You simply cannot ask a multi-functional piece of software to be just as good at a task as a fully dedicated piece of software for that same task. Specialized software (in this case a dedicated media player) will allways be better at it.

The dependency on the web (and html5 with extras) to play media in a browser only is a choice made by the providers of such content. If that limits their audience, then that is a direct result of their own choice. Also, keep in mind that there are plenty of streaming protocols for media to choose from (rtsp, etc, and even just http streaming) that are natively supported by dedicated media players. Not using those transports is also a choice by the service providers.
Even so, it's not like SD isn't available, either.

Concessions do have limits. This is one.

[__NM64__]

Off-topic:
I'd just like to point out that comparing hardware h.264 decoding to VP9 doesn't hold much weight considering that, outside of low-powered devices, the PCs that stuggle the most with VP9 decoding are in fact the ones that lack h.264 decoding in the first place. This is simply because h.264 hardware decoding came at a time when CPU performance starting reaching a point that even software video decoding of 60fps 1080p videos was not an issue unless you were running low-powered parts like Atom, Bobcat, and possibly Jaguar.

Contrary to popular belief, outside of low-powered devices, hardware video decoding isn't as necessary and people make it out to be. For higher-powered devices, it's largely for reasons of battery life, not performance (and even then, without switable graphics, a discrete GPU doing hardware video decoding can actually consume more power than software video decoding as is the case with my sister's 8440p laptop).