|Intent to Ship: Animated WebP images||Urvang Joshi||6/27/13 9:09 PM|
Primary eng (and PM) emails
WebP Container Spec is part of libwebp v0.3.0 and can be accessed here:
Animation support was added to WebP in v0.3.0. This patch adds the same support in Blink.
Note: We already support non-animated WebP images, so this is an incremental feature addition.
Link to “Intent to Implement” blink-dev discussion
Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?
OWP launch tracking bug?
(Bug related to implementation: crbug.com/229641)
Row on feature dashboard?
|Re: [blink-dev] Intent to Ship: Animated WebP images||Darin Fisher||6/27/13 9:42 PM|
I'm supportive, but can you comment on the performance of the implementation? Animated GIFs are power hogs and really contribute much to slowing down the web. I'd imagine that animated WebP is superior, but by how much? How does it compare to the equivalent content packaged up in a video format?
I haven't studied the implementation. Does it integrate with the rendering system just like animated GIFs or does it work more like <video>?
With WebP, I understand that we now send an Accept header so web sites can incrementally adopt WebP. Does animated WebP have its own MIME type? Or, how will sites know the difference between a browser that supports animated WebP versus one that only supports static WebP?
|Re: [blink-dev] Intent to Ship: Animated WebP images||Peter Kasting||6/28/13 1:55 PM|
On Thu, Jun 27, 2013 at 9:42 PM, Darin Fisher <da...@chromium.org> wrote:
This is a concern of mine too. Animated WebP seems to use a format that is inspired by animated GIF in many ways, which worries me. Like animated GIF, it seems to be true that you can have an arbitrarily long chain of frames which cannot be decoded correctly without first decoding the previous frame, making seeking more problematic.
This one I do know: the integration is just like animated GIFs.
|Re: [blink-dev] Intent to Ship: Animated WebP images||new...@gmail.com||6/29/13 3:48 AM|
I think large animations could cause performance problems because the browser tries to re-decode them again and again, for every new loop. And "large" limit is not that big, only 5MB in sum of all decompressed frames. These days, it's like half of GIFs on the internet would go over that limit. Just one such GIF on the page, and CPU's work will never stop.
The limit is hardcoded as 5242880 in Source/core/platform/graphics/BitmapImage.cpp
P.S. I can't figure out how to make animated WebP work, even by using --experimental-webkit-features runtime flag on a just-compiled build (209277). Am I missing something?
|Re: [blink-dev] Intent to Ship: Animated WebP images||Alpha Lam||6/30/13 7:51 PM|
2013/6/27 Darin Fisher <da...@chromium.org>
I've done some study. I downloaded 63 cats animated GIFs from tumblr. I compared file size transcoded from GIF using Animated WebP (lossy, no alpha, constant PSNR 42dB) and WebM (VP8, constant PSNR 42dB).
Animated WebP (lossy) on average is about 38% of the same GIF. WebM (VP8) is on average is about 52.7% of Animated WebP.
Numbers here: https://docs.google.com/a/google.com/spreadsheet/ccc?key=0AofjqgfYdd-idERuajF2VHJiT2NlNGlsVW9zYUUxSEE#gid=0
Quality level is the same for WebP and WebM. See source files, patches and scripts: ~hclam/cats.tar.gz
Note I have not tested with alpha channel vs VP9. But I expect VP9 to compress even better than VP8.
It is implemented exactly like GIFs.
|Re: [blink-dev] Intent to Ship: Animated WebP images||Tom Wiltzius||7/1/13 11:02 AM|
On Sun, Jun 30, 2013 at 7:51 PM, Alpha (Hin-Chung) Lam <hc...@google.com> wrote:
I'd be more worried about performance implications of rendering than the over-network size (I think this is what Darin was getting at?).
Is this intrinsic to the format, e.g. with the bad seeking characteristics Peter mentions above? Or just that's how it's implemented for now?
Do we have any hope of teaching the compositor how to run these animations? If arbitrarily-many-frames-long main-thread decodes are the only way we can implement these animations I fear we're stuck in a world where performance will never be good.
|Re: [blink-dev] Intent to Ship: Animated WebP images||Urvang Joshi||7/1/13 12:02 PM|
Some good points! Some have already been answered. To answer the rest:
On Mon, Jul 1, 2013 at 11:02 AM, Tom Wiltzius <wilt...@chromium.org> wrote:
WebP images have some advantages over GIF:
Moreover: as Adam mentioned in "Intent to implement..." thread: "supporting animation in WebP is valuable because one common use of WebP is as a transcoding target by CDNs and other intermediaries (especially for mobile). Supporting animations lets these intermediaries transcode animated GIFs as well as other image formats."
The mime type for non-animated and animated WebPs is the same, in fact. However, this should not be an issue in the long run due to Chrome auto-updates.
|Re: [blink-dev] Intent to Ship: Animated WebP images||Peter Kasting||7/1/13 12:17 PM|
On Mon, Jul 1, 2013 at 12:02 PM, Urvang Joshi <urv...@google.com> wrote:
Are you referring to the "DisposeOverwritePrevious" value in ImageDecoder.h? If so, the GIF spec was written in a time where storing this decoded data was murderous on memory; that's no longer true, and these days, use of this method is actually a performance _advantage_, because it means frames with this method can always be discarded without affecting the decoder's ability to decode other frames.
Indeed, it's actually the DisposeNotSpecified/DisposeKeep methods (which do the same thing) that are problematic for performance, and WebP uses these. So to answer Tom's question, yes, I believe the bad seeking characteristics of GIFs apply to WebP in general as well.
The biggest format change I can think of to improve decode performance would be to store with each frame information about what previous frames are necessary to decode in order to decode this frame. We recently added code to our image decoders to get a conservative estimate of this, but the encoder knows enough that it could set this more accurately.
Once we get to the point where we support deferred decoding of animated images, this point will be moot; even without that, I don't think this is a huge factor.
Long term I don't believe we will need to decode on the main thread.
|Re: [blink-dev] Intent to Ship: Animated WebP images||Alpha Lam||7/1/13 1:15 PM|
2013/7/1 Peter Kasting <pkas...@google.com>
That's right. The format is deeply inspired by GIF and does not allow specifying a frame explicitly as a key frame (not needing anything before to decode that frame). This feature is critical to to Web because an image should be paused when it's outside of the viewport, discarded in memory and then when it's scrolled into view resume from an arbitrary frame. Without this feature we'll have to cache multiple frames which is not desirable. On mobile most likely the cache will be evicted. Decoding it on impl thread can help but it's still a heavy workload.
MP4 and Matroska (WebM) containers both have this optimize-for-the-web-mode, I'd like to see such feature in Animated WebP. I'd suggest the format support this feature and the tools for generating WebP automatically inject key frames at interval by default.
That's not a huge advantage over GIF, we can now parse GIF really lightly.
FYI: The change to move decoding off main thread for animated images is under review.
|Re: [blink-dev] Intent to Ship: Animated WebP images||Alpha Lam||7/1/13 5:40 PM|
2013/7/1 Urvang Joshi <urv...@google.com>
I really don't think it's a good idea to transcode animated GIF to animated WebP:
1. WebM compress better.
I ran transcoding GIF to WebM and WebP as 42dB PSNR. The data set was 6900 images randomly sourced from Google Image Search. On average WebM with the same quality is 66% of Animated WebP. WebP is on average 78% of GIF. Please ask me for the data set if anyone is interested.
2. Animated WebP provides no advantage in seeking / caching over GIF.
As mentioned earlier. Animated WebP does not make seeking easier than GIF and put the same amount of cache stress. Comparing with WebM which can provide key frame index in header, it's a clear advantage over animated WebP.
3. Animated WebP is harder to decode than GIF.
The codec complexity is simply higher than GIF. There's a lot more stages in WebP, entropy coding, intraframe coding, IDCT, color space conversion, upsampling. GIF only has entropy coding.
|Re: [blink-dev] Intent to Ship: Animated WebP images||Elliott Sprehn||7/1/13 5:47 PM|
Why support Animated WebP at all then? :)
|Re: [blink-dev] Intent to Ship: Animated WebP images||Peter Kasting||7/1/13 5:56 PM|
+CC skal for the format issue below (last paragraph).
I don't know what the ":)" here means, but this has been discussed before. There are a variety of environments where images are accepted but videos are not; browsers may be set to automatically play (or automatically block) videos differently than images, in a way that makes using a video resource problematic; animation support makes WebP a single format which can support basically all important functions of images (regardless of whether that's the best option from a performance perspective); etc.
I am not so opposed to transcoding as Alpha's comment seems to be. There is simply a tradeoff: animated WebP can achieve better compression than animated GIF at the cost of potentially being more costly to decode. I'm also not convinced animated WebP is always going to be more costly to decode than GIF; at least a few things are in WebP's favor, such as not having to look up the color values in a palette for every pixel.
If the WebP format were to include more comprehensive and accurate keyframing, we could at least attenuate the worst case decode times, and possibly improve decode speed in general. I don't know how possible something like this is; it would have been nice to be consulted by the folks creating the WebP format spec during the process of implementing animation support, and maybe now it's too late.
|Re: [blink-dev] Intent to Ship: Animated WebP images||Alpha Lam||7/1/13 8:30 PM|
2013/7/1 Peter Kasting <pkas...@google.com>
I did some performance testing using the decoders in Blink. See attached patch.
Selected ~800 GIFs for transcoding. Again please ask me for the data set. I'm happy to provide.
* Lossy (42dB PSNR) animated WebP on average is 2.6x of GIF
* Lossless animated WebP on average is 1.5x of GIF
* Lossy (42dB PSNR) animated WebP on average is 86% of GIF
* Lossless animated WebP on average is 83% of GIF
I don't see much benefits transcoding GIF to animated WebP given all the factors combined. And no one has tried to optimized GIF for ~10 years.
There's two use cases for a new format for animated images:
1. For transcoding
Animated WebP shows a slight advantage in size but performance is worse and format-wise is no better than GIF.
2. For encoding source material
Note that a lot of GIFs use today is for encoding shot video clips. Apparently using lossless WebP to encode them will result in undesirable large files. Using lossy WebP to encode them is no better than a real video codec. Either way for this use case WebM is the best format for the job.
There are use cases where an <img> tag cannot be replaced by <video>. What about serving WebM files in <img> and internally use the video playback pipeline? This way we promote the best compression for all use cases for about the same CPU usage as lossy WebP. And it has already been optimized to decode off main thread and takes advantage of GPU acceleration.
|Re: [blink-dev] Intent to Ship: Animated WebP images||Alpha Lam||7/1/13 8:36 PM|
2013/7/1 Alpha (Hin-Chung) Lam <hc...@google.com>
Just to emphasize my worry about this use case. Please look around tumblr and almost all animated GIFs are from some kind of video clips. Using a true video codec compresses a lot better than an image codec.
|Re: [blink-dev] Intent to Ship: Animated WebP images||Pascal Massimino||7/2/13 4:50 AM|
On Mon, Jul 1, 2013 at 8:36 PM, Alpha (Hin-Chung) Lam <hc...@google.com> wrote:
(note: 42dB is high (_if_ you had a clean source, agreed). Either you go lossless, or you go video-style with a PSNR in the 35-37dB whereabouts)
Note that if you start from the GIF as source and transcode it to WebP, you're at a disadvantage compared to
starting from the real video clip most GIFs seems to be aiming at. We provided the gif2webp tool as a bootstrap
utility, but going forward this should be avoided (working on this).
Yes, there's a thin line to walk between what is a 'video', what is an 'animation', what is an 'avatar' made of few animated frames, what is a logo, etc.
We deliberately didn't make the Animated WebP format too smart (esp. for frame prediction), so as not to derail people from using <video>
when it makes sense. That being said, WebP still offers reasonable advantage over GIF (but less than WebM of course, on purpose):
you can mix lossy/lossless, you have better alpha support, have a possibility for per-frame palette, etc. Just because the tools to
leverage these is not there yet (if you stick to gif2webp) doesn't mean this format doesn't have a place inbetween static <img> and <video>.
This is already possible right now, irrespective of WebP, and...
...well, there's certainly an educational aspect to it. Some site are smarter than tumblr at using both WebP and WebM where appropriate.
For instance: www.memecenter.com
|Re: [blink-dev] Intent to Ship: Animated WebP images||Alex Russell||7/2/13 9:16 AM|
On Mon, Jul 1, 2013 at 7:02 PM, Tom Wiltzius <wilt...@chromium.org> wrote:
|Re: [blink-dev] Intent to Ship: Animated WebP images||Peter Kasting||7/2/13 10:09 AM|
On Mon, Jul 1, 2013 at 8:30 PM, Alpha (Hin-Chung) Lam <hc...@google.com> wrote:
I don't know what these multipliers are in reference to. "Decoding GIF took x% CPU and decoding WebP took 1.5 * x%"?
On Tue, Jul 2, 2013 at 4:50 AM, Pascal Massimino <sk...@google.com> wrote:
I don't know how to interpret this. "We could have made animated WebP a better format but we chose not to because we were afraid it would impact WebM adoption"? I don't understand what negative consequences could possibly come from making the format as good as possible. Especially if animated WebP sees significant use, we really, really, really want to avoid the current performance problems with animated GIFs, where even on a fast machine the load can become unbearable with just a few images.
|Re: [blink-dev] Intent to Ship: Animated WebP images||Alpha Lam||7/2/13 2:30 PM|
2013/7/2 Alex Russell <sligh...@google.com>
On mobile devices battery life in the most important in my opinion. Once the file is loaded it will keep looping. I think this will be an important angle for improvements for designing a new codec / container.
2013/7/2 Peter Kasting <pkas...@google.com>
I meant lossy WebP took 260% of decoding time of GIF. Lossless WebP took on average 150% decoding time of GIF.
There are use cases where lossless Animated WebP will be useful, e.g. transcoding GIF, encoding clip art, etc. It will increase the chance of success if we make this format strictly better than animated GIF in both features, perf and power usage. I have made suggestions how to make it web friendly.
I share the same fear as Pascal that animated WebP would impact WebM adoption. On top of that I fear that by introducing lossy animated WebP we're not promoting the best practice (i.e. WebM).
My concrete suggestions are:
1. We should improve the container format on Lossless Animated WebP to allow fast seeking and be more web friendly.
2. We should promote the best practice for encoding video content, i.e. WebM. There shouldn't be a lossy animated image format.
|Re: [blink-dev] Intent to Ship: Animated WebP images||Peter Kasting||7/2/13 2:35 PM|
On Tue, Jul 2, 2013 at 2:30 PM, Alpha (Hin-Chung) Lam <hc...@google.com> wrote:
I don't think we should be trying to force authors to do something we like by refusing to provide them good alternatives.
Either the arguments for why we need an animated image format at all when we have <video> make sense, or they don't. If they do we should make both lossy and lossless animated WebP as good as possible. If they don't we shouldn't bother with animated WebP at all.
As you can guess, I disagree quite strongly with this.
|Re: [blink-dev] Intent to Ship: Animated WebP images||Pascal Massimino||7/2/13 3:13 PM|
On Tue, Jul 2, 2013 at 10:09 AM, Peter Kasting <pkas...@google.com> wrote:
that, minus the 'adoption' part: there's a continuum of features <-> complexity, and if you keep making animated WebP 'better', you just end up with P-Frames and VP8 format (or equivalent).
Paraphrasing VP8 / WebM in form and intent, for instance.
That's also true with JPEG, e.g.: you can make the browser crawl to its knees with insane 64k x 64k JPEGs, e.g. All formats have their possibilities of mis-use.
|Re: [blink-dev] Intent to Ship: Animated WebP images||Peter Kasting||7/2/13 3:29 PM|
On Tue, Jul 2, 2013 at 3:13 PM, Pascal Massimino <sk...@google.com> wrote:
I don't think what I've suggested as an addition is very much diferent from what the format does now. It is certainly not going all the way to VP8. So I don't think this is a very good objection to my comment.
You are comparing apples with aircraft carriers. JPEGs of common size take minimal time to decode and display. 64k x 64k JPEGs are extremely rare. GIFs of common size take significant time to decode and display, such that they're one of the largest single problem sources we have w.r.t. overall renderer CPU load and responsiveness. Animated WebP in its current form may make this worse. This is a huge problem and it deserves attention.
You're beginning to make me feel like the people specifying WebP don't actually understand the nuts and bolts of graphics handling in Blink (or other engines, for that matter, since we want adoption by other browsers). That is not a good place to be.
|Re: [blink-dev] Intent to Ship: Animated WebP images||Pascal Massimino||7/2/13 4:05 PM|
On Tue, Jul 2, 2013 at 3:29 PM, Peter Kasting <pkas...@google.com> wrote:
So, what do you have in mind as 'more comprehensive and accurate keyframing' ? We have this project of adding an 'index' chunk that would provide cues to jumping at individual frames in the an animated webp file. But, can't renderer build such an index on-the-fly while decoding, too?
Yes, but it doesn't seem to be related to WebP in particular but rather to large anims in general and habits that have grown around GIF usage.
Animated WebP's purpose is not to fix GIF (<video> can do that), and overly large anims are just a mis-use of both formats capabilities.
Actually, the other important use case foreseen for 'animated' WebP is rather having a collection of images into a single file, that does not
necessarily form an 'animation'. That'd be useful for spriting or comics, say. But that's another discussion i guess.
Well, it seems to me that animation handling part was being re-written simultaneously, so yes it's correct i'm not familiar with the new way of handling animations
(but Urvang is).
|Re: [blink-dev] Intent to Ship: Animated WebP images||Peter Kasting||7/2/13 4:25 PM|
On Tue, Jul 2, 2013 at 4:05 PM, Pascal Massimino <sk...@google.com> wrote:
You simply specify, with each frame, which pieces of which previous frames must first be decoded before the current frame can be layered on top.
The current decoder uses disposal methods to determine a conservative estimation for this, but it's not terribly accurate or time-saving when we have the (common) case of new frames that only modify small portions of previous frames. And while we could attempt to enhance the decoder by more careful checking of per-pixel alpha and the like, at best we would only be able to build this accurate data structure after decoding all frames once -- which means we still have a long, CPU-intensive decode period before we can begin skipping frames (which often delays the start of actual animation by a long time).
Proclaiming that will not cause people on the web to change their habits. You are repeating the problems of XHTML by ignoring the stupid ways real people use things and trying to instead get everyone to change to a better, but not backwards-compatible, way.
If you're not trying to fix GIF, I am opposed to shipping animated WebP at all. Since you're going to be trying to convince the entire world to change direction anyway, you should convince them all to switch to <video> and be done with it.
What I'm saying is, I don't think either of you deeply understand the problems that animated GIF has and how they play out in the wild. But you seem to be trying to convince me that it's not that you don't understand, but that you simply don't care, because you're not trying to fix animated GIFs in the first place. This is a stance I find mind-boggling.
|Re: [blink-dev] Intent to Ship: Animated WebP images||Alex Russell||7/2/13 9:05 PM|
...assuming it is in view, etc.
It's safe to say that appealing to battery life concerns doesn't let you off the hook for network size: radios take power and data often costs money.
|Re: [blink-dev] Intent to Ship: Animated WebP images||Pascal Massimino||7/3/13 8:30 AM|
On Tue, Jul 2, 2013 at 4:25 PM, Peter Kasting <pkas...@google.com> wrote:
this is a reasonable trade-off for (cheaply) gaining compression efficiency. Short of that, files would be terribly large. And anything more complex goes down the video frame-prediction way, with motion vectors and such.
You'd have exactly the same problem with video files... if reasonable encoders didn't insert I-frames regularly to allow random jumps into the stream.
You can even have evil video files without any i-frames at all, only p-frames with lot of intra blocks.
WebP is not trying to fix GIF (it's trying to make the web faster). GIF could be already fixed by itself if gif encoders were to regularly insert Dispose=Background frames for long anim (so we could easily seek into the files), like any regular video codec do by default.
They don't, and that's a pitfall that animated WebP encoder can avoid falling into. What would you do to fix GIF?
It's still my opinion there's room for Animated WebP between GIF and <video>, for short-and-better-compressed animated files. It offers somewhat higher compression (i can shave off 20% of tumblr/ gif pages, that's something), ARGB colorspace (and not just YUV420 like <video>), better alpha handling compared to GIF, and reasonable decoding (and transcoding) time.
|Re: [blink-dev] Intent to Ship: Animated WebP images||Tom Wiltzius||7/3/13 5:44 PM|
On Wed, Jul 3, 2013 at 8:30 AM, Pascal Massimino <sk...@google.com> wrote:
It's clear that there are some great advantages to animated WebP over GIFs, as you list above. My concern is that shaving 20% off network load time of tumblr/ gif pages is great, but if that compression comes at the expense of rendering performance (as Alpha's numbers from earlier in this thread indicate) for one of our worst-case scenarios (i.e. animated GIFs), we're going to saddle everyone with an overall worse experience on the web. Pages that are covered in animated GIFs have terrible scrolling performance and burn a lot of CPU / battery time decoding.
My hope would be that in introducing a new format, we can make sure we don't end up in the same bad place we're in for GIFs in this particular regard. It sounds like there's no hope of that. Do you think we can at least get to the point where WebP decoding times are competitive with animated GIFs, rather than worse?
|Re: [blink-dev] Intent to Ship: Animated WebP images||Peter Kasting||7/8/13 1:18 PM|
On Wed, Jul 3, 2013 at 8:30 AM, Pascal Massimino <sk...@google.com> wrote:
I think I have a pretty concrete suggestion that does not involve motion vectors and does not make file sizes terribly large. It seems like you're objecting in principle to a class of suggestions that I'm not making. I'm being specific on purpose here, so there shouldn't be any reason to argue against a strawman.
I don't know what criteria you use to measure "make the web faster", but network bandwidth cannot be the only relevant issue. GIFs cause huge, obvious performance problems today for many users even with fast machines. WebP is set to worsen this rather than improve it. That's making the web slower in an important way even if it makes it faster in another.
I think that suggestion is complementary with mine. (I'm also not sure offhand when in the GIF bitstream we know we have the authoritative disposal method for a frame.)
I already said (repeatedly): provide with each frame the frame numbers of the minimal set of previous frames required to decode the current frame.
|Re: [blink-dev] Intent to Ship: Animated WebP images||Alpha Lam||7/9/13 3:39 PM|
I uploaded the data set here: https://drive.google.com/a/google.com/uc?id=0B4fjqgfYdd-id3JWOEMyd2hBanM&export=download
It contains 7k GIFs crawled from google image search. Corresponding converted WebP and WebM files. It's a big file.
|Re: [blink-dev] Intent to Ship: Animated WebP images||Tab Atkins Jr.||7/12/13 9:55 AM|
On Mon, Jul 1, 2013 at 8:36 PM, Alpha (Hin-Chung) Lam <hc...@google.com> wrote:
> Just to emphasize my worry about this use case. Please look around tumblr
> and almost all animated GIFs are from some kind of video clips. Using a true
> video codec compresses a lot better than an image codec.
Sorry for the delay in responding to this thread, but this touches on
something potentially important.
WebM, being a lossy, highly-tuned video codec, is better for encoding
video, which happens to match the major animated-GIF use-case well.
But people like the ease and general acceptableness of images (that
is, lots of sites that allow file uploads will take images, but not
There's perhaps a middle-ground here - can we treat WebM as an
"image", for the purpose of HTML's <img> element? We could even
optimize the display, perhaps adopting something like what Vine does -
videos start automatically, muted and auto-looping, and show no
controls except for an "unmute" button. This would make the use of
video-in-<img> less enticing for real video (longer than a few
seconds), but would fit the animated-GIF use-case perfectly, and even
allow (optional) sound to go along with them.
|Re: [blink-dev] Intent to Ship: Animated WebP images||Tom Wiltzius||7/12/13 11:33 AM|
I think this was proposed earlier in the thread too, indirectly, in the notion of using the webm playback pipeline behind the scenes for images. It seems pretty reasonable.
|Re: [blink-dev] Intent to Ship: Animated WebP images||new...@gmail.com||7/12/13 1:02 PM|
That's the key. The times when web-developers were creators of graphics/animation content, are gone. Those days web-developers make a platform for users to upload their graphics/animations. Sometimes we see amusing/interactive animations on the Google front page, but regular users don't do that. Simply because regular users can't upload such stuff on imgur or tumblr, or whatever their favorite place is.
So, in many places, animated GIFs is still the only way for users to upload and post their animations. It's not because they love GIFs, it's because there is no other way. The users would love to find a loophole, but on major websites all loopholes in "uploading arbitrary files" are already closed.
|Re: [blink-dev] Intent to Ship: Animated WebP images||Eric Seidel||7/16/13 3:26 PM|
On Mon, Jul 1, 2013 at 1:15 PM, Alpha (Hin-Chung) Lam <hc...@google.com> wrote:
> That's right. The format is deeply inspired by GIF and does not allow
> specifying a frame explicitly as a key frame (not needing anything before to
> decode that frame). This feature is critical to to Web because an image
> should be paused when it's outside of the viewport, discarded in memory and
> then when it's scrolled into view resume from an arbitrary frame. Without
> this feature we'll have to cache multiple frames which is not desirable. On
> mobile most likely the cache will be evicted. Decoding it on impl thread can
> help but it's still a heavy workload.
I don't believe we pause any GIFs outside the viewport, do we?
I don't see the gifs pause when I scroll or switch to other tabs, etc.
|Re: [blink-dev] Intent to Ship: Animated WebP images||Peter Kasting||7/16/13 3:28 PM|
On Tue, Jul 16, 2013 at 3:26 PM, Eric Seidel <ese...@chromium.org> wrote:
When the GIF is made visible again, we "spin it forward" to the point its animation should have been at if it had continued animating while offscreen.
|Re: [blink-dev] Intent to Ship: Animated WebP images||Darin Fisher||7/16/13 4:43 PM|
It seems that a number of concerns have been raised on this thread. It's not clear that we are ready to ship Animated WebP.
For instance, it seems that Animated WebP is trying to be an improvement over Animated GIF, but based on Alpha's findings, the results are not great. Transport size is marginally reduced at the cost of much greater CPU / power usage. That seems like a questionable trade-off.
The proposal of <img src="foo.webm"> is intriguing. I'm keen on seeing the idea explored further.
At any rate, the recommendation of the Blink API Owners is to work on resolving some of these issues with the goal of building more consensus. (Personally, I'm a big fan of finding some way to improve on Animated GIFs, so I wish you success.)
|Re: [blink-dev] Intent to Ship: Animated WebP images||Urvang Joshi||7/16/13 4:50 PM|
Hi Darin, others,
I've discussed some of the concerns raised here offline with Alpha.
Pascal and I feel that many of the concerns are addressable. But, as it seemed hard to discuss these concerns over email, we are meeting Alpha and Peter Kasting to resolve the same.
I'll update the thread about the conclusions.
|Re: [blink-dev] Intent to Ship: Animated WebP images||Darin Fisher||7/16/13 4:52 PM|
Sounds great. Looking forward to an update.
|Re: Intent to Ship: Animated WebP images||nl||8/26/13 4:01 PM|
Hi... first, I apologize for butting in on this discussion between experts but I thought maybe you might benefit from an outsider's point of view. As someone with an interest in this field I've constructed what I hope to be some well-reasoned and practical arguments in favor of animated webp being implemented, and I hope you'll be willing to read them. I understand you're busy people and your time's valuable so I'm sorry about how long the post is but to get my points across effectively I needed to be a bit verbose.
My main job is in web development and I also work on PC games as a hobby in my spare time. Whether I'm designing a game or a website, I find it's rarely beneficial to work with my current PC (or mobile device) in mind as the target, or even today's mainstream PC; I need to consider what will be mainstream at the time when people will hopefully be viewing my websites or playing my games. Likewise, I think you need to consider the amount of time it will take for animated webp to come into common use and what will have changed or stayed the same by that time.
It's true that low-power devices using a wifi connection may, in the short term, suffer some performance reduction when viewing pages with animated webp images. While this is an important use-case, such devices tend to be either low-end (where good performance is not expected) and likely using an OS that Chrome/Chromium can't run on (Android <4.0), or on the opposite side of the spectrum the device may be one that has relatively powerful internals because of the reduced costs associated with wifi-only devices and larger acceptable form factor. In the first case it doesn't matter if animated webp is too performance-intensive, and in the second case it likely won't be that much of an issue because the device is more capable.
A much more common and important scenario is a device using a mobile data network. Even in relatively well-serviced countries, people tend to spend much of their time in areas which have sub-optimal cellular reception: indoors, in crowded areas, or in areas with poor coverage. If you're loading a 5 MB web page in these conditions, each portion of that page will have ample time available to be decoded while the next chunk of usable data arrives. A significantly smaller filesize thanks to using animated webp instead of GIF will be a huge win and certainly result in a better user experience. The battery usage of a few extra seconds of work for the CPU can often be greatly outweighed by the battery usage of a phone's radio being active.
If you're in an area with a very fast connection such as LTE, transferring large files is less of a concern. Devices using LTE often have better battery life than devices using HSPA simply by virtue of the radio being able to go into a low-power state much sooner, in spite of LTE using much more power for the time it's active. However, if you consider that GIFs are frequently a megabyte in size if not more, and that very often pages will have either no GIFs at all or tons of GIFs, I'd still argue that the increased CPU power usage would be comparable to the reduced modem power usage.
Even if the performance hit is 300%, animated webp won't have any performance impact on desktop PCs. Mobile CPUs are quickly becoming more power-efficient, adding more cores, and improving performance per core. On the other hand, websites are following a similar curve in their increased functionality and complexity, and CPU performance doesn't scale linearly with core count and frequency. Page rendering speed is obviously still improving at a rapid pace on mobile devices though. While it's foolish to assume that everyone will have a high-end device that benefits from the latest SoC improvements, these improvements are rapidly filtering down into mainstream and low-end devices. By the time animated webp becomes common, today's processors could easily be considered too slow for a low-end phone.
PNG is still not used in place of GIF in many places where it would be more appropriate; webp is still not used in place of JPG where it would be more appropriate; archaic codecs like h.263 (xvid) are often used where h.264 (AVC) or VP8 would be more appropriate; it won't be long before VP9 arrives and despite its promised improvements it won't be adopted very quickly either. Bearing in mind the extremely slow pace of adoption that new standards have, the mere availability of animated webp (on just one browser at that) isn't going to suddenly make everyone switch to it and have the web grind to a halt on devices that don't handle the format well. When it's available in Chromium/Chrome, it likely won't be adopted by Firefox and Opera for another year, and Internet Explorer might easily take much longer. Game consoles and other standalone devices probably won't support it for 5 years or more, and any <4.0 Android device will almost certainly never support it.
Image formats can remain in common use for decades even as superior alternatives arrive; the GIF specification was finalized in 1987, JPG in 1992, PNG in 1996. Effectively killing (or just unnecessarily delaying) animated webp by not supporting it in the web browser of the company responsible for its existence, simply on the basis that some percentage of users may not have an ideal experience for the first few years it's available, seems overly conservative. I do understand that this is a discussion about Chromium, not Chrome, but I have to imagine that some of the people here also have an interest in the most visible Chromium project succeed, especially when the project in question is intended to replace a badly outdated and inefficient format which has greatly outlived its usefulness.
Chromium supports many other standards which can have usability issues on a large percentage of devices. A couple examples are WebGL and SVG, both of which are very slow and demanding to display even on many desktop PCs. Chrome for Android can also be very flaky on websites with native touch-based interfaces. Despite these weaknesses, you put the responsibility for deciding if and when it's appropriate to use these standards on web developers, which was the right thing to do. A web browser is designed to facilitate the correct display of a web developer's vision, not to hold back relevant and useful technologies until every device on the market is optimized for them. Web developers routinely design different versions of websites and different assets for different targets; we're capable of using new technologies responsibly, in this case by only using webp on certain platforms while displaying an equivalent GIF on ones where there's likely to be a performance concern.
Data caps are probably one of the biggest constraining factors in the use of mobile services. Less data usage for animated images means more use of the internet in general, which is good for anyone working in this industry. If animated webp catches on, awareness of the advantages of static webp will also begin to grow rapidly. If major image hosts realize the bandwidth savings of millions of GIFs being significantly reduced in size, they will adopt it and drive mainstream support, just like how Firefox wasn't going to implement webp support but changed their mind when some major sites began using it.
GIF needs to be retired, everyone in this field knows it and we've known it for many years. If webp doesn't become the new standard, something else will inevitably come along. What will it be? Will the other standard be as efficient? Royalty-free in commercial use? Maybe it'll be based on HEVC, which means it'll be the h.264 mess all over again if MPEG-LA decides everyone using it commercially owes them a nickel.
|Re: Intent to Ship: Animated WebP images||new...@gmail.com||8/27/13 12:38 AM|
As I understand, animated WebP code is already implemented in Chromium, it's just hidden behind a runtime flag.
You just need to enable this flag and then restart browser:
Animated WebP works for me after that.
That way you might already experiment with the format, its implementation performance etc.
Developers would appreciate a feedback, no doubt.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Darin Fisher||9/16/13 12:44 PM|
This sounds great. One question below:
On Fri, Sep 13, 2013 at 3:59 PM, Urvang Joshi <urv...@google.com> wrote:
On what kind of system did you perform this performance comparison? How does CPU utilization (power consumption) compare between WebP and GIF?
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Peter Kasting||9/16/13 1:20 PM|
FWIW, after the changes to the WebP encoder, decoder, and GIF transcoder, I support the inclusion of animated WebP in Blink.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Urvang Joshi||9/16/13 2:06 PM|
On Mon, Sep 16, 2013 at 12:44 PM, Darin Fisher <da...@chromium.org> wrote:
I ran this decoder benchmark (https://codereview.chromium.org/23532077/) on a set of about 7k images (image set provided by Alpha). The benchmark was run on my Linux machine.
And, the benchmark tool is single-threaded, and AFAIK the decoders run single-threaded, too. So, the decode times should be correlated to the CPU utilization.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Darin Fisher||9/16/13 3:59 PM|
Is it possible for you to repeat the performance test on an Android device? I think it would help to understand the performance characteristics on mobile.
|unk...@googlegroups.com||9/16/13 4:28 PM||<This message has been deleted.>|
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||James Robinson||9/16/13 4:38 PM|
On Mon, Sep 16, 2013 at 4:28 PM, Urvang Joshi <urv...@google.com> wrote:
Chrome on Android most certainly does support animated GIF and always has.
|Re: [blink-dev] Intent to Ship: Animated WebP images||Adam Barth||9/16/13 4:39 PM|
I just went to the top link on reddit on my phone and animated GIFs do appear to be supported. :-)
> On Mon, Sep 16, 2013 at 3:59 PM, Darin Fisher <da...@chromium.org> wrote:
> On Mon, Sep 16, 2013 at 12:44 PM, Darin Fisher <da...@chromium.org> wrote:
> Android doesn't support animated images as yet (be it GIF or WebP). So, that's not a concern right now.
|Re: [blink-dev] Intent to Ship: Animated WebP images||Urvang Joshi||9/16/13 4:41 PM|
On Mon, Sep 16, 2013 at 4:39 PM, Adam Barth <aba...@chromium.org> wrote:
Yes, my bad.
I confused it with the fact that native android apps don't support animated GIFs
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Urvang Joshi||9/16/13 4:56 PM|
Let me find out if it's feasible to run the tests on Android.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||PhistucK||9/16/13 11:21 PM|
However, there are optimizations that benefit multiple thread and multiple core machines as well - right?
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Urvang Joshi||9/16/13 11:26 PM|
On Mon, Sep 16, 2013 at 11:21 PM, PhistucK <phis...@gmail.com> wrote:
Yes, libwebp does have multithreaded decoding support, too.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Darin Fisher||9/16/13 11:32 PM|
When you observed WebP being faster than GIF, was WebP benefiting from using many threads in parallel? If so, I'm even more curious what the results look like on more constrained systems (mobile hardware).
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Urvang Joshi||9/16/13 11:37 PM|
On Mon, Sep 16, 2013 at 11:32 PM, Darin Fisher <da...@chromium.org> wrote:
As mentioned, WebP can potentially use multiple threads to decode. But the decode benchmark used only a single thread.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Darin Fisher||9/16/13 11:40 PM|
OK, that's very helpful. Thanks! Sorry, I'm just trying to understand how to interpret the data.
|Re: Intent to Ship: Animated WebP images||Kornel||9/17/13 2:18 AM|
I'm disappointed that animated WebP even exists. To me it looks like sneaking video into image format to work around vestigial divide in browsers between places where efficient video codecs are allowed and where only inefficient video codecs are allowed (<video> vs <img>).
It is absurd that WebM-based picture format is re-invented as an inferior video format that is going to get better support in Chrome than WebM. Please, just fix WebM to work "just work" without ceremony in <img> and when linked to directly.
I've ranted more about this here: http://pornel.net/beat-gif-manifesto
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Jake Archibald||9/17/13 9:49 AM|
I very much agree with Kornel. Animated WebP feels like Street Fighter: The Movie: The Game http://en.wikipedia.org/wiki/Street_Fighter:_The_Movie_(arcade_game)
Looking at http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#the-img-element, we could allow any of our supported video formats to be image sources. The rest is a UX question. Kornel's suggestion of auto playing muted without any controls sounds about right.
What's stopping us doing this rather than introducing a less-efficient format to do the same thing?
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Ojan Vafai||9/17/13 10:39 AM|
If you're taking the time to do more testing, do you think you could add testing webm performance to your tests? Even if animated webp is much better than animated gif, there's still the question of whether it'd be better to just ship webm-in-img.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Eric Seidel||9/17/13 10:56 AM|
<video> and <img> are very different implementations in the code.
Rendering video content in <img> could be quite a bit of work. But
that's not to say we shouldn't do it.
I don't really understand why we don't support video formats in <img>
other than the implementation challenge. The auto-play/no-sound video
in an <img> seems the moral equivalent of an animated gif, and as
kornel states is likely to perform better from a data-compression
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Alpha Lam||9/17/13 11:28 AM|
This point has been raised several times and I strongly support having WebM playable in <img>. This gives much better compression than lossy Animated WebP. WebM has interframe prediction that is much better suited for video content. Performance wise it's not much different than lossy animated WebP depending on encoding options. Having said that, animated WebP has a lossless mode which gives better picture quality than WebM and lossy WebP. It is also simpler to decode. I think choice is good and we can offer good alternatives: 1) WebM for better compression ratio 2) Animated WebP for simplicity and lossless support.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Stephen Konig||9/17/13 11:41 AM|
I think we need to be careful to not view this as the way we wish things worked vs. the way they actually do. Specifically one of the challenges with video is around creation: video editing tools are generally more complex and require more work on the part of the user, while simple tools to create animated GIFs are everywhere and far easier to work with (especially if all you really want is a moving avatar or meme).
If we could turn back the clock I think we'd have a great argument for why animated images are a bad idea and shouldn't be supported, but we are where we are. If we don't supported animated WebP I suspect animated GIFs will continue to flourish and the percentage of people who use WebM video instead of animated GIFs will be miniscule. As a practical matter I fear it's not a reasonable alternative.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Stephen Konig||9/17/13 11:42 AM|
Though to be clear, I think supporting WebM video in addition to animated WebP is worth considering.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Peter Kasting||9/17/13 11:50 AM|
On Tue, Sep 17, 2013 at 11:42 AM, Stephen Konig <sko...@chromium.org> wrote:
Right, and as Alpha noted, that's been suggested many times, and many of us have made approving noises each time. I've never heard anyone disagree with the suggestion that we at least investigate this possibility.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Jake Archibald||9/17/13 11:47 AM|
I'm not convinced that's true. There are a load of tools now to take video and convert it to gif. We need to work out why that's happening and fix it.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Kornel Lesiński||9/17/13 1:27 PM|
On Tue, 17 Sep 2013 19:42:05 +0100, Max Stepin <new...@gmail.com> wrote:> OK, consider this example: http://imgur.com/M9Lr4s5
> It only looks good on white background, because of GIF alpha limitations.
> What would you replace it with?
WebM is adding support for alpha and I applaud that:
Ideally that's what I'd use.
> Maybe APNG, maybe Animated WebP, something with proper alpha channel,
As much as I love PNG, I think APNG is the same kind of mistake as
animated WebP. You don't need to reinvent technically inferior codec in
order to support small resolutions or alpha channel.
If WebM (with alpha) worked in all places where GIFs work, and had UI as
good as GIF, would you ever think you need animated WebP?
> But probably not video. Converting such tiny GIF into video doesn't make
What are the criteria for making sense here?
* Does it have to be limited to a palette? Would Cinepak make sense for it?
* Does it have to lack inter-frames? Would MJPEG be OK?
* Does it have to be so computationally cheap that 1990's CPUs can decode
it? Would Intel Indeo make sense?
We've been stuck in this mindset that small animations don't deserve a
"proper" codec. We've learned to think that GIF is lightweight and
effortless to use, and other codecs are heavyweight and shouldn't be used
for animations that GIF can.
But I think that's just a result of trauma of living with QuickTime and
WindowsMedia plug-ins for years that made "proper" video codecs seem hard
to use and not worth bothering for small animations.
But we don't rely on crappy plug-ins anymore. Now we can have *any* native
codec as privileged and effortless to use as GIF.
To me APNG and Animated WebP are a bad case of "faster horse" thinking.
They're like trying to replace GIF-horse with a gasoline-powered
mecha-horse. Just use the car you have!
People use GIF, because (apart from fantastic compatibility that no format
younger than 15 years can match) it's the only video codec that works in
<img>, and it's the only video codec that is autoplayed and looped so
easily in all browsers.
But: you don't need to make WebM technically worse in order to give it
less fussy UX.
**You can already integrate WebM in Chrome _so well_ that people will
think it's GIF.**
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||addyo...@gmail.com||9/17/13 2:27 PM|
I work with both video and GIF on a daily basis and I have to strongly disagree. Tooling has come a long way here in recent years and the tools available for editing video and GIF are significantly more straight-forward to use than they once were. If these same tools supported WebM video encoding (with alpha) I'd gladly drop GIFs in a heartbeat.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Jake Archibald||9/17/13 12:14 PM|
I like the idea of <img src="video">, but does it actually solve the problem?
People are going out of their way to transcode video to horrible-looking heavy gifs. Why? My finger-in-the-air guess is:
Does that sound about right, any other reasons?
It seems like the sticking point is the upload services. If autoplay is an issue, it's probably easier to persuade Apple to allow <video> to autoplay than get them to implement <img src="video">.
On Tue, Sep 17, 2013 at 11:28 AM, Alpha (Hin-Chung) Lam <hc...@google.com> wrote:
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Kornel Lesiński||9/17/13 3:35 PM|
On Tue, 17 Sep 2013 22:07:56 +0100, Max Stepin <new...@gmail.com> wrote:> I just know that for such tiny 32x22 animation instantiating a full video
> codec is overkill.
> Significant memory and cpu resources are needed to just start a video
Has that been measured (compared to anim WebP) or is it just a gut feeling?
> Now imagine twenty such smiles on one webpage (very common case), with
> twenty instances of video codecs running simultaneously...
I can easily imagine 20 instances. I can imagine 2000 instances on my
Nexus 4. This entire emoticon video, uncompressed, in RGBA, takes 40KB of
It's not 20 instances of QuickTime Player plug-in :)
The WebM decoder requires bunch of buffers for decoding, animation,
colorspace conversions, just like animated WebP, plus and extra buffers
for reference frames, but at anim-GIF sizes it's all pretty small. Is
there some massive constant and impossible to avoid overhead in WebM, but
not in a-WebP, that I'm missing?
Maybe CPU usage would be a problem? Unfortunately, Animated WebP is not
substantially cheaper to decode than WebM (AFAIK it's not any cheaper at
all than WebM with all i-frames). WebP has block prediction, in-loop
deblocking, entropy coding, and needs colorspace conversion. All those
things are far in the "full video codec" territory compared to GIF copying
pixels from 4K LZW LUT.
And yet it all still shouldn't be a big deal for today's computers and
even smartphones, and will be laughably cheap in 5-10 years time before
any format reaches level of support GIF enjoys. It doesn't make sense to
make long-term bets against Moore's law.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Urvang Joshi||9/19/13 2:59 PM|
To test performance on a mobile device, I ran the benchmark tool on a Nexus 7; and the comparative numbers were similar: Decoding speed is between 0.8x and 0.9x compared to GIF.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Peter Kasting||9/19/13 3:01 PM|
On Thu, Sep 19, 2013 at 2:59 PM, Urvang Joshi <urv...@google.com> wrote:
Decode _speed_ (higher is better) or _time_ (lower is better)?
Decoding with seeking or without?
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Urvang Joshi||9/19/13 3:04 PM|
Sorry, I should have been clearer. This is "Decode time with seeking" just like the Desktop numbers. So, lower is better.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Peter Kasting||9/19/13 3:09 PM|
On Thu, Sep 19, 2013 at 3:04 PM, Urvang Joshi <urv...@google.com> wrote:
For clarity, straight-line decoding without seeking is still slower than GIF on both mobile and desktop, right? Can you give the ratios for that?
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Urvang Joshi||9/19/13 4:41 PM|
Yes, the decoding without seeking is slower compared to GIF. Lossless WebP takes 1.8x time while lossy WebP takes 2.9x time compared to GIF.
To put this in perspective: GIF decodes about 2162 frames/second, Lossless WebP decodes 1200 frames/second, and lossy WebP decodes 745 frames/second. [Compare this to the delay between successive animated frames, which is typically 100ms].
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Peter Kasting||9/19/13 5:04 PM|
On Thu, Sep 19, 2013 at 4:41 PM, Urvang Joshi <urv...@google.com> wrote:
Are those ratios expected to change significantly in the future? To put this another way, how much low-hanging fruit is there in the WebP decode loop?
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Urvang Joshi||9/19/13 6:03 PM|
Not many low-hanging fruits in the core decode loop. But, I do have an idea to improve gif2webp tool for lossy images that has good potential.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Peter Kasting||9/19/13 6:08 PM|
On Thu, Sep 19, 2013 at 6:03 PM, Urvang Joshi <urv...@google.com> wrote:
I'm mainly worrying about people with several visible animated WebPs at once. If they just stare at the page, we won't seek, and thus we'll be eating even more CPU than with GIF.
It might be nice to investigate the idea (I've heard a few times) to have Blink decode internally to some intermediate form, more compact than the 32bpp FrameBuffer of today, but easier to decode than the original compressed data. Such a form could be very useful for looping GIFs _and_ WebPs, because we could use it to raise the current clamp on saving decoded data, thus putting more images into the "doesn't cost a ton of CPU continuously" category.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Urvang Joshi||9/20/13 3:09 PM|
On Thu, Sep 19, 2013 at 6:08 PM, Peter Kasting <pkas...@google.com> wrote:
Let's think about the overall impact in the worst case scenario: there are 10 animated images (with average 15 frames per image) visible at a time, and user stares at it until images cycle 5 times.
Overall savings for WebP lossy: 4.23 seconds.
Overall savings for WebP lossless: 1.52 seconds.
Sure, this would be a nice to have for GIF as well as WebP.
At the same time, one would have to think about (i) What that internal format would be (ii) how much time it takes to decode original image, encode into the internal format and repeatedly decode from this internal format; and would this process result in overall savings.
Probably warrants a separate discussion.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Peter Kasting||9/20/13 3:50 PM|
On Fri, Sep 20, 2013 at 3:09 PM, Urvang Joshi <urv...@google.com> wrote:
The only problem I have with this is that the numbers don't match what we can often see on real web pages. In the wild, it's frequently true that pages with lots of GIFs have very large (= high frame count) GIFs, and the decoding machine is either much slower or much more heavily contended than whatever you used to get the 2k FPS decode speed estimate. (Classically, we've had pages where just one animated GIF can burn 50% CPU in perpetuity, which, even assuming the GIF runs at 60 FPS, would mean the CPU is only capable of ~120 FPS.) So I worry about scenarios where either the CPU is much slower or the GIFs are much more demanding than the estimates you have here.
It would of course be much better if I could point you at precise data collected about machine speed, slow URLs, etc. to make what I'm saying concrete. I realize I'm waving my hands. But I hope others can attest that GIF CPU cost has been a big deal in the past, and while I am extremely pleased that we can make the decode-with-seeking case so much better with WebP, it'd be even more awesome if we could _also_ make straight-line decoding faster.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Darin Fisher||9/20/13 4:05 PM|
I think the case for animated WebP would be much stronger if relative to GIF there wasn't a CPU / power usage cost. I recognize that animated WebP can be delivered to clients faster than corresponding GIFs, which is great, but it seems quite unfortunate that CPU / power usage is so much higher.
Presumably WebM is also more costly than GIF to decode? I'm curious if <img src=foo.webm> has better CPU characteristics than <img src=foo.webp>.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Peter Kasting||9/20/13 4:15 PM|
On Fri, Sep 20, 2013 at 4:05 PM, Darin Fisher <da...@chromium.org> wrote:
I do want to re-emphasize here that the overall decode time in the "with seeking" case is noticeably _lower_ than GIF. This is the case that causes the most visible problems on the web, which fall into two buckets:
(1) The CPU is overloaded, and we fall into a negative feedback loop where we don't have time to fully decode most frames, which makes us try to spin animations forward, which can require decoding more frames, which makes the problem worse. WebP will be more resistant to this effect.
(2) We haven't been looking at an animation for some time and then it becomes visible again (due to tab switching, scrolling, DOM changes, whatever), and there's a noticeable hang as we spike the CPU to 100% to spin the animation forward to account for the time gap. WebP will have fewer, less severe such pauses.
These are significant benefits, and are why I gave my endorsement to animated WebP.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Darin Fisher||9/20/13 10:06 PM|
Those are great points. Thanks for clarifying!
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Mike Lawther||9/22/13 11:30 PM|
On 21 September 2013 08:50, Peter Kasting <pkas...@google.com> wrote:
We could consider putting a UseCounter into Blink to measure things such as number of concurrent GIFs, GIF size, GIF framerate, amount of time spent decoding/seeking etc.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Alpha Lam||9/22/13 11:53 PM|
2013/9/20 Darin Fisher <da...@chromium.org>
Peter has answered this question.
WebM is a superset of Animated WebP and is at least as complex as Animated WebP to decode.
Straight playback without seeking is more complex to decode. Playback with seeking (fast forward due to scrolling, tab visibility change) is about the same. The advantage is better compression ratio and smaller file size for the same quality. WebM can be at least half the size of the same file in Animated WebP.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Ojan Vafai||9/23/13 5:04 PM|
On Sun, Sep 22, 2013 at 11:53 PM, Alpha (Hin-Chung) Lam <hc...@google.com> wrote:
To be clear, has your positioned changed to supporting shipping animated WebP?
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Peter Kasting||9/23/13 5:11 PM|
On Mon, Sep 23, 2013 at 5:04 PM, Ojan Vafai <oj...@chromium.org> wrote:
From his mail of Sept. 16:
"With the improved spec and implementation I think animated WebP is a lot more compelling. I will be happy to see it supported in Chrome and other browsers."
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Ojan Vafai||9/23/13 6:45 PM|
I don't have that in my thread history.
In either case, if Peter and Alpha both support shipping animated webp (as opposed to only shipping webm in img), then I'm sold.
LGTM to ship.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Alpha Lam||9/24/13 1:21 PM|
Yes. I support shipping Animated WebP. And thanks Urvang for making those changes in spec and implementation. Somehow my reply email dropped blink-dev@.
2013/9/23 Peter Kasting <pkas...@google.com>
|Re: [blink-dev] Intent to Ship: Animated WebP images||Darin Fisher||10/21/13 4:54 PM|
To update this thread, after going over all of the issues, we (the Blink API Owners) have decided that it makes sense to proceed with shipping Animated WebP. The reasoning behind the decision is captured by this section of the WebP FAQ: https://developers.google.com/speed/webp/faq#why_should_i_use_animated_webp
Thanks to everyone, especially Urvang, for seeing this through!
On Tue, Jul 16, 2013 at 4:43 PM, Darin Fisher <da...@chromium.org> wrote:
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Eric Seidel||10/21/13 5:06 PM|
I prepared a response before Darin sent his, so I figured I might as well send it in case it provides more insight into at least one API Owner's thinking:
I'm sorry that WebP has had such a difficult time with the Intent-To-Ship process, but hopefully we've all learned a lot through this process.
There has been some further off-list discussion, resulting in the FAQ Darin mentioned.
My personal opinion is that <img src=video> will eventually win the day, but that day is a long ways away. As its' been pointed out in this thread (and on the FAQ) Chromium's stack is currently optimized for the single-video-on-page case and is no-where-near optimized for sites with lots of videos (like we have today with lots of animated GIFs).
Additionally, I (personally) believe that the much larger decision for Chrome (and all Browser vendors in turn) is one of if it's worth including libwebp (and thus supporting WebP as an image format). The real test for WebP will be if other browsers choose to adopt it -- if they do, I don't think they'll care whether they need to write 5 extra lines of code to wire up animation too.
I also think that if WebP allows popular sites (e.g. FaceBook ) and proxy-services (like ) to save gobs of bandwidth and user's phone battery life (due to more efficient network encoding and client-side decoding ) then WebP will be a win, even if the general web never chooses to use WebP.
So with that said, I support shipping WebP: LGTM.
2. http://news.cnet.com/8301-1023_3-57580664-93/facebook-tries-googles-webp-image-format-users-squawk/ (obviously reviews are mixed!)
4. Note that although https://developers.google.com/speed/webp/faq#why_should_i_use_animated_webp mentions that WebP takes more CPU time in straight-line decoding, Blink's image decoders always do seek-based decoding. We seek to the frame we're supposed to draw just before we draw it. We also don't animate when tabs are in the background (and catch-up when the come foreground again). I expect that the seeking case is actually the more common case and that WebP may be a battery-life win, but I could be wrong.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Noel Gordon||10/22/13 4:59 PM|
The color correction of animated images seems wrong per the webp spec. Could we either fix the spec, or disable color correction for animated webp at this time, or fix the implementation to conform to the spec before shipping?
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||PhistucK||10/22/13 11:45 PM|
Regarding note 4 -
Note that I am not familiar with the differences between seek based and straight line decoding and I could not find any information with a quick search.
You write the Blink always uses seek based decoding. So if a page includes an animated WebP and it is always visible and the tab is always active during the animation time - it still uses the seek based decoding?
And in that case (which seems like the common case) - is it better than straight line decoding?
Perhaps I am simply misunderstanding the terms and theories and confusing everything, so, please, forgive my ignorance here.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Eric Seidel||10/23/13 12:03 AM|
The code I'm referring to is here:
I admit to not being the world expert on that code, but thankfully Peter and Alpha can correct any misunderstandings I may have.
When it comes time to paint a bitmap image, we compute the desired frame index, possibly skipping frames in between. We then ask for that specific frame data (BitmapImage::frameAtIndex()) and its up to the underlying ImageDecoder as to what frames in between it may or may not decode, possibly seeking past skipped frames.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Peter Kasting||10/23/13 12:38 AM|
On Tue, Oct 22, 2013 at 11:45 PM, PhistucK <phis...@gmail.com> wrote:
Footnote 2 says: "Decode time with seeking" is computed as "Decode the first five frames, clear the frame buffer cache, decode the next five frames, and so forth".
Where did you read that? If that were true, Disadvantage 1 ("In the absence of seeking...") would not be a factor.
Seeking will happen in this case if the animation drops frames (hence Advantage 4's "Excessive CPU usage that results in animations dropping frames can also require the decoder to seek forward in the animation"). Otherwise, you'll be doing straight-line decoding.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||PhistucK||10/23/13 12:48 AM|
Eric wrote that in his footnotes -
So the CPU time advantages are only in cases of inactive tabs or otherwise invisible animated WebP images. The common case (I assume) is straight line decoding, in which animated WebP is worse than GIF. Thus the seek based advantages are uncommonly relevant.
I see no good reason to ship this yet (especially without any expressed support from at least another vendor), but who am I to decide.
I just hope we do not end up in the same situation like Firefox with APNG.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Peter Kasting||10/23/13 1:05 AM|
On Wed, Oct 23, 2013 at 12:48 AM, PhistucK <phis...@gmail.com> wrote:
Ah. I see. Eric's footnote and the WebP FAQ mean different things. He means that the code always does "seek-based" decoding (in terms of how it's architected), while the FAQ was only referring to decoding that actually involved seeking past undecoded frames. The more seeking (that is, skipping frames) you do, the more efficient WebP is compared to GIF.
Or dropping frames. Put all of those together and you have a good description of a LOT of pages that cause jank and stuttering via animated GIFs today. Those are precisely the cases that get better with animated WebP.
I don't know whether this is the common case. Regardless, it's not the case that causes bad user experiences.
The WebP FAQ lays out four major reasons animated WebP makes sense. You have discussed only one of them (and in a way that, I think, unfairly dismisses it).
Let's put this discussion in the proper context: Chrome has already shipped non-animated WebP. That was a different discussion, which happened in the past, and wasn't being revisited here. THIS discussion was only about whether to enable support for animated WebP as part of our existing, shipping WebP support. Talking about "not shipping this yet" or being the only shipping vendor are the sorts of comments that relate to the original decision to ship WebP at all; they aren't really applicable to this thread.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||PhistucK||10/23/13 1:39 AM|
Animated WebP is incompatible with WebP, which makes it a whole new format for the web and one that has no support from other browser vendors (much like the original WebP, but still in addition to WebP, since one does not have to activate the animated WebP support when implementing WebP).
No support for other vendors and more CPU time for regular decoding looks like deal breakers to me.
I understand that you think I am biased due to perhaps wrong assumptions. I have no argument 'against' that. ;)
I think the lack of multiple vendor support is my 'strongest' argument for not shipping this, anyway.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||new...@gmail.com||10/23/13 2:45 AM|
Recent additions of keyframes might help the performance, but they hurt the compression rates.
I experimented with recent gif2webp, and for longer GIFs, where converter adds a lot of keyframes, WebP often comes with even bigger size than original GIFs.
It's especially noticable on "cinemagraphs", where optimized GIFs take full advantage of very little frame-to-frame changes.
WebP takes advantage of that too, but inserting keyframes hurts that a lot, and WebP would often be bigger than original GIF.
It would be very hard to convince people to switch from GIF to WebP, unless you guys will think of another way to solve the performance issues, without adding keyframes.
|Re: [blink-dev] Intent to Ship: Animated WebP images||porn...@gmail.com||10/23/13 2:58 AM|
On Tuesday, 22 October 2013 00:54:43 UTC+1, Darin Fisher wrote:
FWIW I find these arguments completely unconvincing. In Chrome there are many marvels of engineering, but Animated WebP is not one of them.
I would expect that 24-years after GIF (especially when you use few times more CPU time to decode) you would create a format that always beats GIF by a wide margin, but it's not hard to find animations that WebP performs poorly on: http://littlesvr.ca/apng/gif_apng_webp1.html
It looks like lossless AWebP has serious disadvantage in low-motion animations and chroma-subsampling lossy WebP is unsuitable for cartoony animations — the exact cases that are typically thought of as being "animations" rather than proper "videos".
I suspect improvement over "random GIF from internet" you quote in the FAQ is mainly due to common usage of GIF as a way to "quote" fragments of H.264/WebM videos, but those are clearly cases where AWebP is redundant/obsolete/irrelevant, because any real video codec will perform much better, and GIF is used only for its universal compatibility that AWebP is unlikely to have anytime soon.
Speed advantage in presence of seeking is a contrived scenario that's less of an indicator of WebP's advantage, and more of deficiencies and lack of imagination in Chrome's implementation: by storing just one decoded frame from middle of a GIF animation you can halve cost of seeking in GIF and make GIF faster than AWebP in all scenarios (and please don't tell me it's cheaper for entire industry to adopt a new format for decades to come than for browsers to cache one frame in order of several KBs that's ridiculously cheap even on lowest-end phones produced today).
Similarly argument against using WebM instead of AWebP is contrived and partially specific to Blink's implementation deficiencies, rather than formats themselves. Animation presented is an extreme edge case, and 4 reference frames are not that expensive in cases AWebP is supposed to be used for. Remember that we're not talking here about dozen full HD videos (because AWebP's compression is to weak to be even used for that). When multiple animations are used on the page they're often things like animated emoticons or avatars, so 4 postage-stamp sized reference frames are ridiculously cheap. Last time it's been discussed example I was given as argument against WebM was animation that as a whole takes 40KB *uncompressed*. I'm all for fast browsers and lean memory usage, but ..40KB.. *are you kidding me?*
|Re: Intent to Ship: Animated WebP images||nawoa...@gmail.com||10/23/13 1:58 PM|
After reading through this discussion I'm beginning to wonder if WebP's >60% compression advantage over GIF is being measured as fairly as possible.
I'm familiar with JPG, GIF, h264, h263, PNG, and other compression schemes, and the same rule almost always applies: if you compress an image, then open it and compress it again using the same settings, you'll further "improve compression" but at the expense of loss of visual quality.
I think I understand your motivation for using GIF -> Animated WebP as a use case, because this is likely how a mobile Chrome proxy might best make use of the new format, but at what cost? And is WebP truly a superior format if the compression comparison is more fair?
I think that rather than "recompressing" GIF images into WebP, a large-scale comparison should be made where raw, uncompressed animations are converted to both GIF, WebP, and even APNG to see which truly offers the best size/performance/quality.
After all, if we're just going to talk about recompressing GIF images as you're doing with WebP in your comparisons (primarily for the sake of better mobile performance) then the same argument of improving performance and filesize could be made if you take the original GIF either optimize it better, reduce its color palette slightly, resize it while displaying it at the same size in the browser, or all of the above, and the loss of visual quality may be just as negligible as converting to WebP.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Peter Kasting||10/23/13 2:09 PM|
On Wed, Oct 23, 2013 at 1:39 AM, PhistucK <phis...@gmail.com> wrote:
We've been very clear in our discussions with all other partners who are considering implementing WebP support that the likely route here is that WebP includes animated WebP. And that is indeed the route that Chromium is now going. Part of the internal discussion on whether to ship this included the likelihood that someone supports WebP-but-not-animation. We consider this to be very unlikely. Animated WebP is part of WebP as of the current version of WebP and will be part of WebP as of shipping copies of Chrome. There is little advantage for other vendors in adding WebP support but avoiding animated WebP in this scenario.
Part of shipping any web feature is evaluating what the potential support is from other vendors and what the demand is from authors etc. I don't view the vendor situation as bleakly as you seem to. But even if I did, I don't think adding animated WebP to the WebP equation changes anything meaningful.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Peter Kasting||10/23/13 2:12 PM|
On Wed, Oct 23, 2013 at 2:45 AM, <new...@gmail.com> wrote:
Feel free to send us samples of cases that don't work well. I'm sure Urvang and the other WebP folks would like to take a look at them.
In our tests over thousands of GIFs, we didn't see the sort of size penalties you're referring to. I can't say offhand whether that's due to the GIFs in question, or because of some other factor. In any case, I would honestly be very surprised if we had a significant compression ration problem due to keyframes in general.
|Re: [blink-dev] Intent to Ship: Animated WebP images||Peter Kasting||10/23/13 2:24 PM|
On Wed, Oct 23, 2013 at 2:58 AM, <porn...@gmail.com> wrote:
This seems naive. All compression algorithms have cases where other algorithms can theoretically beat them. The issue is what the prevalence of such cases is.
I saw this a little while back, but I don't know what version of the tools they used, so I don't know how to evaluate this. I would not be surprised if a more recent toolchain encodes better. I defer these sorts of questions to Urvang.
Which is one reason why lossless WebP exists.
The FAQ directly addresses the issue of using real video codecs for these cases.
No, honestly, it's not. It is the single biggest end-user problem with the Blink image decoding system with GIFs today.
No, you can't necessarily. We do already store various decoded frames from GIFs, and we have talked about implementation of other heuristics as to precisely which frames to pick. Unfortunately, storing decoded frames comes at a memory cost, which goes up quickly with large images, long images, or lots of images on the page, all of which are scenarios we see commonly. Paying tens of megabytes or more in additional memory (and yes, that is the cost we're talking about in the janky scenarios, not "several KBs") just to make various webpages not animate as jankily is not a compelling option in all scenarios, especially on mobile devices.
And your claim that storing just one frame would halve the cost of seeking is clearly wrong. It halves the cost of seeking _to the last frame of the image_. It gives no help at all, for example, to seeking within the entire first half of the frameset. This is why the best solutions here involve heuristics to pick the frames to save. (gif2webp, for example, now uses a sliding window where it calculates the optimal keyframes to use within the window.)
That's irrelevant. Even if the argument is based solely around implementation difficulties, those difficulties are real. The FAQ answers why we're taking the course we are in Blink today, and that decision involves making the web better for a variety of very interested consumers NOW, not at some unspecified future time well down the road.
Those are not the scenarios where performance is an issue. The scenarios where performance is an issue are pages involving larger animated images -- of which I can assure you there are many.
We're looking primarily at cases involving > 5 MB of uncompressed image data. And I repeat, those are extremely common on the web today.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Peter Kasting||10/23/13 2:31 PM|
On Wed, Oct 23, 2013 at 1:58 PM, <nawoa...@gmail.com> wrote:
That's true of lossy compression schemes. WebP allows for lossless compression, and the FAQ directly addresses the lossless compression numbers -- where animated WebP is still noticeably smaller than animated GIF.
APNG compresses extremely poorly, because PNG was not designed as an animated format. There is a lot of explanation elsewhere on the web about why this is. Suffice to say that, if you're worried about compression efficiency, APNG is not going to win any awards; APNG's advantages over GIF are in things like higher color depths and better-than-1-bit alpha, which are also features animated WebP brings to the table.
No, it won't. The kinds of changes you describe making to GIFs are easily visible quality degradations.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||new...@gmail.com||10/23/13 4:08 PM|
> Feel free to send us samples of cases that don't work well. I'm sure Urvang and the other WebP folks would like to take a look at them.My tests were already posted, but just in case:
I think you tested the old gif2webp code, the one without keyframes. I tested new gif2webp, with keyframes.
> APNG compresses extremely poorly,
> I saw this a little while back, but I don't know what version of the tools they used, so I don't know how to evaluate this. I would not be surprised if a more recent toolchain encodes better. I defer these sorts of questions to Urvang.I updated them recently, the source code is from October 19. On that page I also mentioned the versions of all tools, and which command line options were used. So it's easy to reproduce.
Have you run any tests? Because in my tests, APNG clearly wins over GIF and WebP.
Here, let me show you the graph of one of my tests, it's easy to see how 4 keyframes hurt the compression rate. It shows how file size grows over 75 frames.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||Peter Kasting||10/23/13 4:11 PM|
On Wed, Oct 23, 2013 at 4:08 PM, <new...@gmail.com> wrote:
No, I was referring to the with-keyframe-insertion version.
I'll defer to Urvang for other comments since he owns the tooling here.
|Re: [blink-dev] Re: Intent to Ship: Animated WebP images||new...@gmail.com||10/23/13 4:30 PM|
If you run the tests on just a random set of GIFs from the internet, most of them will be less that 10 frames, so keyframes effect won't be noticeable.
Selecting only long (>40 frames) animations will make the effect obvious.
I use a set of 100 or so GIFs saved from http://iwdrm.tumblr.com/ (they are nicely optimized btw), and the effect from inserting keyframes becomes very clear.