Log in

View Full Version : Alliance for Open Media codecs


Pages : 1 2 3 4 5 6 7 [8] 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52

mzso
21st November 2017, 20:21
Possibly if you somehow manage to record the MPEG DASH video stream locally and play it afterwards; but that's the opposite of the intended use: Video streaming. Who knows whether the streaming or the player is the bottleneck here (but it is hosted on Akamai network servers...).

I can't know, that's why I wanted to download the video file. To exclude networking issues.

IgorC
21st November 2017, 20:22
1080p streams have the issue. 720p and below play all fine.

Quality is less than impressive (even for highest bitrate, 1080p@3 Mbps). A lot of blur. :scared:
Probably lately AV1 will be tuned visually.

wiak
22nd November 2017, 17:07
To me video hangs every few seconds for several seconds in FF Nightly. Any better way to view it?

Can I download it somehow? It might be that something glitchy with networking.
well thats one of the long time quirks of that decoder, i suspect they use the same decoder firefox used in a another older demo, what hw do u got?
i suspect its very single core depenant on decoding just like the current encoder

wait for the bitstream to freeze to check it out, thats when all the encoders and decoders align to decode the same file, atm the decoder cant decode another version of the encoder

mzso
22nd November 2017, 17:41
well thats one of the long time quirks of that decoder, i suspect they use the same decoder firefox used in a another older demo, what hw do u got?
i suspect its very single core depenant on decoding just like the current encoder

wait for the bitstream to freeze to check it out, thats when all the encoders and decoders align to decode the same file, atm the decoder cant decode another version of the encoder

I have a Ryzen 1600 right now.

wiak
22nd November 2017, 18:39
I have a Ryzen 1600 right now.
hello there, your zenpai here! i got a 1700X :)

Clare
25th November 2017, 17:45
hello there, your zenpai here! i got a 1700X :)

I'm looking to buy one too (or maybe wat for the Zen+ in February), what kind of fps do you get for AV1 or x265?

bstrobl
27th November 2017, 17:36
Streaming Tech Sweden AV1/HEVC comparison by Jan Ozer: https://www.youtube.com/watch?v=KzqOIddTNPQ

Hopefully the AV1 update by Jai Krishna will be uploaded soon. For those who are impatient, the slides are here: https://speakerdeck.com/stswe/av1-update-by-jai-krishnan-from-google

hajj_3
27th November 2017, 22:37
Streaming Tech Sweden AV1/HEVC comparison by Jan Ozer: https://www.youtube.com/watch?v=KzqOIddTNPQ

Hopefully the AV1 update by Jai Krishna will be uploaded soon. For those who are impatient, the slides are here: https://speakerdeck.com/stswe/av1-update-by-jai-krishnan-from-google

only ~25% better compression than vp9 so far. They were claiming 30% by bitstream freeze, lets hope they make it.

They have delayed the bitstream freeze to January now instead of end of year, not a big deal.

VincAlastor
29th November 2017, 21:06
https://demo.bitmovin.com/public/firefox/av1/

how can i grab this demo stream? I wanna analyse and test this stream outside of firefox.

sneaker_ger
29th November 2017, 21:12
youtube-dl (https://rg3.github.io/youtube-dl/) https://bitmovin-demos.commondatastorage.googleapis.com/mozillaAV1_Oct2017/e87fb2378f01103d5d6e477a4ef6892dc714e614_v1/stream.mpd

bstrobl
30th November 2017, 14:32
Mozilla Blog: https://hacks.mozilla.org/2017/11/dash-playback-of-av1-video/

mzso
30th November 2017, 22:53
Hmmm. It looks like they removed the 1080 videos from the demo page.

benwaggoner
1st December 2017, 18:46
Hopefully the AV1 update by Jai Krishna will be uploaded soon. For those who are impatient, the slides are here: https://speakerdeck.com/stswe/av1-update-by-jai-krishnan-from-google
It makes me somewhat nervous that the percentage gains go down the more subjectively correlated the metric used is.

-26.51% for VOD PSNR-Y but only -23.57% for MS-SSIM. And no metrics that include any temporal component. I'd love to see at least VMAF scores, which is the metric most predictive of DMOS that we have today.

The VPx series was always heavily tuned to optimize for PSNR, so its theoretical PSNR always overstated the series' actual perceptual quality. At least since VP6, which had a lot of advanced postprocessing technology that did a good job of hiding artifacts in a lot of ways.

IgorC
1st December 2017, 20:35
https://demo.bitmovin.com/public/firefox/av1/

how can i grab this demo stream? I wanna analyse and test this stream outside of firefox.

Hmmm. It looks like they removed the 1080 videos from the demo page.
Yep.

Also audio is Opus @ 32 kbps. Opus is the best available audio codec right now though 32 kbps is low.

Opus @ 48 kbps has much better quality which makes more sense for 720p streams (and 64-96+ kbps for 1080p)

VincAlastor
4th December 2017, 23:04
Yep.

Also audio is Opus @ 32 kbps. Opus is the best available audio codec right now though 32 kbps is low.

Opus @ 48 kbps has much better quality which makes more sense for 720p streams (and 64-96+ kbps for 1080p)

But it's amazing what audio quality is possible with 32 kbit/s! Thank you IgorC and all other opus audio developers! :)

I can't wait for upcoming opus 1.3 alpha/beta release!

bstrobl
5th December 2017, 16:41
It makes me somewhat nervous that the percentage gains go down the more subjectively correlated the metric used is.

-26.51% for VOD PSNR-Y but only -23.57% for MS-SSIM. And no metrics that include any temporal component. I'd love to see at least VMAF scores, which is the metric most predictive of DMOS that we have today.

The VPx series was always heavily tuned to optimize for PSNR, so its theoretical PSNR always overstated the series' actual perceptual quality. At least since VP6, which had a lot of advanced postprocessing technology that did a good job of hiding artifacts in a lot of ways.

I suppose the good news here is that AV1 has had no form of optimisation beyond the basic stuff done to it yet. Might be able to squeeze out a couple percent more with improved encoders. Right now encoding time is the biggest problem, especially for RTC.

benwaggoner
7th December 2017, 00:15
I suppose the good news here is that AV1 has had no form of optimisation beyond the basic stuff done to it yet. Might be able to squeeze out a couple percent more with improved encoders. Right now encoding time is the biggest problem, especially for RTC.
I'm sure there are massive potential gains that can be squeezed out by real-world encoders. Something like x264 and x265 can run rings around the reference encoders with real-world long form content using real-world parameters, and still be orders of magnitude faster.

It just takes a whole lot of development that's out of scope of defining a bitstream to get those gains. Codec development focused on PSNR @ Constant QP also runs the risk of over optimizing for a design where QP correlates highly with PSNR.

bstrobl
7th December 2017, 11:51
I'm sure there are massive potential gains that can be squeezed out by real-world encoders. Something like x264 and x265 can run rings around the reference encoders with real-world long form content using real-world parameters, and still be orders of magnitude faster.

It just takes a whole lot of development that's out of scope of defining a bitstream to get those gains. Codec development focused on PSNR @ Constant QP also runs the risk of over optimizing for a design where QP correlates highly with PSNR.

Doesn't HEVC do the same thing to an extend? Besides, the VP9 base will still be prominent in AV1 due to limited development time and the desire for reusability of components by chipset manufacturers.

The fact that AV1 does well when compared to x265 with a five year head start is neat, but I won't deny the fact that this was a somewhat rushed development.

My guess is most desirable features and improvements will only come with AV2, when the Alliance have most of the development kinks worked out.

iwod
10th December 2017, 13:52
Doesn't HEVC do the same thing to an extend? Besides, the VP9 base will still be prominent in AV1 due to limited development time and the desire for reusability of components by chipset manufacturers.

The fact that AV1 does well when compared to x265 with a five year head start is neat, but I won't deny the fact that this was a somewhat rushed development.

My guess is most desirable features and improvements will only come with AV2, when the Alliance have most of the development kinks worked out.

I am hoping for the best on AV2. But given how they have communicate, and expecting to have AV2 and AV3 done in next 5 years just shows they have absolutely no idea how real world progress and works.

Then there is the law of diminishing return, a lot of the improvement and progress made in x264 and x265 took years to fine tune. It wasn't long ago x264 was still beating x265 at high bitrate encoding.

mzso
10th December 2017, 15:26
I am hoping for the best on AV2. But given how they have communicate, and expecting to have AV2 and AV3 done in next 5 years just shows they have absolutely no idea how real world progress and works.
I don't have high hopes. They'll just probably keep tweaking the same basic concept (dct on blocks) as it's done for decades now.
Then there is the law of diminishing return, a lot of the improvement and progress made in x264 and x265 took years to fine tune. It wasn't long ago x264 was still beating x265 at high bitrate encoding.
That's why it would make sense to head to a radical new direction. But they won't.
I doubt that there'll be any interest in adopting AV2 if it ever gets finished. By then AV1 will be pretty well optimized and AV2 won't offer any improvement of particular significance.

bstrobl
11th December 2017, 17:56
That's why it would make sense to head to a radical new direction. But they won't.
I doubt that there'll be any interest in adopting AV2 if it ever gets finished. By then AV1 will be pretty well optimized and AV2 won't offer any improvement of particular significance.

Nothing wrong with DCT on blocks, worked well for a long time and still does ;).
It's a bit like squeezing out everything from current microprocessors and other modern technology, eventually you simply reach what is actually possible without going off into ridiculous complexity/cost. Daala is a good codec with a different design, but doesn't have a huge benefit over HEVC/AV1. Same with wavelets.

I doubt the Alliance will release a new codec if they can't make it at least 30% better than AV1. If there is no AV2, we will at least have a solid codec that is royalty free to depend on. Nothing wrong with a long lasting standard when you don't have to replace hardware/software and re-encode everything.

mzso
11th December 2017, 18:36
Nothing wrong with DCT on blocks, worked well for a long time and still does ;).
It's a bit like squeezing out everything from current microprocessors and other modern technology, eventually you simply reach what is actually possible without going off into ridiculous complexity/cost.

Yeah, it feels like most of the complexity of present codecs is spent on catering to blocks and deblocking.

Daala is a good codec with a different design, but doesn't have a huge benefit over HEVC/AV1. Same with wavelets.

I think alternative approaches are sorely under-researched. Not much effort was put into wavelets, even less into Daala's overlapped transformation before it was dopped.

benwaggoner
15th December 2017, 18:30
Yeah, it feels like most of the complexity of present codecs is spent on catering to blocks and deblocking.
Well, they ARE block-based codecs! New codecs are adding LOTS of knobs around block sizes and deblocking modes.


I think alternative approaches are sorely under-researched. Not much effort was put into wavelets, even less into Daala's overlapped transformation before it was dopped.
That is one of the challenges with any radically new technology. We have decades and millions of engineer-hours of experience optimizing around DCT-like block-based encoding. Even if a fundamentally new transform had a lot more potential, its initial implementations would have to compete against all the refinement of the current architectures. And it's very hard to estimate how well a basic technology will pan out. Wavelet-based video codecs were "obviously" the future, until actual real-world implementations went splat.

If we started with J2K instead of JPEG, and had all the motion estimation work done based around wavelets, hundreds of PhDs and developers could have found the magic way. And then someone with a crazy block-based codec idea would have run out of funding at just full-pel motion search, and we'd say "yeah, blocks were kind of interesting, but just never proved to be competitive."

bstrobl
19th December 2017, 09:55
Took a while but here is the Google update on AV1:

https://www.youtube.com/watch?v=sBAHBZsh4AA&list=PLpv8XV4Px3qKVWXj3rzJHP8y8-Qaqcvb0&index=7

hajj_3
19th December 2017, 11:23
Took a while but here is the Google update on AV1:

https://www.youtube.com/watch?v=sBAHBZsh4AA&list=PLpv8XV4Px3qKVWXj3rzJHP8y8-Qaqcvb0&index=7

The video says that they are currently up to 29% improvement over VP9 and aim to be at ~35% by the bitfreeze in January. That is a welcomed improvement as they say a month or so ago that they were aiming for 30% improvement.

hajj_3
4th January 2018, 22:19
Hell has frozen over...... Apple has quietly joined AOM as a founding member: https://www.cnet.com/news/apple-online-video-compression-av1/

nevcairiel
4th January 2018, 22:30
How can you join as a "founding member" this late?

hajj_3
4th January 2018, 23:17
How can you join as a "founding member" this late?

I presume founding members pay more money and probably have more voting rights. AOM obviously wanted Apple to join badly as having a single codec for all future smartphones and tablets would be extremely beneficial for everyone.

GTPVHD
5th January 2018, 01:57
That's unexpected but welcome news, I'm guessing Apple will have Axx SoCs with fixed function AV1 hardware decoding in the future.

And yes, Hell has frozen over.

x265_Project
5th January 2018, 03:43
That's unexpected but welcome news, I'm guessing Apple will have Axx SoCs with fixed function AV1 hardware decoding in the future.

That's not a safe assumption. Supporting a standards organization and adopting the standard in your own products and services are two separate decisions. Companies may have many different motivations for the first decision. But it's low risk. They only make the second, much more expensive decision based on a careful cost/benefit analysis for each product line (or in Apple's case, for each platform). It took Apple 4 1/2 years from the time HEVC was standardized until it announced broad support for HEVC (and AV1 is not yet finalized, as far as I know). Apple joining the Alliance for Open Media may actually end up helping HEVC adoption, as AV1 (or the threat of a major platform owner like Apple actually adopting AV1) provides a strong counter-balancing force to convince HEVC patent holders to avoid unreasonable patent license demands. HEVC doesn't need to be free to all implementers to succeed, but it definitely needs to be reasonable, and the work of the Alliance for Open Media is very helpful to the overall cause of enabling advanced encoding standards at reasonable costs. Only time will tell how it all plays out.

iwod
5th January 2018, 11:48
There is NetVC, which aims to be a royalty free Video Codec for the Internet, and AV1 is the front runner ( or the only contender ) for it.

Apple may very well only support AV1 in Safari only, much like opus on their platform.

Since Apple already have cross licensing with all the HEVC patents holder, any video patents against AV1 is highly unlikely to be a threat to them. And like @x265_Project have said, this is a move to tell the HEVC patents holder, loosen up or get out of the way.

GTPVHD
6th January 2018, 16:27
http://www.streamingmedia.com/Articles/News/Online-Video-News/Apple-Joins-Alliance-for-Open-Media-What-Does-it-Mean-122476.aspx

iwod
7th January 2018, 13:08
http://www.streamingmedia.com/Articles/News/Online-Video-News/Apple-Joins-Alliance-for-Open-Media-What-Does-it-Mean-122476.aspx

Apart from Desktop Web, I dont see any devices that has or would only have AV1 hardware decode support and not HEVC decode support. So the argument for Apple needing AV1 because they are trying to compete with Netflix in the future is moot.

It could be Netflix and Youtube decided against HEVC, which means Apple will need to add AV1 out of necessity. I hardly doubt Apple will budge if it was only Youtube.

While the article said it was being doubtful, I actually think Apple wants its opinion and steering on AV2 a very possible reason.

My guess is that there will be more news leaking out in CES.

bstrobl
7th January 2018, 14:43
It took Apple 4 1/2 years from the time HEVC was standardized until it announced broad support for HEVC (and AV1 is not yet finalized, as far as I know). Apple joining the Alliance for Open Media may actually end up helping HEVC adoption, as AV1 (or the threat of a major platform owner like Apple actually adopting AV1) provides a strong counter-balancing force to convince HEVC patent holders to avoid unreasonable patent license demands. HEVC doesn't need to be free to all implementers to succeed, but it definitely needs to be reasonable, and the work of the Alliance for Open Media is very helpful to the overall cause of enabling advanced encoding standards at reasonable costs. Only time will tell how it all plays out.

Apple already had HEVC in the A8, only to rip it out a short time later. Even the threat of VP9 has only barely provoked licensors into giving slightly better terms.

I think Apple has noticed where the wind is blowing and is also fed up with the other patent groups, having adopted OPUS in High Sierra and iOS 11.

HEVC is done, hope you don't mind creating an xAV1 :)

Blue_MiSfit
8th January 2018, 20:00
HEVC is scarcely "done".

It's in production and working extremely well in UHD BluRay, UHD linear TV, and 4K OTT streaming services. It's also enabling great consumer experiences like HDR.

Even if AV1 was done today, there'd be years of runway for broad availability of hardware decoders, and performant, well tuned encoders.

I think we'll all be living with HEVC for several years, at least!

hajj_3
8th January 2018, 21:42
HEVC is scarcely "done".

It's in production and working extremely well in UHD BluRay, UHD linear TV, and 4K OTT streaming services. It's also enabling great consumer experiences like HDR.

Even if AV1 was done today, there'd be years of runway for broad availability of hardware decoders, and performant, well tuned encoders.

I think we'll all be living with HEVC for several years, at least!

Hardware decoders will take 12-18 months to make and a small number of months for products to ship with the new chips. YouTube and Netflix will be encoding videos with AV1 within days of it being finalised. A large portion of youtube viewers use a pc which can software decode av1. Sure it will take a while for av1 to become mainstream but we will still be using it quickly. I hope that my new $40 android box that has a quad core 1.5ghz cortex a53 is powerful enough to software decode 1080p AV1.

mzso
9th January 2018, 13:11
HEVC is scarcely "done".

It's in production and working extremely well in UHD BluRay, UHD linear TV, and 4K OTT streaming services. It's also enabling great consumer experiences like HDR.

Even if AV1 was done today, there'd be years of runway for broad availability of hardware decoders, and performant, well tuned encoders.

I think we'll all be living with HEVC for several years, at least!

We're not even living with HEVC now. It's scarcely used. Websites use VP9 or AVC, home media is encoded in AVC.

I only came in contact with HEVC files via samples and files encoded for filesharing (and it's scarce even here).

sneaker_ger
9th January 2018, 13:27
It's often used for 4K. E.g. Netflix, Amazon, Blu-ray, DVB. Also some non-4K broadcasting, e.g. DVB-T2 in Germany is exclusively HEVC (1080p50 max).

And it seems no one is creating VP9. E.g. if you buy a camcorder it will record AVC or HEVC, not VP9. No live VP9 broadcasting. Could end up the same with AV1, i.e. we will consume it via Youtube and Netflix (non-live encoding in big server farms) but in other areas HEVC will be the leader.

We'll see ...

hajj_3
9th January 2018, 13:32
We're not even living with HEVC now. It's scarcely used. Websites use VP9 or AVC, home media is encoded in AVC.

I only came in contact with HEVC files via samples and files encoded for filesharing (and it's scarce even here).

yep, it has been a commercial flop so far. Apple's recent addition is the only major support they have had recently. A small number of tv broadcasters use it, uhd bluray and 4k streaming services but that is about it. hardly any torrents use it and those that do use a bitrate ridiculously low that it looks far worse. Unless a single patent group is formed with lower licensing costs and a cap for costs it is never going to become even vaguely as popular as h264.



And it seems no one is creating VP9. E.g. if you buy a camcorder it will record AVC or HEVC, not VP9.

hardly any camcorders, point and shoot cameras or dslr's support hevc. Those are areas that should have adopted it years ago but still haven't.

Motenai Yoda
9th January 2018, 14:15
yep, it has been a commercial flop so far. Apple's recent addition is the only major support they have had recently.
Yep, unless you count that almost all smartphones, smart tvs (especially those with uhd and hdr support), gpus, intel cpus, single board computers, tvboxes and uhd bluray players of those last 2 years can natively decode and/or encode hevc videos (apple is only a little last addiction on a large and consolidated panorama)
All streaming services as netflix, prime video, google film, itunes, youtube etc. uses hevc beside vp9 for 4k content.
All broadcasters need to use hevc on dvb-t2 trasmissions.
All UHD BD are encoded in hevc.

yep a very large "flop"

hajj_3
9th January 2018, 15:15
Yep, unless you count that almost all smartphones, smart tvs (especially those with uhd and hdr support), gpus, intel cpus, single board computers, tvboxes and uhd bluray players of those last 2 years can natively decode and/or encode hevc videos (apple is only a little last addiction on a large and consolidated panorama)
All streaming services as netflix, prime video, google film, itunes, youtube etc. uses hevc beside vp9 for 4k content.
All broadcasters need to use hevc on dvb-t2 trasmissions.
All UHD BD are encoded in hevc.

yep a very large "flop"

This post is filled with nonsense:

1. broadcasters are not require to use hevc with dvb-t2, the uk uses h264+he-aac audio on dvb-t2.
2. youtube does not encode any videos in hevc.
3. tv's and smartphones may have hevc decoders but hardly any phones record videos in hevc and hardly any tv's receive broadcasts in hevc. Saying that because there are hardware decoders in lots of devices doesn't make it a success. Lots of devices have vp8 hardware decoders but that isn't a successful codec either.

dapperdan
17th January 2018, 11:04
Apart from Desktop Web, I dont see any devices that has or would only have AV1 hardware decode support and not HEVC decode support. So the argument for Apple needing AV1 because they are trying to compete with Netflix in the future is moot.


I could imagine this applying to the next generation of Chromecast devices from Google.

I wonder if those video dongle's will lower hardware prices to the point where just shipping with free codec support would be a viable differentiation move for companies without a dog in the fight. Probably comes down to which content providers they consider essential and what those content providers in turn choose to do.

GTPVHD
22nd January 2018, 20:05
https://www.cnet.com/news/google-mozilla-av1-photo-format-could-outdo-aging-jpeg/

mzso
22nd January 2018, 21:58
https://www.cnet.com/news/google-mozilla-av1-photo-format-could-outdo-aging-jpeg/

Finally some promising news on this. I started to think that everyone in the alliance is too dumb to think of a brand new still image format.

LigH
22nd January 2018, 22:13
Imagine, I once found a website which specialized in offering images in WebP format and was not just a format promoting site.

One.

User acceptance is hard to predict. If it doesn't offer more important advantages than just bandwidth saving (in times of VDSL and 4G), there may not be much incentive to use it. Just remember the overhead of external JavaScript modules required to keep your own source small.

http://frupic.frubar.net/thumbs/36347.png (http://frupic.frubar.net/shots/36347.jpg)

HerpaDerp
23rd January 2018, 08:38
Imagine, I once found a website which specialized in offering images in WebP format and was not just a format promoting site.

One.

User acceptance is hard to predict. If it doesn't offer more important advantages than just bandwidth saving (in times of VDSL and 4G), there may not be much incentive to use it. Just remember the overhead of external JavaScript modules required to keep your own source small.

http://frupic.frubar.net/thumbs/36347.png (http://frupic.frubar.net/shots/36347.jpg)

I've been improving a website for a customer off/on for the past year. One of the goals was to create product pages that showed high resolution, high quality images with alpha transparency overlayed on top of a fixed background image, so that it makes the product "pop" and look impressive when the user scrolls down the page.

I quickly ran into a roadblock where, JPEG wouldn't work because it doesn't support alpha transparency. GIF will get you close, but it's either fully opaque, or fully transparent. PNG in my instance resulted anywhere from 800KB to 1.5MB per image, and with some pages containing 20+ images, you can see how this would be a problem for mobile users.

So, my solution was to provide WebP to Chrome users on both Desktop and Android, and provide a fallback of Quantized (Lossy) PNG for Firefox, Edge, Internet Explorer, and basically any browser that doesn't support WebP.

This resulted in a massive bandwidth reduction for the user, which caused the page to load 10-15 seconds faster on 4G.

Now, you mentioned you once found a website that specialized in offering images in WebP, and I can name a big one right off the top of my head: Netflix. They in fact, provide WebP to Chrome users.

Facebook at one point dabbled with WebP, but due to the nature of users wanting to download pictures, I think they ended up upsetting people more than making them happy, since WebP is a bad format to serve to people wanting to make local backups of their files.

Now, WebP is really not the best format, but it solved a big problem for me on Chrome, especially since it captures more than 60% of the total browser marketshare. I'm not making that number up.

A big problem with WebP is that it suffers from generation loss, and for certain situations, it can produce a significantly worse looking image than JPEG, which is why it's paramount that you don't choose a quality lower than 80%.

I looked into FLIF image format, which as of right now, is supported by absolutely nobody. It's some new fangled format that shunts the most important bits to the the beginning of the image so that if you downloaded a mere 10KB of a 2MB image, you could still view a low resolution version of it, which quite frankly is awesome.

The see several immediate problems with FLIF.
1. Files take a horrendous amount of time to create if they're greater than 2048x2048px in dimensions because it's doing all sorts of color sorting and algorithms to achieve the best filesize. Time to create the file increases exponentially with dimension. We're talking 5+ minutes to create a 4096x4096 FLIF image. Also, I have been unsuccessful in creating 16bit FLIF files, but that could just be a limitation of XNViewMP. Not sure.

2. It doesn't actually solve filesize problem for mobile users. Hypothetically speaking, if you put 30 FLIF files on your web page, each of which amounts to 2MB in file size, then you're forcing the user to download 60MB of pictures. The only benefit they get is the ability to view the image before they've finished downloading, but this just simply inflates the filesize of the page enormously, and causes other files to queue during the page load time. At the end of the day, serving your users smaller images ( less than 1MB in filesize) is the absolute best way to achieve fast page load time.

3. Animated FLIF is fantastic if you have less than 30 second recordings, but if you go beyond that, it quickly becomes impractical because the user would still have to download a mega amount of data just to be able to begin displaying the image. So, at the end of the day, you're still far better off using a video codec for anything exceeding 30 seconds.... and we now have an absolute wealth of services that do exactly that (imgur, gfycat, etc). Animated FLIF is a neat proof of concept, but I see almost no practical use for it other than being able embed fast previewing short animated images into a product page... which tbh, I would probably be the one in 100,000 website developers taking advantage of that feature. lol... Right now, my current method of doing animated video is to overlay a VP9 WebM for Firefox and Chrome users, and then fallback to animated GIF for Edge / IE users. What a pain the neck, but hey it works.

4. A 30KB partial download of a FLIF looks SIGNIFICANTLY worse than WebP, Jpeg, BPG, or any new fangled image format that is saved at the exact same filesize. FLIF is fantastic looking once the full data has been received, but looks quite terrible for partial downloads if you're comparing them to already existing image formats saved at the exact same filesize.

5. If web browsers ever become intelligent enough to download "only" the bits needed for optimal viewing experience, what we will end up with, is a bunch of partial downloads sitting in our browser cache, which means if user resizes their web browser, or zooms the image, then the browser will have to request the additional data from the webserver, which means, you can end up having multiple requests for the same image... and web servers operators HATE multiple requests. They would rather you get the full file the first time, than to bog down their servers with multiple requests for the same file.

I could go on and on and on.

But what we need, is not FLIF. We need an alternative image format, that reduces file size, has features, does not suffer from generation loss, is fast to create files, and in every way shape or form, replaces JPEG and PNG. FLIF does not replace JPEG and PNG. It's great, but it doesn't resolve the 5 issues I mentioned above.

And unfortunately, AV1 probably has TERRIBLE generation loss because using similar tech as WebP, and I can almost guarantee, it will suffer from the same problems. Nevertheless, if an AV1 image format became available to use in Chrome, I would switch to it simply because I like better things.

Anyway, just thought I'd like to share. lol

Jamaika
23rd January 2018, 14:42
I quickly ran into a roadblock where, JPEG wouldn't work because it doesn't support alpha transparency.
We are talking about the JPEG standard. What about the other native JPEG development?
JPEG2000, JPEGLS or JPEGXT. Amateur production or codes will have any application.
Now, WebP is really not the best format, but it solved a big problem for me on Chrome, especially since it captures more than 60% of the total browser marketshare. I'm not making that number up.
A big problem with WebP is that it suffers from generation loss, and for certain situations, it can produce a significantly worse looking image than JPEG, which is why it's paramount that you don't choose a quality lower than 80%.
Google develops a WebP but without the VP9 codec. I don't know what creators have vision Lepton. Codec bases on WebP and JPEG. I think that you made a mistake codecs. WebP isn't 16bit, and 16bit is FIiF. Unfortunately, it works even more slowly.

HerpaDerp
23rd January 2018, 16:05
We are talking about the JPEG standard. What about the other native JPEG development?
JPEG2000, JPEGLS or JPEGXT. Amateur production or codes will have any application.

https://caniuse.com/#search=jpeg

Google develops a WebP but without the VP9 codec. I don't know what creators have vision Lepton. Codec bases on WebP and JPEG. I think that you made a mistake codecs. WebP isn't 16bit, and 16bit is FIiF. Unfortunately, it works even more slowly.

:confused:

benwaggoner
24th January 2018, 20:27
The only real viable replacement for GIF/PNG/JPEG I see now is HEIF, which is now the default picture format for iOS. The implementation today is HEVC, but extending it to AV1 appears reasonably straightforward.

I have no idea how HEVC and AV1 would compare for still image coding, but both are WAY better than JPEG or PNG for any kind of image type. And unbelievably better for mixed continuous/discreet tone images like graphics or comic books.

hajj_3
24th January 2018, 20:53
The only real viable replacement for GIF/PNG/JPEG I see now is HEIF, which is now the default picture format for iOS. The implementation today is HEVC, but extending it to AV1 appears reasonably straightforward.

I have no idea how HEVC and AV1 would compare for still image coding, but both are WAY better than JPEG or PNG for any kind of image type. And unbelievably better for mixed continuous/discreet tone images like graphics or comic books.

isn't heif patented though? I can't see mozilla adopting a patented format nor many phone manufacturers. AV1 is 15% better than hevc at still images according to recent statements. Google's PIK is another contender.