Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
5th January 2018, 11:48 | #381 | Link |
Registered User
Join Date: Apr 2002
Posts: 756
|
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. |
7th January 2018, 13:08 | #383 | Link | |
Registered User
Join Date: Apr 2002
Posts: 756
|
Quote:
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. |
|
7th January 2018, 14:43 | #384 | Link | |
Registered User
Join Date: Jun 2016
Posts: 55
|
Quote:
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 |
|
8th January 2018, 20:00 | #385 | Link |
Derek Prestegard IRL
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,989
|
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! |
8th January 2018, 21:42 | #386 | Link | |
Registered User
Join Date: Mar 2004
Posts: 1,126
|
Quote:
|
|
9th January 2018, 13:11 | #387 | Link | |
Registered User
Join Date: Oct 2009
Posts: 930
|
Quote:
I only came in contact with HEVC files via samples and files encoded for filesharing (and it's scarce even here). |
|
9th January 2018, 13:27 | #388 | Link |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
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 ... |
9th January 2018, 13:32 | #389 | Link | |
Registered User
Join Date: Mar 2004
Posts: 1,126
|
Quote:
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. Last edited by hajj_3; 9th January 2018 at 13:34. |
|
9th January 2018, 14:15 | #390 | Link | |
Registered User
Join Date: Jan 2010
Posts: 709
|
Quote:
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"
__________________
powered by Google Translator |
|
9th January 2018, 15:15 | #391 | Link | |
Registered User
Join Date: Mar 2004
Posts: 1,126
|
Quote:
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. |
|
17th January 2018, 11:04 | #392 | Link | |
Registered User
Join Date: Aug 2009
Posts: 201
|
Quote:
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. Last edited by dapperdan; 17th January 2018 at 11:24. |
|
22nd January 2018, 22:13 | #395 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,782
|
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. |
23rd January 2018, 08:38 | #396 | Link |
Registered User
Join Date: Apr 2011
Posts: 13
|
Quote:
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 Last edited by HerpaDerp; 23rd January 2018 at 08:45. |
23rd January 2018, 14:42 | #397 | Link | ||
Registered User
Join Date: Jul 2015
Posts: 706
|
Quote:
JPEG2000, JPEGLS or JPEGXT. Amateur production or codes will have any application. Quote:
Last edited by Jamaika; 23rd January 2018 at 14:50. |
||
23rd January 2018, 16:05 | #398 | Link | ||
Registered User
Join Date: Apr 2011
Posts: 13
|
Quote:
Quote:
|
||
24th January 2018, 20:27 | #399 | Link |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
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. |
24th January 2018, 20:53 | #400 | Link | |
Registered User
Join Date: Mar 2004
Posts: 1,126
|
Quote:
|
|
|
|