Firefox 44 released [LWN.net]

Firefox 44.0 has been released. With this version Firefox can get push notifications from your favorite sites. This release also features improved warning pages for certificate errors and untrusted connections, H.264 is enabled if the system decoder is available, if MP4/H.264 are not supported WebM/VP9 video support is enabled, the brotli compression format via HTTPS content-encoding is supported, and more. See the release notes for details.

to post comments

WebM/VP9

Posted Jan 26, 2016 20:45 UTC (Tue) by epa (subscriber, #39769) [Link] (11 responses)

I don't get it. WebM is enabled but only on machines that don't have a system H.264 decoder? Why not enable it unconditionally?

WebM/VP9

Posted Jan 26, 2016 22:21 UTC (Tue) by dowdle (subscriber, #659) [Link] (10 responses)

I'm not sure what is meant by that either. I'm guessing it is just badly worded. Perhaps it is trying to differentiate a preference rather than a capability. I upgraded to Firefox 44 on a Microsoft Windows host (I expect Fedora updates in a week or so) and pointed it to direct .mp4 and .webm links... and both play fine. Perhaps when a javascript based player asks the browser what do you have, mp4 might be preferred if it is available, but webm (both vp8/vorbis and vp9/opus) should still work when needed. If you haven't tried vp9-based webm, I think it kicks H.264's butt with regards to the compression / quality ratio. Of course they haven't put a lot of effort in optimizing the vp9 encoder so it does take considerably more resources to encode it.

Example? Well, it is a specific genre but here is an 11 minute screencast I recorded (no audio) in a reasonable resolution in webm that is only 1.7MB in size:
https://www.montanalinux.org/files/videos/alpine-based-op...

I mean, that is smaller than your average high resolution smartphone .jpg.

Sorry to get off topic. :)

WebM/VP9

Posted Jan 27, 2016 6:25 UTC (Wed) by fratti (subscriber, #105722) [Link] (7 responses)

>If you haven't tried vp9-based webm, I think it kicks H.264's butt with regards to the compression / quality ratio

Depends. If you do a PSNR based comparison, sure. If you do a double-blind study and use a proper H.264 encoder (such as x264), then no. In the double-blind studies I've seen, VP8 and VP9 actually end up looking a bit embarrassing, as the encoder is clearly tuned for PSNR and will create a blurry mess of an output as long as the flawed metric tells it it's good.

Additionally, encoder bugs cause various decreases in quality that are unavoidable regardless of the number of bits you throw at it. I've seen libvpx make quite a mess of brightness before.

Using 10-bit encoding with x264 (which due to increased precision during motion prediction stages makes the files *smaller*, as the quanitsation takes care of the added bits anyway), H.264 actually still looks pretty competitive today.

I think the only thing VP9 has going for it, compared to H.265/HEVC, is the patent pool situation. However, neither the patents in those pools nor Google's claim of VP9 not being affected by the very same patents despite coding similarities have ever been reviewed in court to my knowledge.

One thing is for sure though, it'll be a few more years until we have an encoder as great as x264 again. And seeing as Google/On2 is currently busy working on VP10 (leading to the entire family being mockingly referred to as VPgit-HEAD by some), their priorities do not appear to be in making the best of their existing standard.

WebM/VP9

Posted Jan 27, 2016 11:06 UTC (Wed) by Otus (subscriber, #67685) [Link] (6 responses)

> In the double-blind studies I've seen

Any links? I haven't seen any and would be interested.

WebM/VP9

Posted Jan 27, 2016 18:10 UTC (Wed) by jensend (guest, #1385) [Link]

I'm willing to bet he's referring to a couple of blind tests that were done with very immature prerelease versions of VP9 from early-to-mid-2013. I've seen more recent subjective tests where VP9 beats x264 solidly.

PSNR is certainly not the only objective metric by which libvpx does much better than x264. For instance, last year's Moscow State University tests use SSIM, and libvpx came out behind x265 but barely ahead of the best non-x265 HEVC encoders and well ahead of x264. Or you can look at Xiph's automated test site http://www.arewecompressedyet.com which shows x264, x265, libvpx, and Thor as comparison points for all their Daala builds, and shows libvpx 1.4 doing quite well in different metrics.

WebM/VP9

Posted Jan 27, 2016 19:15 UTC (Wed) by fratti (subscriber, #105722) [Link] (2 responses)

Here's one: http://infoscience.epfl.ch/record/207496/files/QoMEX2015_... (From 2015)

Following the blogs of FFmpeg/Libav developers can also yield some interesting opinions about VPx: http://codecs.multimedia.cx/?p=851

WebM/VP9

Posted Jan 27, 2016 21:21 UTC (Wed) by jensend (guest, #1385) [Link] (1 responses)

The study you linked used a 2013 unstable version of libvpx and chose to restrict encoder options in a fashion that has nothing to do with the way most web video is played. The authors are the same ones who published the other flawed study I was referring to, and their biases are very much in question.

The "interesting opinions" you linked are angry ridiculous immature ranting from somebody who apparently thinks "Google" is a swear word.

WebM/VP9

Posted Jan 27, 2016 23:08 UTC (Wed) by fratti (subscriber, #105722) [Link]

>The "interesting opinions" you linked are angry ridiculous immature ranting from somebody who apparently thinks "Google" is a swear word.

He's also a Libav developer, so he very likely knows more of the topic than either of us do.

VPx is not an encoder as "open" as some people want to believe, it's developed behind closed doors at On2/Google and they'll publish a new standard whenever they damn well please, which they appear to do every 18 months, making hardware decoder implementations a lost cause.

WebM/VP9

Posted Jan 27, 2016 22:25 UTC (Wed) by MoSal (guest, #103113) [Link] (1 responses)

* x264 is still the best codec for visually transparent encodings.

* x264 is still the best encoder for grainy sources.

* x265 and libvpx/VP9 produce better HD encodings at low bitrates (courtesy of larger transform sizes). Not having to downscale, to get an acceptable result, seems to be impressing many people!

* The blurry (good for metrics) output of x265 seems to be liked by 2D animation fans.

* Google recently offered their VPx work to the Alliance for Open Media (AOM). That means they reached a point where they are confident about their standing patent-wise. I wouldn't put any links here, as this move is still largely unannounced.

* The AOM and the IETF are supposed to be cooperating to produce a next-generation royalty-free codec. Mozilla and Cisco have already made real contributions with Daala and Thor. Google is expected to join soon with their VP9/VP10 work.

* Of the three technologies mentioned above, I find Daala the most interesting. It certainly has the potential to dethrone x264.

WebM/VP9

Posted Jan 27, 2016 23:11 UTC (Wed) by fratti (subscriber, #105722) [Link]

I agree that Daala is the most interesting of those technologies, if not the most interesting video compression technology in general in the last decade. I really hope Mozilla and Xiph can succeed with it.

WebM/VP9

Posted Jan 27, 2016 7:37 UTC (Wed) by mgedmin (guest, #34497) [Link] (1 responses)

The quality of that screencast looks amazing! What tools did you use to record and encode it?

WebM/VP9

Posted Jan 27, 2016 22:30 UTC (Wed) by chirlu (guest, #89906) [Link]

I guess that answer was intended to go here: https://lwn.net/Articles/673726/

Firefox 44 released

Posted Jan 26, 2016 22:23 UTC (Tue) by dowdle (subscriber, #659) [Link] (5 responses)

Another thing worth mentioning is that there is a notice in Firefox 44 that Tab Groups is finally going to be removed in Firefox 45. I really love tab groups so I'm happy to see there is a workable alternative in another 6 weeks when they get yanked:

https://support.mozilla.org/en-US/kb/tab-groups-removal

Firefox 44 released

Posted Jan 26, 2016 23:56 UTC (Tue) by testsilicon (guest, #96703) [Link]

I really find Tab Groups useful too. I run the beta version of Firefox and I'm happy to say that the Tab Groups add-on is working great.

Firefox 44 released

Posted Jan 27, 2016 4:32 UTC (Wed) by sheepdestroyer (guest, #54968) [Link] (2 responses)

Tab Groups functionality has been ported as an add-on here :
https://github.com/Quicksaver/Tab-Groups
https://addons.mozilla.org/en-US/firefox/addon/tab-groups...

You can install it right now and it will replace the current implementation. Your groups will be seamlessly migrated. Happy user myself.

Firefox 44 released

Posted Jan 31, 2016 17:03 UTC (Sun) by vbabka (subscriber, #91706) [Link] (1 responses)

I expect with the new extension api and after the current one gets inevitably ditched, this extension won't be possible anymore?

Firefox 44 released

Posted Feb 4, 2016 6:17 UTC (Thu) by ssokolow (guest, #94568) [Link]

Their goal is to have a two-tiered setup where 99% of extensions get along just fine with the base WebExtensions API and, if that doesn't meet your need, you can write a manually reviewed "native.js" library extension which can be auto-installed as a dependency when people install your main extension.

Said library extension will be able to hook into the browser's guts like before with the intent being that "native.js" extensions be uncommon and, eventually, supplanted by additions to the built-in API.

(Source: Reading through the "blocks" and "blocked by" dependency tree on Bugzilla starting from the "Are we Web Extensions yet?" site.)

Firefox 44 released

Posted Jan 27, 2016 15:54 UTC (Wed) by dowdle (subscriber, #659) [Link]

I just used vokoscreen (in rpmfusion for Fedora) which produced a 175.9 MB .mkv file. I then used ffmpeg two pass to convert it to webm with an upper bitrate of 200k.

Firefox 44 released

Posted Jan 26, 2016 22:41 UTC (Tue) by josh (subscriber, #17465) [Link]

Great to see Firefox supporting the Service Worker API. In addition to enabling push notifications, this also provides a much better alternative for offline web applications, or for web applications that support caching. Service Worker allows applications to implement their own resource fetching policy in a client-side script, running separately from the page.

Firefox 44 released

Posted Jan 26, 2016 23:43 UTC (Tue) by trenton (guest, #106520) [Link] (5 responses)

>H.264 is enabled if the system decoder is available, if MP4/H.264 are not supported WebM/VP9 video support is enabled

Does it mean that they will finally start to work on hardware video decoding on Linux? Or the opposite -- that they won't work on it, because they provide the VP9 as a less computationally expensive alternative now?

Firefox 44 released

Posted Jan 27, 2016 0:50 UTC (Wed) by nix (subscriber, #2304) [Link] (4 responses)

I think the actual change is likely to be 'support VP9 on systems with no H.264 support, rather than disabling it on such systems': the behaviour on systems *with* H.264 support appears to be unchanged. (Not that I can find an actual commit implementing either of these...)

Firefox 44 released

Posted Jan 27, 2016 2:28 UTC (Wed) by trenton (guest, #106520) [Link] (1 responses)

> rather than disabling it on such systems': the behaviour on systems *with* H.264 support appears to be unchanged

I wasn't talking about disabling H.264.

Linux version of Fx still does not have support for hardware-accelerated video (H.264) decoding. I am simply afraid that as Mozilla started to ship VP9 as less computationally expensive alternative to (software decoded) H.264, they will be reluctant to work on hardware acceleration of H.264 (as if they weren't reluctant now).

Firefox 44 released

Posted Jan 27, 2016 7:37 UTC (Wed) by iabervon (subscriber, #722) [Link]

It looks like they're going entirely to using ffmpeg when possible, so it should use hardware acceleration where it's available, and Firefox is the wrong place to add new hardware acceleration support if someone's going to write it.

Firefox 44 released

Posted Jan 27, 2016 15:01 UTC (Wed) by tterribe (guest, #66972) [Link]

> (Not that I can find an actual commit implementing either of these...)

Here is the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1190970

Firefox 44 released

Posted Jan 27, 2016 19:41 UTC (Wed) by kenmoffat (guest, #4807) [Link]

At the risk of taking this O/T (to discuss youtube rather than firefox), I built ff44 on my test machine last night, several times for different semi-recent systems. I had been told it now used ffmpeg for playing youtube, if available at runtime, so I started with a full system and confirmed it appeared to do that. By the end, I was on a partially-built system (no AV, apart from the parts I build *before* firefox : the ogg and theora stack, flac, libvpx, gstreamer with only the base plugins).

To my immense surprise, even that build was able to play all the youtube selections I tried on it, even stuff originally uploaded several years ago.

I assume google have 'upgraded' all available clips to newer formats (one clip at least had only been flash when I first looked at it some years ago), so does anyone know which AV packages are now the minimal requirement for firefox to be able to play youtube ?

Firefox 44 released

Posted Jan 27, 2016 1:15 UTC (Wed) by Zizzle (guest, #67739) [Link] (6 responses)

But have they fixed the crashers?

FF crashes reliably by just scrolling down on facebook on Fedora 23. Fresh profile, no add-ons.

Firefox 44 released

Posted Jan 27, 2016 2:19 UTC (Wed) by luto (subscriber, #39314) [Link]

Are you using the nvidia binary driver by any chance?

Firefox 44 released

Posted Jan 27, 2016 4:41 UTC (Wed) by roc (subscriber, #30627) [Link] (2 responses)

Sorry to hear that FF crashes reliably *for you*. Certainly it doesn't crash on Facebook for all Linux users (me, for instance). And unfortunately we haven't fixed all crash bugs for all users.

If you file a Bugzilla bug hopefully someone will work with you to narrow it down.

Firefox 44 released

Posted Jan 28, 2016 2:44 UTC (Thu) by Zizzle (guest, #67739) [Link] (1 responses)

I just looked into about:crashes

Seems it's libavcodec that is doing the crashing. As far as I can see in about:config I'm pretty much using all defaults.

Any downsides to disabling ffmpeg?

Firefox 44 released

Posted Jan 28, 2016 9:28 UTC (Thu) by roc (subscriber, #30627) [Link]

If you disable ffmpeg you probably won't be able to play MP4 videos in Firefox (well, not without Flash).

Please do file a Bugzilla bug about that crash. Whoever's fault it is, other users will probably hit it too.

Firefox 44 released

Posted Jan 31, 2016 0:23 UTC (Sun) by Tet (subscriber, #5433) [Link] (1 responses)

No, they haven't. Firefox now crashes continuously, making it unusable. I appreciate it's not doing it for everyone. But it is for me. I had to revert to the ESR version to get back to a usable browser. The critical bug I logged has been open for over a month now...

Maybe a dynamic shared library bug?

Posted Jan 31, 2016 13:31 UTC (Sun) by sdalley (subscriber, #18550) [Link]

Could it be a version/compatibility bug in a shared library that firefox uses but that your distribution has a missing/broken dependency for?

Such things, of course, can be rather outside Mozilla's control. They and other users just have to pick up the pieces when a library breaks backward compatibility etc.

No wonder bundling libraries is so attractive.

Is there a useful stack trace in the core file?

Firefox 44 released

Posted Jan 27, 2016 6:45 UTC (Wed) by mokki (subscriber, #33200) [Link] (13 responses)

Firefox is now the first browser to support brotli compression. It packs most content 15-20% smaller than gzip and is as fast to decode and not much slower to encode. Chrome has announced that they will follow.

Now it is just work for httpd, nginx, varnish and all other open source web servers to add support for on-the
-fly compression. But most sites can and should pre-compress their static files and most web servers can be configured to serve '<file>.br' files when requested with few config config lines.

Firefox 44 released

Posted Jan 27, 2016 11:16 UTC (Wed) by alankila (guest, #47141) [Link] (8 responses)

Unfortunately brotli is not fast enough compared to the compression gain to be worth enabling as a wire protocol for many/most situations. You can synthesize a test here:

https://quixdb.github.io/squash-benchmark/

using the Transfer + Proessing form. In many stream transmission cases (= compress + transfer at some rate + decompress), only lzo/lz4-style algorithms are worth considering, followed by low compression level versions of gzip.

Brotli is therefore for precompressed assets.

Firefox 44 released

Posted Jan 27, 2016 13:30 UTC (Wed) by butlerm (guest, #13312) [Link] (6 responses)

Static html compression isn't very useful. Most web pages in the world are generated on the fly. Brotli is designed to excel at that case. The compression overhead is somewhat higher, but for realistic average transfer rates between 1000 KiB/sec and 10000 KiB/sec, Brotli at low compression levels outperforms zlib at any compression level.

That is based on the very nice website you linked with Xeon E3 hardware and the enwik8 dataset. Other text type datasets are similar.

Firefox 44 released

Posted Jan 27, 2016 14:00 UTC (Wed) by alankila (guest, #47141) [Link] (4 responses)

Unfortunately if latency is an objective then you can't get the data from server to client faster than sending it uncompressed using brotli. That was rather my point. Only a handful are fast enough at transfer speeds in the 1-10 MB range.

Firefox 44 released

Posted Jan 27, 2016 14:12 UTC (Wed) by alankila (guest, #47141) [Link] (1 responses)

Apologies, a correction.

Yes, there are data sets in which brotli does get quite well in fact. Just well enough that at least few of the low compression levels such as 1, 2 or 3 can win over zlib depending on your exact dataset. At least it has the advantage of sending fewer bytes down the wire.

So, I will change my position. For at least some kinds of data, brotli streaming compression can be useful, with the caveat that it's probably not going to budge your latency figures one way or other compared to zlib. However, as another point in favor, for noncompressible data, brotli also doesn't waste a whole lot of time, and in that respect is better than any version of deflate.

I'm still mostly impressed by zstd which often appears very close up. It seems like it is some kind of mild improvement over deflate, being a bit faster and compressing a bit better, but otherwise being in the same family.

Firefox 44 released

Posted Jan 27, 2016 18:17 UTC (Wed) by butlerm (guest, #13312) [Link]

Brotli works well on most types of binary data, but it is optimized for compressing text, and html formatted text in particular:

"[Brotli] contains 13,504 words or syllables of English, Spanish, Chinese, Hindi, Russian, and Arabic, as well as common phrases used in machine readable languages, particularly HTML and JavaScript. The total size of the static dictionary is 122,784 bytes. The static dictionary is extended by a mechanism of transforms that slightly change the words in the dictionary. A total of 1,633,984 sequences, although not all of them unique, can be constructed by using the 121 transforms.”
http://www.theregister.co.uk/2015/09/23/googles_brotli_co...

On that type of text (enwik8 again), zstd looks like a stronger competitor from about 3 MB/sec to 40 MB/sec or so, and then something like LZ4 above that. If the average web client had a 24 Mbit/sec or better connection, the world would no doubt be better off going with zstd for web page compression right now. It might be a while before that is the case though.

Firefox 44 released

Posted Jan 27, 2016 14:31 UTC (Wed) by barryascott (subscriber, #80640) [Link] (1 responses)

Across the internet its the ping times that kill the latency rather then encode times surely?

Firefox 44 released

Posted Jan 27, 2016 16:34 UTC (Wed) by butlerm (guest, #13312) [Link]

By "latency" I believe the reference is to total encode + transfer + decode time. Network latency (ping time) does have an effect on the transfer rate in TCP for various reasons of course, but that is not the issue here.

Firefox 44 released

Posted Jan 27, 2016 19:23 UTC (Wed) by roc (subscriber, #30627) [Link]

Most big web pages load a lot of static JS and CSS assets, and the JS assets in particular are often large.

Firefox 44 released

Posted Feb 2, 2016 17:01 UTC (Tue) by powturbo (guest, #106766) [Link]

you or some readers might need or be interested in the new compressor benchmark program TurboBench: https://github.com/powturbo/TurboBench.
You can make your own benchmarks, with your data.

Here you can also read that, there is no visible difference for most users when you replace zopfli compression with brotli:
http://encode.ru/threads/2343-Transfer-Encoding-amp-Data-...

Firefox 44 released

Posted Jan 27, 2016 18:37 UTC (Wed) by jensend (guest, #1385) [Link] (1 responses)

I really, really feel like it's a bad idea to take an algorithm that relies on a magic list of 14,000 strings that happen to be common on today's web and enshrine that as a permanent Internet standard.

I'd feel a lot better about zstd or something like that.

If somebody other than Google showed up asking everybody to rearchitect the Web to rely on their handcrafted static dictionary, they'd be laughed out of town.

Firefox 44 released

Posted Jan 27, 2016 19:25 UTC (Wed) by roc (subscriber, #30627) [Link]

The common words in common languages, and the words used in HTML and JS, are not going to change quickly.

Ten or twenty years from now, compression technology will probably have advanced enough to introduce a new compression standard anyway. Hardware may also have evolved enough to make a different set of tradeoffs preferable.

Brotli

Posted Jan 28, 2016 14:34 UTC (Thu) by robbe (guest, #16131) [Link] (1 responses)

I disable HTTP compression on most of my httpds due to BREACH et al. Can I still profit from brotli?

Brotli

Posted Jan 31, 2016 0:53 UTC (Sun) by butlerm (guest, #13312) [Link]

Probably not. Brotli is just an alternative compression algorithm. There are a number of other practical defenses against BREACH though:
https://blog.qualys.com/ssllabs/2013/08/07/defending-agai...

Push notifications?

Posted Jan 27, 2016 20:40 UTC (Wed) by markhb (guest, #1003) [Link] (1 responses)

Did they happen to call that feature "Netcaster"? Or maybe "Marimba"?

Push notifications?

Posted Feb 1, 2016 16:04 UTC (Mon) by morhippo (guest, #334) [Link]

Great comment - I am old enough to trigger some long-unused synapses with these words... :-) Full circle.