
Evolution of &lt;img&gt;: Gif without the GIF - cflat
https://calendar.perfplanet.com/2017/animated-gif-without-the-gif/
======
mmastrac
Unsurprisingly, Apple goes for the patent-encumbered video format [1]. I'm
disappointed that Firefox never really had the opportunity to "win" the
browser wars and push more user- and developer-friendly formats on the world.

[1]
[http://scratchpad.wikia.com/wiki/MPEG_patent_lists#H.264_pat...](http://scratchpad.wikia.com/wiki/MPEG_patent_lists#H.264_patents)
(the vast majority of the patents will expire by 2023, but 2027 is the last
probable date that it will be encumbered)

~~~
bpicolo
This is to support sites like imgur, reddit that are essentially distributing
GIFs as MP4s now. They didn't really determine the format that the community
adopted

~~~
jessriedel
I've never really understood this. I previously had figured that the
popularity of GIFs on reddit had been about bandwidth and load times. In that
past, video would be too slow for the rapid novelty stimulus reddit offered,
while GIFs were lightening. But now every "GIF" people post is a just full
movie, and it loads more slowly than YouTube or other websites that are
smartly structured to handle video.

Why do they do this?

~~~
bpicolo
[https://blog.imgur.com/2014/10/09/introducing-
gifv/](https://blog.imgur.com/2014/10/09/introducing-gifv/) has some of the
details.

It definitely makes sense technically. It should in most cases reduce file
size, and also allows you to stream content in buffered so you don't need to
wait for the whole thing to load for it to play. (Though I believe streaming
in gifs is teeeechnically possible? I feel like I saw a demo one time that
made a clock by streaming in gif frames)

~~~
jessriedel
Hey thanks, this is super useful! I still don't quite get it though. I
understand that converting huge HD GIFs to a standard video format allows
steaming and better compression, but why encourage people to upload it like
this rather than just upload videos?

The only explanation in the post is "the culture of the GIF now trumps the
file format. With Project GIFV, Imgur is reimagining the looping GIF video
with all the richness it deserves as a key piece of Internet culture." Is the
idea just that people want soundless looping HD video, and they're accustomed
to uploading GIFs, so Imgur is going to accommodate them by doing the
conversions server-side?

I guess this is an explanation, but it's a surprising one. For instance, it
doesn't really fit well with the observation that people uploaded GIFs of
content that was obviously native video and not connected to internet GIF
culture, e.g., sports videos.

~~~
Strom
Yes it's all about no sound. Everyone likes opening up a bunch of tabs that
include auto-playing funny looping videos, but nobody likes auto-playing
sound, especially if it overlaps with some other sound.

~~~
dspillett
I'm not sure if it is Chrome's doing or YouTube's, but if I open a couple of
youtube links in tabs (a selection from the "related" list to the right of one
I'm currently watching for instance) the clips in the new tabs don't start
playing until that tab gains focus. This avoids the auto-playing sound
overlapping problem _and_ means you don't miss the start of the clip and drop
in part way through. Surely this is the solution to that selection of
requirements?

~~~
Strom
I've noticed the Chrome feature as well. I watch a lot of Twitch streams, and
it causes a frustrating experience, albeit with possible workarounds by
Twitch. It's that Twitch is about live streams and live chat, but now the
video autoplay is delayed until I activate the tab, but chat is still live
from the moment I clicked on the link. It basically buffers the stream now,
but makes me go out of sync with chat. One alleviator could be Twitch adding a
"go live" button that shows up when I'm not live.

There are still two classes of problems unaffected by this change.

1) As is popular with gifs, there could very well be multiple of these
autoplaying videos on the same page, probably even multiple fitting in the
same viewport area. If they had sound, these would interfere with eachother.

2) My understanding is that many listen to music from some source unrelated to
the webpage containing these autoplaying videos. So even if there's only one
video, its autoplaying sound could easily mix with my tunes.

Doing autoplaying sound is hard, but with gaze tracking and knowledge of
system sound usage status, I think a pretty good solution is possible.

------
detaro
I don't see why the "issues" with the <video> tag couldn't be fixed in the
video tag?

"Autoplay video is used for ads and thus controlled by browsers" (and <img>
video won't have the same development?!) and "<video> can't be saved" (yes, if
you use a JavaScript player that interferes with it, if you just link in a
file through a <video> tag at least FF and Chrome do have a save option) seem
especially nonsensical.

I guess there is some semantic argument for "videos that should act like
images", but I somehow doubt that'll happen nicely...

~~~
seanalltogether
> I don't see why the "issues" with the <video> tag couldn't be fixed in the
> video tag?

You could make that argument for a lot of html tags. <address>, <section>,
<figure>. Perhaps this is the safari teams opening argument for a new tag to
be added to the spec.

~~~
lojack
Those tags add semantic meaning. Putting video in your img tag as opposed to
fixing the video tag does the opposite.

~~~
Dylan16807
It doesn't "do the opposite". It applies a different, better-fitting semantic
meaning.

------
jwarren
I was appalled when I first started reading this.

But in reality, it feels quite true to HTML. The HTML author is declaring to
the browser the purpose of this asset. This one is to be viewed as an image.
This other asset is to be viewed as a video.

The encoding format shouldn't dictate the tag, the content and intent should.

We've been okay with animated GIFs being images for long enough now that we've
kind of opted into animated images being okay in general.

~~~
chias
I hate that I can't find fault with this argument.

------
hbbio
APNG is also a very good way to achieve that! No limits in the number of
colors, better compression. No patents?

All major browsers now support APNG, Chrome being the last in the bunch :) For
example, we use it in our README screencast for
[https://github.com/wallix/awless](https://github.com/wallix/awless)

~~~
mmastrac
I didn't realize support for this had improved, but it's still missing Edge:
[https://caniuse.com/#feat=apng](https://caniuse.com/#feat=apng)

You could probably polyfill something in WebAssembly for it, however!

~~~
cflat
still ridiculously large file compared to webm/mp4. The alpha support is cool
though.

------
treve
This seems super pointless.

Their reasons:

> 1\. Browser performance is slow with <video>

Maybe look into ways to make <video> fast?

> 2\. You can’t right click and save video

I never had an issue with this... But if Safari does, perhaps they should have
fixed that there?

> 3\. Autoplay abuse

Mute the video or remove the audiotrack. If even this in the future gets
prevented to autoplay, then I don't see how <img> tags wouldn't as well. After
all, they're just becoming the same thing.

~~~
SaltySolomon
1\. The issue here is what browsers are expecting with a <video> tag, which is
long-form content and that's what they are optimizing for.

2\. Depends on the browser and the player that is used.

3\. Well, the <img> tag is by default much more limited, hence it is less of
interested to the ad companies and the browsers allow it more freedom. But yes
I agree that this is a point the browser developers should improve upon.

~~~
phyzome
For #1, Safari could support a "shortform" hint on the video tag.

------
che_shirecat
Linked site is down - it's a pretty well-written writeup, archived here -
[https://web.archive.org/web/20171204164627/https://calendar....](https://web.archive.org/web/20171204164627/https://calendar.perfplanet.com/2017/animated-
gif-without-the-gif/)

EDIT: original author put this up on medium -
[https://medium.com/@colinbendell/evolution-of-img-gif-
withou...](https://medium.com/@colinbendell/evolution-of-img-gif-without-the-
gif-8da25adcca15)

------
retrac98
Oh the irony of a site named "perf planet" going down under a little HN
traffic.

~~~
prathiks
was thinking the same high fi

------
pendar747
This page crashes on chromium before you even have the opportunity to read
half of the article. I wonder if there is a memory leak or it's just the GIF
implementation in chromium.

~~~
JepZ
same same (chrome 62; x86_64 Linux)

Btw. from the TL;DR: This post is 46MB on Chrome but 2MB in Safari TP

And the post looks great in Firefox Quantum ;-)

------
twhb
The crux of the problem seems to be where we encode the information "this
video should loop".

We did it before in surrounding HTML structure. The proposal is to now do it
different, slightly shorter, surrounding HTML structure. As far as I can see,
there's no fundamental difference, just syntax sugar and a battleground reset.

How do we get the video to loop when viewed directly? When set as the
background? When saved as a file? These are use cases that .gif satisfies and
videos don't, or only awkwardly and inconsistently.

Also note that content is inherently suited or unsuited to looping. It's
rarely useful to play a normal video on a loop, or a video meant to loop just
once.

All this points to one solution: a new file extension that means "a video
meant to be played in a loop". The format of the file need not be any
different from a video. Maybe ".mp4l", ".webml", etc.

~~~
missblit
That would have some downsides. You to browser behavior to url in a way that
never been done before, it doesn't really account for mime types or content
encoding, it isn't backwards compatible at all, it doesn't allow you to use
one resource in both ways, and it relies on duplicating all extension names 2x
for all video formats and times no one unrelated will make a video formats
ending in 'l'. If we must change this some combination of css and/or js would
probably work better. Like 'img { repeat: none; }' for example

------
romwell
One of the reasons GIF's are popular is that it's a format with nearly
universal support, with no codecs to fuss about. Anyone can see a GIF, and
anyone can edit a GIF.

The proposed "improvement" offers the key limitations of GIF without the key
advantages, and lacks many features.

Like, what about variable frame rate? Transparency? Not fuzzing out the pixels
in pixel-art?

The last one specifically: a great use-case for GIF is capturing screen
animations (see
[https://www.cockos.com/licecap/](https://www.cockos.com/licecap/)). Video
codecs aren't optimized for this - you won't see the comparison for such GIF's
on the linked webpage.

~~~
wolrah
It's not supposed to replace GIFs for the things they're actually good at,
like your examples. It's supposed to replace the abuse of GIFs for things
they're not good at, like long, high frame rate, and/or high color depth
videos.

The majority of the GIFs being produced today are not things the GIF format
was designed to handle.

------
potch
I've floated the idea of allowing various video formats in <source> for the
<picture> element. Would allow for the right codec to be selected, and would
easily allow for a <img src="foo.gif"> as the final fallback. Might be worth
pushing on more.

~~~
cflat
Don't know if you need a spec change since this is technically now supported
in Safari TP. (See the example) Really it's up to the browser to decide if it
wants to use the media type or not.

------
koolba
The article mentions removing the audio track. Is that required for this to
work or would it play if it's included or is that just for efficiency? i.e.
will Safari simply ignore it if it's included?

~~~
cflat
don't need to remove the audio. it's muted by the browser. removing audio just
saves bytes.

~~~
floatingatoll
Incorrect. If an audio track is present, the mp4 does not qualify for autoplay
unless other conditions are met.

EDIT: Context is unclear about whether the parent's guidance is about <video>
or <img>. No idea what <img> does. I sure hope it doesn't play due to the
wasteful audio track, so that people are forced to do it right instead of
lazy, though!

~~~
cflat
in the context of <img> the audio track doesn't play anyway. dropping it
ensures you save the bytes.

------
Ajedi32
Site is down for me so I have no idea if they addressed this in the article or
not, but what's wrong with the `<video>` tag?

As a user, I greatly prefer that option since it lets me control playback (via
the "show controls" menu option) whereas GIFs (and presumably also mp4
"images") don't.

~~~
cflat
the biggest draw back is the browser preloader and general performance. For
cinemagraphs & clips this will be great. Anytime you want to add audio or
pause/control playback, this will be the wrong solution.

~~~
Ajedi32
> the biggest draw back is the browser preloader and general performance

So why can't we just fix that issue with the `<video>` tag? (Maybe with a
`preload` attribute or something.) It just seems semantically incorrect to be
putting videos in `<img>` tags (and yes, I realize this same argument applies
to GIFs as well).

> Anytime you want to add audio or pause/control playback, this will be the
> wrong solution

I'm referring to me as a user showing controls even when the site has them
hidden. Obviously as a developer I can always just choose to not use this
feature and use a video tag instead.

------
cflat
Mirror: [https://medium.com/@colinbendell/evolution-of-img-gif-
withou...](https://medium.com/@colinbendell/evolution-of-img-gif-without-the-
gif-8da25adcca15)

------
roh0sun
It’s just HEIF.
[http://nokiatech.github.io/heif/technical.html](http://nokiatech.github.io/heif/technical.html)

I think we should not deny its future proving goodnees.

~~~
cflat
mp4s aren't HEIF. but this feature is certainly pre-lude to Safari supporting
HEIF in the browser.

------
bsimpson
If you're interested in seeing this in Chrome, star
[https://crbug.com/791658](https://crbug.com/791658)

------
the8472
Does it support transparency and 4:4:4 chroma? Otherwise it does not cover all
gif use cases. Namely pixel art and sprites.

Animated PNG is probably a better replacement for those.

------
xvilka
WebP and APNG are both good formats instead of GIF. But the problem is that
Chrome developers stubbornly do not want to add APNG support, while Firefox
developers, also stubbornly, do not want to add WebP support. "Thanks" to both
those teams we are forced to do such hacks...

------
amelius
Can we please replace image and video formats by something more generic, e.g.
bytecode+data?

(We can put the bytecode of the encoder/decoder in some content-addressable
remote storage, and pre-fetch/pre-optimize it when necessary.)

~~~
chronial
Videos are usually decoded in hardware.

~~~
amelius
Yes, the solution to that is to make opcodes for the special instructions
typically available in hardware, e.g. discrete cosine transforms; or a more
coarse grained approach if necessary. Eventually, it will be up to platform
owners to provide translations from the bytecode to the underlying hardware.

------
JCharante
Did it get hugged? The website isn't loading for me.

------
yeldarb
Link is dead. Is it also supported on mobile Safari?

------
lordnaikon
Still no date as input type :(

------
est
IE 5.5 supported <img dynsrc=""> back in the 90s.

------
prathiks
what other browsers are drinking this cool aid

------
ourcat
But .mp4 is a video/... MIME type. Not an image/...

We have <video>, so why not use that?

What next? Utterly ridiculous, Apple.

~~~
azinman2
Probably because videos don’t auto play anymore and they come with controls?

~~~
ourcat
But aren't Apple the only people enforcing that?

~~~
cflat
Chrome now has the same enforcement for <video> tags.

