A Very WebP New Year from Cloudflare | Hacker News Reader

A Very WebP New Year from Cloudflare

blog.cloudflare.com

53 pointsIcyApril17 comments

> For example, a JPEG image at https://example.com/picture.jpg that has been converted to WebP will still have that same URL. The “Content-Type” HTTP header tells the browser the true format of an image.

So if a visitor tries to download one of those images, are they going to end up saving the image with an incorrect file extension, or is it up to browsers to fix the file extension based off of the Content-Type header?

It will have the wrong file extension, but the bigger problem is that when the user tries to open the file in Preview on OSX or whatever their native picture viewing application is, chances are it will fail to open a WebP image.

I recall Facebook experimenting with WebP, but abandoned it because when users saved images from the web to their hard drives, they couldn't work out how to open the files.

Indeed Facebook tried this in 2013, and the user misery was immediate and loud [1][2].

[1] https://www.cnet.com/news/facebook-tries-googles-webp-image-... [2] http://arstechnica.com/information-technology/2013/04/chicke...

I wish cloudflare had better tooling for a/b tests. I'd love to enable this option on our site, but without a/b test evidence that it won't affect conversions I'll never get buy in from management for a feature that likely won't affect our infrastructure. It might improve conversions through faster load times but I can't prove that.

That's a very fair point. IIRC WebP uses more cpu than JPEG, so, faster transfers but will it actually enhance my customers experience with their various Android phones?

The transfer time saved is almost certainly more expensive than the CPU resources used, especially on modern devices. Depending on your browser, this may even happen off the main thread.

A more glaring problem is video, where the widespread lack of hardware acceleration for VP8, VP9, or whatever variant Youtube happens to serve by default today will burn software decoding cycles [3] (and battery life) while H.264 would decode in hardware buttery smooth.

Given that VP9 is in no way superior to H.264 [1][2], this is purely an ideological push to favor their own format over a more widely supported another, and is a clear detriment to users.

[1] http://www.streamingmedia.com/Articles/Editorial/Featured-Ar... [2] https://infoscience.epfl.ch/record/200925/files/article-vp9-... [3] https://news.ycombinator.com/item?id=13226309

In no way better? Isn't VP9 free, whereas H.264 requires patent licenses?

Not for H.264 made available at no cost on the public Internet [1]:

"Internet Broadcast AVC Video (not title-by-title, not subscription) - no royalty for life of the AVC Patent Portfolio License"

For any other uses (like Netflix, Youtube RED, and other subscription, pay-per-view and similarly commercial uses), once a company exceeds the yearly cap in license payments, they need not pay more. In 2016 the cap is $8.125 million, from 2017 to 2020 the cap is $9.75 million.

[1] http://www.mpegla.com/main/programs/AVC/Documents/avcweb.pdf

But that is still not "in no way better."

> Not for H.264 made available at no cost on the public Internet [1]:

That's only the content license. You still have to pay for the encoder and the decoder.

> from 2017 to 2020 the cap is $9.75 million.

So using VP9 saves them $9.75 million per year in licensing fees alone, never mind the bandwidth cost savings from better compression. That's a strong financial incentive to switch to VP9 today and AV1 later when it's ready.

> Given that VP9 is in no way superior to H.264 [1][2],

YouTube and Netflix disagree with you:

https://youtube-eng.googleblog.com/2015/04/vp9-faster-better...

http://techblog.netflix.com/2016/08/a-large-scale-comparison...

http://techblog.netflix.com/2016/12/more-efficient-mobile-en...

The real world experience of YouTube and Netflix across a wide variety of video says VP9 outperforms H.264. It's not ideology, it's practicality.

> and is a clear detriment to users.

Read the YouTube engineering blog post on VP9. They're optimizing for bandwidth and quality. VP9 allows them to get their users better quality at lower bandwidth.

If I understand this correctly "...removes unnecessary data...", their optimization algorithm strips metadata on the image. This would include copyright information. For every single image that they do this to it would be a crime.[1] And they face a minimum liability of $2500, up to $25,000 + lawyer fees.[2]

[1]https://www.law.cornell.edu/uscode/text/17/1202 [2]https://www.law.cornell.edu/uscode/text/17/1203

Dropbox's Lepton [1][2], an additional lossless compression layer that operates on top of JPEG, would make for a smoother transition.

If a browser natively supported Lepton, you could serve the compressed version over the wire, and still get the bit-exact original .jpg out at the end, if the user wanted to save the file.

Of course, browser support doesn't exist yet. But browser implementors, consider the gains. This isn't promoting an incompatible format, it's getting bandwidth savings while being fully backwards compatible.

[1] https://blogs.dropbox.com/tech/2016/07/lepton-image-compress... [2] https://github.com/dropbox/lepton

There's not really much point to supporting Lepton directly instead of WebP. It's (approximately) a JPEG converted losslessly into a WebP variant-- it uses a predictor very similar to the VP8 inter-block predictor and the VP8 arithmetic coder. WebP is based on VP8, so it uses the same technologies.

I'd argue the exact opposite: the two use nearly equivalent methods, but one of them is completely backwards compatible with JPEG, while the other one... isn't.

The ability to losslessly convert it between another format doesn't seem that relevant for a browser-- you still need to deploy new software to support it, at which point you might as well just use something more efficient than JPEG.

Remember, the compression is lossy to begin with.

Reply on news.ycombinator.com