1. 47
  1.  

  2. 10

    Gifs keep on being used because people like to share content links and have them autoplay. Slack and Discord to my knowledge only does that for gif files and not mp4s, unless they’re supported by an integration and even thats of dubious reliability. Which is a shame.

    1. 6

      The future is pretty cool. Not only do (basically all) browsers support multiple image types, but they probably support video! And not a plug-in in sight!

      1. 5

        APNG.

        1. 1

          What makes apng more useful than using a video file?

          1. 4

            A few:

            • Autoplay. The fact that videos may have sound dictates that browsers should treat them more cautiously. Images don’t have that problem.
            • APNG files tend to be smaller than similar looking mpeg.
            • APNG can be transparent
            1. 6
              • muted gives the same signal to browsers, and Safari can play videos in <img>.
              • APNG has crappy compression. Lossless, no motion vectors. It’s dumber than even MPEG-1. In some ways it’s even worse than GIF, because GIF can have local palettes, and APNG can’t (and true-color APNG is going to be 2-3 times larger than GIF).
              • WebM and AV1 have transparency.

              All the GIF-killers have the same primitive approach to animation, and are in the same order of magnitude of inefficiency. Your APNG, just like GIF, is still going to be 10 times larger than a modern codec, won’t have any hardware acceleration, and is going to eat lots of RAM due to lack of keyframes, so you may as well use GIF for compatibility.

              1. 1

                Today I learned something new, thanks!

        2. 5

          This is pretty cool, I took a ten minute break just now to make the change!

          for file in *.gif; do ffmpeg -i "$file" -movflags faststart \
              -pix_fmt yuv420p -f mp4 "${file%.*}.mp4"; done
          

          I also found you can also slap on preload="none" on the video tag to get lazy loading, a la loading="lazy" for images. So your video tags could look like

          <video src="/videos/foo.mp4" autoplay loop muted playsinline preload="none"/>
          
          1. 4

            To convert a GIF into a video file on the command line, I use FFmpeg.

            ffmpeg -f gif -i dancing-baby.gif dancing-baby.mp4
            

            Unless I’m mistaken, the -f is not necessary here, because ffmpeg can infer the from type from -i’s extension.

            1. 3

              Very good write up about why to use video formats over .gif but you should add some caveats about autoplay with video. Some browsers/platforms block autoplay even when muted, so you will absolutely need to implement error handling and a UI to initiate playback via a user gesture.

              Rule number 1 of autoplay on the modern web is never assume autoplay will work without fail.

              1. 8

                Autoplay is evil and should never have been allowed in the first place. a GIF has no audio so it’s slightly more acceptable although I would argue that autoplay of a GIF is probably also worth considering blocking. Video however has audio and it’s very intrusive to have a video with audio start playing when you open a page. While there are probably valid ergonomic reasons a site may want to allow autoplay for the most part websites on the internet can’t be trusted to not abuse it.

                1. 6

                  Autoplay is evil and should never have been allowed in the first place.

                  For advertising, perhaps, but autoplay itself is not inherently evil, but it can certainly be used for evil. It’s like The Force.

                  Video however has audio and it’s very intrusive to have a video with audio start playing when you open a page.

                  You are perusing a list of music videos and you click on a link to one of them, I should have to have another click to play the music video?

                  You are on a website waiting for a live stream to start, and instead of transparently being able to start playback, you have to force a user gesture to start playback?

                  You have an artsy background video, it probably needs to autoplay, but it would be nice if browser’s offered a way to tell if you’re on a metered connection so you could fallback to an image instead to save your end users money.

                  There more examples, all of perfectly valid autoplay use cases, the real issues are:

                  1. Many user’s do not have control over their own devices (Chrome)
                  2. Browser vendors still have not implemented a way to tell if someone is on a metered connection so you cannot choose to be responsible about bandwith usage, which creates problems for Good Actors in many other systems (p2p, etc)

                  While there are probably valid ergonomic reasons a site may want to allow autoplay for the most part websites on the internet can’t be trusted to not abuse it.

                  I don’t actually disagree. It should have used the permissions system so that websites can request autoplay permissions, it defeats bad actors, and allows for good actors to benefit from improved UX.

                  Instead what we got was Google’s MEI (Media Engagement Index) so they can basically whitelist bad actors that pay them enough advertising revenue ala, CNN and those absolutely annoying popup autoplaying + audio videos. And it introduced a non deterministic system which makes debugging an absolute PITA

                  1. 3

                    I think we very much agree actually. There are valid reasons for autoplay on videos to be useful. I just think that human nature and the reality of website operators on the web mean the downsides for users in aggregate outweigh the usefulness of autoplay.

                  2. 4

                    GIF has tremendous downside when compared to video: energy consumption. With GIF one must render every frame: raster frame, transfer that to GPU, render it, discard it and start raster next one. Caching frames is not probably going to be an option as those textures are going to take lot of space, which especially mobile devices can’t afford. With video all that computing cost is paid during encoding. This is also why loading spinners made from gifs are.. silly: pretty often running gif through all the sandboxing and extra buffer handling overhead uses 100% from one core.

                    1. 2

                      I don’t think anyone would seriously argue that you were wrong. Video is indeed a superior encoding for animated images. But the downside of autoplay for video has nothing to do with that. It’s purely an issue with the fact that browsers in general in the past have done a very poor job of protecting their users from bad actors in the autoplaying video space. Firefox has been taking steps recently in this direction but it’s not enough.

                      1. 1

                        Isn’t decoding h.264 much more power demanding than reading a raw video buffer? I’ve heard people say that devices that struggle playing videos are often able to play animated gifs (at the cost of ram)

                        1. 3

                          GIF is more expensive to decode than modern video codecs. It’s very poor at compressing, so the sheer volume of data is huge. It gives you 10x more data to decompress, but it’s nowhere near 10x simpler to process it. In fact it’s pretty expensive for modern CPUs, because it requires chasing pointers in a dynamic dictionary (memory and branching are slow). Modern codecs give you way less data to decompress and then some transformations and filtering that are SIMD and cache-friendly.

                  3. 3

                    Until he follows his own advice and actually provides WebM files, it won’t play in any browser on Linux (I can attest for OpenSUSE) until the user breaks patent law in their country and install H.264.

                    But VP8 is so 2013. Nowadays, I would give the libre crowd AV1. It is (or will be) supported on anything except i-devices.

                    If it’s too cumbersome to have multiple formats, wait till 2023 when the H.264 patents expire.

                    1. 2

                      Kudos to Safari for supporting videos directly in the <img> element.

                      Other browsers maintain an artificial split between “video” and “animation”. That distinction is an illusion due to historical accidents and tech debt in browser engines.

                      The usual assumptions is that “animation” is for pixel-art-like content that can’t be blurred with DCT-based encoders. But that rule hardly makes sense any more: “Animated” WebP has a DCT mode. AV1 “video” has a palette mode. Lots of meme-GIFs on the web are video clips.

                      And a second assumption is that “animations” are simpler or cheaper to decode. Except that your computer can decode full HD video without a sweat, but it would burst in flames trying to decode a full HD GIF. “Animation” formats usually dumb-down compression in order to be “simple”, but that means they have to process orders of magnitude more poorly-compressed data.

                      1. 2

                        You can do basic delta compression on GIFs, see “Frame disposal method” in this PDF. Each frame can also have its own 256-color palette!

                        But yeah videos are a better idea.

                        1. 1

                          Except the example literally didn’t work (Android, Firefox), which makes me distrust this a lot Except now it does. Hmm. I think it’s just that the Obama one didn’t loop and I didn’t scroll down fast enough.