Evolution of <img>: Gif without the GIF
calendar.perfplanet.com
calendar.perfplanet.com
[1] http://scratchpad.wikia.com/wiki/MPEG_patent_lists#H.264_pat... (the vast majority of the patents will expire by 2023, but 2027 is the last probable date that it will be encumbered)
Further, they claimed VP8 infringed no patents but refused to indemnify users against patent suits; the MPEG LA began forming a patent pool on behalf of companies that claimed to hold patents on the techniques in use in VP8 and the situation didn't clear up until 2013, when Google essentially paid the license fees for everyone and agreed to sublicense these out [2].
They continued evolving the bitstream with incompatible revisions, which haven't even been finalized [3]. Nonetheless, this VP9 is widely deployed in Google properties today.
In the future, a consensus codec AV1 developed by a consortium of companies will be ready for public consumption; this codec descends from VP9 while incorporating significant enhancements from Cisco and Xiph.Org. The participant companies are numerous and include big chipmakers and content delivery networks, banding together to perpetuate a royalty-free video codec that mounts a competition against MPEG's efforts, whose rules don't exclude techniques that are patented. Until AV1 is ready and good, MPEG formats form a superior choice on technical merit, as well as rigor in documentation should you choose to make an independent implementation.
[1] https://en.wikipedia.org/wiki/VP8 [2] https://techcrunch.com/2013/03/07/google-and-mpeg-la-sign-li... [3] https://www.webmproject.org/vp9/
IMO, video formats will live and die based on hardware support. If your mobile device doesn't come with a AV1 hardware decoder that works with the majority of players out-of-the-box than chances are streaming services won't support it. Apple's advantage with HEVC adoption will be their hardware.
What about how they're used makes them "proprietary"? If there's open source implementations of them that aren't patent-encumbered, then that's terrific.
By the way, MP4 is a completely open standard (open does not equate 'free') and is free to use for videos that are also freely distributed. Of course there are also free and open source implementations of the codec. Being patent encumbered sucks but in principle there should be no practical limitation for gifs at least.
mp4 is a container. It typically contains an audio stream and a video stream. The streams are encoded and the majority of the formats are patented with license fees.
Why do they do this?
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)
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.
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.
You cannot easily control the volume until the video starts playing; not even when the video is still loading.
Luckily on newer version of Android there is always an option to quickly access the media volume after you press the volume button once, but it's still unintuitive.
[1]: https://www.linux.com/news/mjpeg-tools [2]: https://sourceforge.net/p/mjpeg/Code/483/
Maybe this one? (Now dead link): http://tycho.usno.navy.mil/utclock.html
It's also possible to live-stream video as a GIF(!):
gopher://sdf.org/0/users/irl/blog/2012-08-20-streaming-video-over-gopher.md
(There was a discussion about this on the gopher-project mailing list in August 2012, but unfortunately GMane is down and I can't provide a link.)
Video require more technical skill and different software people would have to learn (and time in case you need to edit it frame by frame).
What I find nonsensical is that imgur only lets you upload gif which it then converts to video instead of allowing you to upload video directly.
Maximum quality is usually via
Video editor:
VirtualDub
MKVToolNix
(cut a scene and convert to uncompressed video)
GIF editor (they are still around):
Jasc Animation Shop
Ulead Gif Animator
(open uncompressed video and convert to GIF)
And there are a ton of noob-friendly tools that combine the two.
But what changed was that people simply started ripping frames from HD videos, dumping them into gifs and plastering them all over social media.
End result was that the gifs ballooned in size because they now held many more images, and each images was much higher resolution.
What is more wacky is why gifs returned to fashion at all. They were dead for nearly a decade after people stopped doing their own web sites, and used gifs for things like animated "under construction" signs.
Same reason that H.264 won the web video standards war: mobile.
While mobile browsers can now embed videos reliably that wasn't always the case, and if there's one thing mobile users hate it's links opening other apps. GIFs allowed "video" content to be displayed inline easily in a mostly universal fashion.
- A "minimum viable animated thing" tag is more complicated for videos:
<video autoplay loop muted src=video.mp4>
Find the missing tech company: http://aomedia.org/about-us/
https://blog.imgur.com/2014/10/09/introducing-gifv/ gifv is just rebranded mp4 more or less
For example, imgur redirects hotlinked images to its embedded view in some cases. One of those cases is when they decide that your domain is using them as a CDN, which they forbid.
I don't hope they go down the Imageshack road...
At least this is in the continuity of the legacy GIF format.[1] </sarcasm>
[1] https://en.wikipedia.org/wiki/GIF#Unisys_and_LZW_patent_enfo...
Maybe when used correctly. In the tech space, it seems like they hardly are, anymore.
The problem is price. What should these patents cost.
"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...
So it kind of never works like gifs.
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.
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.
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
You could probably polyfill something in WebAssembly for it, however!
Better compression than MP4?
It's still useless when things are moving, but it's no worse than gif.
No format that I'm aware of supports lossless compression that spans frames. Which leads to a funny situation where some images compress best by custom outputting a .gif or .png with no compression, and then zipping it.
And so does apng, more or less, via alpha. But that's less important than motion interpolation, which it utterly lacks.
Fresh start of latest release version of Firefox and it shoots up to 4GB memory the moment I open just that page!
https://i.imgur.com/KJaWy2G.png
Note that Chrome also has the same page open (as well as several others) and is using less than 800MB memory.
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.
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.
EDIT: original author put this up on medium - https://medium.com/@colinbendell/evolution-of-img-gif-withou...
Btw. from the TL;DR: This post is 46MB on Chrome but 2MB in Safari TP
And the post looks great in Firefox Quantum ;-)
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.
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/). Video codecs aren't optimized for this - you won't see the comparison for such GIF's on the linked webpage.
The majority of the GIFs being produced today are not things the GIF format was designed to handle.
https://webkit.org/blog/6784/new-video-policies-for-ios/
"<video> elements will be allowed to autoplay without a user gesture if their source media contains no audio tracks."
"<video muted> elements will also be allowed to autoplay without a user gesture."
"If a <video> element gains an audio track or becomes un-muted without a user gesture, playback will pause."
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!
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.
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.
I think we should not deny its future proving goodnees.
Animated PNG is probably a better replacement for those.
(We can put the bytecode of the encoder/decoder in some content-addressable remote storage, and pre-fetch/pre-optimize it when necessary.)
We have <video>, so why not use that?
What next? Utterly ridiculous, Apple.