I think one based on VP10 is a possibility, since the Alliance for Open Media now includes all major browser makers except Apple, and a bunch of big websites.
Currently the members seem to be working on converging VP10, Daala and Thor tech in the video realm but I'd guess images might be on their radar too.
The first official version of FLIF has not been released yet, and currently they are discussing releasing it under Apache 2 or MPL (Mozilla Public License).
I don't even get to spot the difference. For some reason on my box chrome pegs the cpu at 25% for about 30 seconds then asks me to kill the page. Stripping out the alternate format, the other one plays instantly and with minimal cpu usage.
We're essentially converting from one frequency-domain format to another in order to accommodate an entirely new inter-frame compression format. There definitely needs to be a frequency-domain to spatial-domain conversion, which that, in itself, is lossy, then it goes back to frequency-domain when re-encoding.
Not trying to not give them a break, but I'm pointing out they said clearly there's no difference in quality. There surely is.
To your excellent point about MP4 to BPG conversion, I'd say that OP should have used (did they? I don't know) the source material to avoid a "copy of a copy."
Granted, the Author should have been clearer about it, but BPG's is not mean to replace MP4 even though he juxtaposed them, it's about BPG's potential replacement for GIF.
In the part where it says "Spot the difference" and everyone says "The BPG one looks worse". That's because BPG, even in "lossless" mode... is lossy. So you're taking a video with H.264 compression artifacts and recompressing it with HEVC artifacts. The quality can only go down.
FLIF on the other hand is lossless, so the image would be truly identical (pixel for pixel). However the filesize will likely be much larger, as MP4 is a very good at lossy compression. What BPG is doing is better performed by HTML5 video formats that already exist due to hardware acceleration support for H.264 and better memory management for video. Also there are patent issues with BPG due to it being based on HEVC.
FLIF is patent free, making it the more likely candidate for mass adoption. It's animation, like APNG is lossless and supports full 24-bit transparency (versus GIF's 8-bit). However the filesize for FLIF is considerably smaller than APNG, even when crushing it with algorithms like Zopfli. Still though, for full frame video, you'll have a better time with MP4, though FLIF will be better quality, it will only be marginal and not likely noticeable in most cases.
What is interesting is the responsive aspect of FLIF. If you encoded an HD video, but only display it on a page at a lower resolution, it will only download the minimum amount of data required to display the image up to that resolution. So it could technically require a lot less bandwidth from a server compared to MP4 if the user doesn't fullscreen the video. But this is more to do with implementation than with formats. YouTube does this same idea, though with a completely different style of execution, in which they only give the the quality for the resolution you are playing it at.
3) If digital cameras would use FLIF, they would probably need to implement a simplified encoder in hardware, e.g. one that uses a hardcoded (set of) MANIAC tree(s) and only uses a subset of the available encoding options. Otherwise it will be too slow.
The first official version of FLIF has not been released yet, and currently they are discussing releasing it under Apache 2 or MPL (Mozilla Public License).
FLIF only has a lossless mode. For lossless animation, it usually beats GIF, APNG, MNG, WebP and BPG. It is the only responsive animation format afaik.
For lossy movies, actual video codecs are best, since they're designed for that. BPG is essentially HEVC (a great but patent-encumbered video codec) so it should be good at lossy movies -- it will be worse on line-art animations with hard edges like e.g. cartoons, or animations with transparency.
Thanks for the compliment about FLIF's progressive decoding! (FLIF author speaking here)
However, truncated FLIF files will (probably) never achieve the same quality/size ratio as dedicated lossy methods that can produce a completely different file for each quality setting.
So at the moment I still see an important use case for lossy methods. However, in the future, I can imagine that people will start to demand/expect lossless encoding, to avoid generation loss and to get the most out of their display hardware.
E.g. higher bit depths are becoming a thing, while the JPEG/WebP color space (YCbCr) is effectively less than 22 bits per pixel (roughly speaking, red and blue are only 7-bit), and chroma subsampling makes this even worse. Also what's the use of ever higher display resolutions if most of those pixels are only displaying compression artifacts or blur?
Lossy formats like JPEG/WebP/BPG/JP2/JXR are good at medium-quality, but if you use them at a near-lossless quality setting (e.g. 99 or 100 for JPEG), they often produce bigger files than lossless formats.
Meanwhile, the range of display sizes is getting larger: while in the past, we had a range from say 13" monitors to 21" monitors, now we have a range from 1.5" smart watches to huge 100" smart TVs. I do think that in order to avoid huge amounts of rescaling/transcoding, we need image/video formats that are "responsive by design", like JPEG2000 and FLIF (and progressive JPEG to some extent).
Good luck, it sounds like a great format! One really nice thing about lossless formats is that they are great for archival purposes since you can easily convert them to whatever format is currently optimal or convenient for end use (if you don't want to use it directly). I shudder at the number of complex video implementations that may need to be supported forever due to quality loss if you convert them.
As a fun side project I was thinking of writing a clean room FLIF en/decoder, but I can't seem to find any paper or real explanation of the mechanics. Are those coming, or did I just miss those?
FLIF is based on context mixing so it's extremely slow but has an extremely high (lossless) compression ratio. It's designed for image archival and not for real-time streaming video. It does have some interlacing techniques for previewing the image in a lower resolution but really it's orders of magnitude slower than other image formats.
The current decode time (on a lower end ARM CPU) is approx 1 megabyte per second. This of course will increase as the format is finalized and better/more optimized decoders are written for it. As well as with CPU speeds increasing. Though even at the current rate it should be fast enough in almost any real world scenario. A 1080p video on youtube is about 260-320 kilobytes per second. So as long as video quality doesn't demand 3-4 times what we are currently getting from HD video online, it should decode faster than it matters. Plus the whole video is available as it downloads in a lower resolution. It just gets clearer the longer it plays. Which is a much better experience than GIF/APNG/BPG/WebP and even MP4 in use as a GIF replacement. Though the MP4 will almost certainly be visually as good of quality at a consistently much smaller filesize due to H.264's fantastic lossy compression.
Implementing an image format via JS is cool, but I'm not sure what the use-case is for this format that isn't already covered (and supported in browsers) by other formats.
https://en.wikipedia.org/wiki/APNG should be a better alternative for GIF-like images (including transparency and low bit depth), and MP4 + H.265 should be the alternative for movie-like content. For most platforms, you might even get decoding support in hardware, so performance and battery life shouldn't be anything but better vs this.
> [APNG] should be a better alternative for GIF-like images (including transparency and low bit depth), and MP4 + H.265 should be the alternative for movie-like content.
H.264/H.265 are good for both Gif-like and movie-like content. Bandwidth isn't cheap. Although APNG has inter-frame compression, it is nowhere near as sophisticated as H.265 let alone H.264.
If I want animation, why would I use a format that puts a burden on users, when alternatives already exist?
Don't get me wrong, I totally acknowledge that we still have the issue of mp4 files not autoplaying on mobile browsers. However, once that is solved, I would avoid APNG and Gif, in favour of said video format.
Here's hoping that one day, BPG is adopted widely, so that I can forgo mp4 and APNG/Gif entirely for use cases that cover short animations for aesthetic reasons.
Albeit, I do admit, for the time being, I will resort to using mp4 and OGG on the desktop browser, and either a static image or APNG on the mobile browser.
Do content providers have to pay certain royalties with h.264? I thought the players were free of royalties and the license was paid for encoded content. And then with h.265 I thought I heard that there were two different license pools with different licensing strategies.
I'm not sure that meme generators have royalties very high on their list of concerns, the big hosts that host a lot of them might have some concerns about it though.
At this point, a newer webP based off the newer VP10 might be the only realistic PNG, GIF, and JPEG replacement but it doesn't exist yet.
For H.264 it's the opposite (for web content), only the players need to pay royalties.
For H.265, both need to pay royalties, which depend on the business model. The licensing terms are pretty much totally unsuited for usage as a still image format. And yes, there are multiple pools and you have to pay all of them.
No, hence, Gif/APNG are good for lossless animations. But for sites like imgur that host animations, I would like it if their gifv format (pretty much mp4/webm) played immediately on my mobile, without it having to be a gif file.
Author says that the BPG version is re-encoded from the MP4, so lower quality is to be expected. Looking at the linked comparison tool[1], it seems that while BPG and WebP both have fewer artefacts than JPEG at a given file-size, BPG seems to achieve this with waaaay too much smoothing. Seriously, check out the engineer's eyelids in [1].
I take your comment to mean that you find the BPG version of that engineer picture -- being "overly smoothed" -- to be unrealistic, comparatively. I think the face, as a whole, looks crisper. Even though the sharpness isn't there, the lack of visible artifacts just looks plain better. This reminds me, weirdly, of seeing video through an old television. The resolution is poor, but it's not poor in a way where I think the image is fake. Things still look real.
Separately, though, take a look at other features of the image: the beams running lengthwise down the shell, specifically the ones on the top left of the image. The BPG version makes them look niceeeeee and crisp, whereas the WebP version looks very bad.
Other places where I think the BPG compression looks noticeably better: her uniform (right sleeve, right leg, etc), the rivets along the top edge of the platform she's standing on, where she's grabbing that power tool.
One thing I noticed in the BPG version is that some gradient areas have more visual banding compared to the WebP version.
Why can't we just use MP4? Add an inline JavaScript decoder for Mobile Safari, and then at least all the other browsers get instant hardware decoding.
Are there trust issues with allowing third-party MP4 embeds into user-submitted content such as forums/hosted blogs? Do we need a "no sound"/"max file size" attribute on the video tag?
Videos--more specifically mp4 videos--can be embedded into web pages. They just don't autoplay on mobile browsers.
Hence why there is a push for alternatives to Gif/APNG and mp4/webm. We want a video-like animation, that plays on page load.
Now, the real question is, why don't mp4s play when we hit play?
I can only speculate, but I think it's because mp4s are streamable media, where a troll can simply decide to keep streaming mp4s and drain the user's bandwidth. (Never mind the fact that it is also a problem with Gifs.)
Half the comments are pointing out that BPG is implemented in JavaScript.
Like no shit? It's not natively supported in browsers, and OP makes a call for everyone to push browsers to natively support it.
I mean like, geez, I want a proper video-like playback format (e.g. 24+ frames per second) at a smaller file size, so that I can view videos on my mobile phone.
Gif lags on mobile internet, and MP4 requires that we explicitly hit the play button on mobile browsers.
So either we adopt a format like BPG, or adopt another format based on h.264/h.265/VP8/VP9/Theora but for the sole purpose of being a Gif-like animation.
> Gif lags on mobile internet, and MP4 requires that we explicitly hit the play button on mobile browsers.
Wouldn't the more obvious choice be simply adding an option in browsers to not require hitting the play button (perhaps for MP4 that has no sound)?
Even with browser support for BPG, MP4 has the huge advantage of hardware acceleration in almost all modern devices[1].
[1] In theory, BPG may be able to take advantage of similar hardware acceleration, but why not just fix the user experience around an existing format rather than implement yet another format?
Honestly, I view the need to hit the play button as the right user-experience. Sure, a user-defined option to turn that off would be cool, but I'd never use it. I wish GIFs had that option as well, actually
I agree - I wouldn't enable that option either, but at least it'd offer a better alternative for people who do like GIFs / GIF-like animations.
It's a bit ironic that the autoplay functionality of BPG is touted by some as a major advantage, yet the only reason it autoplays is because it currently has to be implemented in Javascript (bypassing the normal push-to-play behavior of web video).
If the people pushing for native BPG browser support get their way, the most likely outcome will be BPG implemented with the same push-to-play UX as any other kind of web video.
(I know this is really late, but HN has been really aggressive about "submitting too fast" lately, and a half hour's wait didn't convince it to let me try again.)
I'm sorry; you're right, I misunderstood your needs, and thought that you wanted GIFs not to play at all. As with "there's an app for that", the answer to most Firefox needs is "there's an extension for that". I'm not in touch with the current Firefox extension ecosystem, but some Googling suggests that https://addons.mozilla.org/en-US/firefox/addon/toggle-animat... should fill the need.
Mp4 requiring you to hit play is a /feature/ in my book. The fact that animated gifs automatically play has caused more problems, like annoying banner ads, than it's created.
Were this fifteen years ago, I'd recommend that the makers of this format create a proper plugin to handle this format in the interim, but because browser makers are terrified of extra functionality, especially on mobiles, we can't do that anymore.
Tried to just view the BPG alone by right clicking and "view image". it just gave a static png though. Amusingly the URL of the static picture is amazingly long (at least thousands of bytes) and does nasty things to my computer when I tried to copy it.
Edit: It actually appears to be the images encoded since it starts with "data:image/png;base64"
its a serious question, in 2 years HVEC decoders will be in all hardware. Which means fast, energy efficient decoders on virtually all platforms.
Having a seperate codec, which is basically a less capable version of an industry standard, whats the point? (ignoring the still images part for a second.)
How do the new lossy video formats work for looped videos? It looks like gifv has been accepted by r/perfectLoops...[1] Do HEVC etc require the last frame of a video to be a keyframe? Are predicted frames specified at the same quality level as keyframes?
Wow, this throws me back to the early 90s, when we would basically have the same discussions about JPEG vs GIF. At the time most graphics programs could open a GIF you downloaded with your modem, but if you wanted to view a JPEG you had to jump out to a separate program, and everyone said that as soon as there was native JPEG support no one would use GIF anymore.
If people said that then they were silly, because JPEG and GIF solve different problems. JPEG didn't displace GIF because JPEG doesn't actually do a good job of compressing the images that GIF is good at compressing. Note that once a format came along that was good at those, namely PNG, it did displace GIF pretty much entirely for the still-image use case.
APNG was rejected primarily because it used image/png when it was clearly a video, and the WG felt that images shouldn't handle video. When video/png was offered instead, Mozilla rejected that because it felt backwards compatibility was more important.
So, basically, it was rejected due to a pissing contest on the least important part of the specification.
Hah yep given how long GIF has persisted, I think it's clear that nobody cares about what is the best format in terms of technical achievement. It's all about what is most compatible.
Anyone else try drag/drop BPG? Didn't work for me. GIF thrives despite flaws because works everywhere, easy to use, remix, and above all: easy to share.
Uhmm... OP is demonstrating an example using a JavaScript-based polyfill.
If we rejected every feature that began as mere polyfills, we wouldn't have the web that we have today.
Here's just a few examples: we would need images for rounded corners, Gif/Flash/JavaScript for animations, Cookies for storage, Flash for browser-based webcam calls, etc.
Because the internet doesn't need a HUGE lossless animated image format. What it needs is something GIF-like (animated images with no sound) that works universally, is smaller, and doesn't consume too much battery on mobile devices.
So BPG (or others) could replace GIF for the way GIF is commonly used today, rather than a direct 1:1 drop in replacement in all scenarios. If you really need lossless then continue to use GIF, support isn't going away soon, but for small soundless animations, a better alternative may be welcomed.
PS - The statement "The author clearly doesn't know what they're talking about." is inflammatory and needless. The author never said anything either way about lossless/lossy.
GIF is extremely lossy for this use case since they can't do 24-bit color. In addition to being unnecessarily gigantic, animated GIFs also look terrible for just about anything that isn't pixel art. GIF itself is a lossless format, but when you use it for stuff like this the whole process is super lossy.
Perhaps GIF wasn't intended for this use case? Oh right, it wasn't. There are plenty of video formats that are. That doesn't make them "GIF replacement".
GIF has already been replaced by better formats. The one exception to this is short, looping videos, where GIF still enjoys enormous popularity.
So yeah, GIF wasn't intended for this use case. But that's the use case it has right now.
Go back 20 years, and "GIF" means a 256-color losslessly compressed image, occasionally animated. Today, "GIF" nearly always means a short looping video with horrible compression.
Practically speaking, today, "GIF replacement" means doing a better job for short, looping videos, because that's all GIF has left at this point.
As long as Chrome/Webkit doesn't support APNG, there's no ubiquitous format that directly replaces GIF.
>Today, "GIF" nearly always means a short looping video with horrible compression.
To me, GIF means an image format. The fact that many people misuse the terminology doesn't mean we should propagate it. Instead, people should be educated on the difference between lossy video formats and image formats that support animation, and which is preferable for various sorts of media. Articles like the OP only confuse the issue further. As someone who has authored animation-editing software (Animstack script for GIMP), it's a major pain in the ass to explain these misconceptions to users. The least we can do is to use correct terminology, and educate people at every opportunity.
> As long as Chrome/Webkit doesn't support APNG, there's no ubiquitous format that directly replaces GIF.
That's a fun trick, to quote one sentence and disagree with it in a way that is already covered by the following sentence stating there is an exception.
I only quoted the sentence I was replying to. To assume I didn't read the rest of your message is, frankly, insulting. The exception you were talking about ("short looping video with horrible compression") is precisely the thing that both GIF and APNG aren't supposed to do well.
Both GIF and APNG support:
- palettes
- transparency
- different delay per frame
- combine/replace disposal mode per frame
Generic video formats don't generally support these.
Whether GIF was intended for this usecase or not (it wasn't, the GIF spec specifically calls it out as a bad idea [0]), it's overwhelmingly what it's used for in practice. Therefore anything that can displace GIF in this space is a replacement.
https://en.wikipedia.org/wiki/Better_Portable_Graphics#Paten...