Open Bug 895131 Opened 11 years ago Updated 1 year ago
Add support for video formats in <img>, behaving like animated gif
As an upgrade path, we should add support for video formats in <img>, behaving exactly like animated gif, but using a sane video format. They should autoplay, autoloop, and have no sound.
This was being discussed on blink-dev this week as well. We should probably coordinate with other browser vendors about this.
Just <img> or CSS images too? I imagine the latter, which would make this an imglib patch ... somehow hooking back to content/media.
(nocontrols also, as ehsan pointed out on blink-dev) CSS images is probably the "right" thing, though I cringe at animated WebM video backgrounds. But we already have ytmnd.com. :p
11 years ago
It makes the most sense for this to be applicable anywhere CSS images can be used. This probably does need to be done inside imagelib, which is a little sadmaking, but it's not without precedent.
The other issue which worries me is interoperability. We could choose one video codec format which everybody supports, or we could choose to end up in the same situation as with <video> today, and rely on a combination of srcset and image() to handle fallbacks for various formats.
There was a long "live" conversation as to what we're trying to accomplish with this, perhaps somebody can capture it here? I can also see "behaving exactly like animated gif" needing a few details sorted out.
There are many places on the web where an image is OK, or a lightweight silent video. Right now, animated gifs are used, despite all of their pretty awful qualities. The only positive aspect they have is ubiquity. What ehsan says in comment #5 is totally valid -- it would be good to choose a common video format. But I don't think one exists; IE doesn't support WebM, which is probably the closest thing. Still, I would suggest that us and Chrome supporting WebM would be a net win. It would let sites support this with a much more straightforward change (just allow webm in uploads), instead of needing to switch to <video> and similar. "behaving exactly like animated gif" is largely autoplay, nocontrols, loop, no sound. I don't think there's much to it other than that.
(In reply to comment #7) > What ehsan says in comment #5 is totally valid -- it would be good to choose a > common video format. But I don't think one exists; IE doesn't support WebM, > which is probably the closest thing. Still, I would suggest that us and Chrome > supporting WebM would be a net win. It would let sites support this with a > much more straightforward change (just allow webm in uploads), instead of > needing to switch to <video> and similar. What about H.264? In practice that video codec is uniquotous, whether we like that or not. WebM I believe is the wrong choice here because that would probably never be interoperable with IE and Safari.
I think we might as well just support all the video formats we support.
Using HTMLMediaElement for this from imglib seems hard especially for CSS image values. It's probably easier/better to implement a new subclass of MediaDecoderOwner for this. GetVideoFrameContainer would need to return a new kind of VideoFrameContainer that forwards notifications to the imglib code to update animation frames. This should work with OMT animated images.
Is this a good mentored bug? Or someone want to take it on as a side project? Seems like it would be a nice win for the web for us to do this.
I think we want this in order to easily deploy GIF -> WebM (or H264) conversion in the Janus proxy, so I will try to take a look at it.
(possible duplicate: https://bugzilla.mozilla.org/show_bug.cgi?id=1041233) Safari shipped this earlier this year: https://bugs.webkit.org/show_bug.cgi?id=176825 (to much fanfare: https://calendar.perfplanet.com/2017/animated-gif-without-the-gif/) Blink has had a lot of discussion about this recently, including a prototype implementation: https://bugs.chromium.org/p/chromium/issues/detail?id=791658 Anybody interested in picking it up?
You need to log in before you can comment on or make changes to this bug.