animated gif vs webm-in-<img> [Was: Intent to Ship: Animated WebP images]

[Ami Fischman]

[attempting to fork the thread since it feels like this stopped being about animated webp a while ago]

Considering the number of threads we spawn per <video> tag I doubt that, e.g., http://www.tumblr.com/tagged/animated%20gif would be better served if all those .gifs were .webm's.

(I'm worried that instead of making a single renderer janky such a transition would make the entire browser janky/crashy, esp. on resource-limited platforms)

Cheers,

-a

On Fri, Jul 12, 2013 at 9:55 AM, Tab Atkins Jr. <jacka...@gmail.com> wrote:

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
videos).

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.

~TJ

[Dale Curtis]

Does your view change in the world (that we're trying to get to) where we only use 1 thread per renderer for <video>?

- dale

[Ami Fischman]

Of course.

[Tab Atkins Jr.]

On Fri, Jul 12, 2013 at 10:07 AM, Ami Fischman <fisc...@chromium.org> wrote:

> Considering the number of threads we spawn per <video> tag I doubt that,
> e.g., http://www.tumblr.com/tagged/animated%20gif would be better served if
> all those .gifs were .webm's.
> (I'm worried that instead of making a single renderer janky such a
> transition would make the entire browser janky/crashy, esp. on
> resource-limited platforms)

Ah, I didn't realize we had such a problem. Pending fixes to this
(which it sounds like we're moving to), I retract my suggestion for
now.

However, assuming that we do make such a change so that lots of
<video>s in a page don't jank up the whole browser, how does the idea
sound?

~TJ

[Ami Fischman]

On Fri, Jul 12, 2013 at 11:07 AM, Tab Atkins Jr. <jacka...@gmail.com> wrote:

However, assuming that we do make such a change so that lots of
<video>s in a page don't jank up the whole browser, how does the idea
sound?

Kinda crazy to me but maybe only because I lack vision.  Some of the obstacles I see:

- Are these sites that only accept images (not videos) known to not care about the format of the files they stick in <img> tags?  (IOW, your strategy backfires if they have a whitelist that doesn't include webm)

- Everybody supports animated GIF today; which browsers will support video-in-<img> using the semantics you describe?  (IOW are you proposing to push for this to go into the HTML spec for <img>?)

- Will this be another transcoding burden on hosting sites (like the fact that youtube vends the same frames via numerous formats today)? (IOW vp8 or h264 or ...)

Cheers,

-a

[Alpha (Hin-Chung) Lam]

In the current implementation of <video> tag you're right. There's too many threads at the moment.

But despite this one issue <video> is very close to an ideal framework for showing animating images, meaning off-main-thread, doesn't interfere with image cache and support for GPU acceleration. If it can be made lightweight (less threads) it will be a far better in terms of performance and jank than the current image animation pipeline.

2013/7/12 Ami Fischman <fisc...@chromium.org>

[Alpha (Hin-Chung) Lam]

2013/7/12 Ami Fischman <fisc...@chromium.org>

On Fri, Jul 12, 2013 at 11:07 AM, Tab Atkins Jr. <jacka...@gmail.com> wrote:

However, assuming that we do make such a change so that lots of
<video>s in a page don't jank up the whole browser, how does the idea
sound?

Kinda crazy to me but maybe only because I lack vision.  Some of the obstacles I see:

- Are these sites that only accept images (not videos) known to not care about the format of the files they stick in <img> tags?  (IOW, your strategy backfires if they have a whitelist that doesn't include webm)

Pretty much all forums that accepts uploading has a whitelist, which commonly supports only JPEG, PNG, GIF and BMP. The problem is the same for any new format.

[Peter Kasting]

On Fri, Jul 12, 2013 at 12:17 PM, Alpha (Hin-Chung) Lam <hc...@google.com> wrote:

2013/7/12 Ami Fischman <fisc...@chromium.org>

On Fri, Jul 12, 2013 at 11:07 AM, Tab Atkins Jr. <jacka...@gmail.com> wrote:

However, assuming that we do make such a change so that lots of
<video>s in a page don't jank up the whole browser, how does the idea
sound?

Kinda crazy to me but maybe only because I lack vision.  Some of the obstacles I see:

- Are these sites that only accept images (not videos) known to not care about the format of the files they stick in <img> tags?  (IOW, your strategy backfires if they have a whitelist that doesn't include webm)

Pretty much all forums that accepts uploading has a whitelist, which commonly supports only JPEG, PNG, GIF and BMP. The problem is the same for any new format.

Yep.  Animated WebP or WebM-as-image are likely to have similar issues here.

That said, if static WebP gains traction as an image format, people may be more likely to add "WebP" to the list of accepted formats in different places, in which case animated WebP can piggyback better than WebM can.

PK 

[new...@gmail.com]

On Friday, July 12, 2013 11:17:40 PM UTC+4, Alpha Lam wrote:

Pretty much all forums that accepts uploading has a whitelist, which commonly supports only JPEG, PNG, GIF and BMP. The problem is the same for any new format.

Except for APNG, which will be accepted where PNG is accepted. Unless specifically detected and blacklisted, of course.

[Tab Atkins Jr.]

On Fri, Jul 12, 2013 at 11:19 AM, Ami Fischman <fisc...@chromium.org> wrote:
> On Fri, Jul 12, 2013 at 11:07 AM, Tab Atkins Jr. <jacka...@gmail.com>
> wrote:
>>
>> However, assuming that we do make such a change so that lots of
>> <video>s in a page don't jank up the whole browser, how does the idea
>> sound?
>
>
> Kinda crazy to me but maybe only because I lack vision. Some of the
> obstacles I see:
> - Are these sites that only accept images (not videos) known to not care
> about the format of the files they stick in <img> tags? (IOW, your strategy
> backfires if they have a whitelist that doesn't include webm)

Well, not backfires, but at least is much less effective, sure. In my
experience, it's usually easy to change the set of filetypes that
forum software accepts.

> - Everybody supports animated GIF today; which browsers will support
> video-in-<img> using the semantics you describe? (IOW are you proposing to
> push for this to go into the HTML spec for <img>?)

Technically the set of formats you support is completely open-ended;
HTML doesn't say anything about this. (In the <img> case, it's
because everyone already supports a common base; in the <video> and
<audio> case, it's because nobody could agree on a common base.)

That said, the obvious hope is that if we do this, other browsers will
pick it up as well.

> - Will this be another transcoding burden on hosting sites (like the fact
> that youtube vends the same frames via numerous formats today)? (IOW vp8 or
> h264 or ...)

Only insofar as a hosting site wants to.

~TJ