[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.
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.
Why do they do this?
Find the missing tech company: http://aomedia.org/about-us/
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.
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.
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.
"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.
We have <video>, so why not use that?
What next? Utterly ridiculous, Apple.
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!
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.
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.
(We can put the bytecode of the encoder/decoder in some content-addressable remote storage, and pre-fetch/pre-optimize it when necessary.)
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.
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.
I think we should not deny its future proving goodnees.
EDIT: original author put this up on medium - https://medium.com/@colinbendell/evolution-of-img-gif-withou...
Animated PNG is probably a better replacement for those.
