181–190 of 229 posts
Earlier quoted context omitted.
With only a slight compression, the image would go shit or totally unrecognizable. A quick album (there are captions): https://imgur.com/a/7yHPzRH
> 4:2:0 chroma subsample the fft This is hilarious but I don't think it makes any sense.
I also tried 70% 444, still unrecognizable.
Earlier quoted context omitted.
What I think the AV1 initiative neglects as a way of spreading their tech would be giving away a great open implementation of an encoder. x265 and x264 spread their respective codecs all over the internet through pirated content, which forced adoption. The fact that you can play .mkv files almost anywhere now is a testament to that.
There's 3 that I know of, libaom https://aomedia.googlesource.com/aom , the reference implementation. https://gitlab.com/AOMediaCodec/SVT-AV1 - from the Alliance for Open Media, which Intel is deeply involved with and is spending a lot of time optimising. https://github.com/xiph/rav1e - written in rust, also subject to a lot of optimising. It's not complete coverage of all features, intended to be used for places whe…
The article starts off with talking about "raw" video containing 3 bytes for every pixel. However, most video is YUV, which is typically 1.5 bytes/pixel. https://en.wikipedia.org/wiki/YUV
YUV alone is still 3 bytes per pixel and can be converted back to rgb without any loss. But YUV is almost always combined with color subsampling, which gets you to 1.5 or 2 bytes per pixel.
Earlier quoted context omitted.
What does it mean for developers that it is patented?
You could write a complete from-scratch decoder, and be sued if you distribute it. This is the case with MPEG-2 formats used in DVD Video, and the reason that the VLC Media Player exists as a French student research project distributed as source code instead of a normal library. Related: https://www.gnu.org/philosophy/software-patents.en.html
Earlier quoted context omitted.
Yeah, in this era of mobile device dominance i think hardware decoding is key. Suspect Apple will add it then suddenly the Android SoC folks will suddenly consider it a priority and not before.
Apple won't add it; they traditionally ignore free codecs, and even if they implement them, it is so limited, so it is usable only in the narrow situation, where it is required (see Opus, for example). On the PC side, decoding is supported by Intel (since Tiger Lake), Nvidia (since 30x0) and AMD (since RDNA2). On the mobile side, it is supported by bunch of mobile chip vendors, like Mediatek or Samsung; so you can ha…
The article starts off with talking about "raw" video containing 3 bytes for every pixel. However, most video is YUV, which is typically 1.5 bytes/pixel. https://en.wikipedia.org/wiki/YUV
YUV alone is still 3 bytes per pixel and can be converted back to rgb without any loss. But YUV is almost always combined with color subsampling, which gets you to 1.5 or 2 bytes per pixel.
Earlier quoted context omitted.
There's 3 that I know of, libaom https://aomedia.googlesource.com/aom , the reference implementation. https://gitlab.com/AOMediaCodec/SVT-AV1 - from the Alliance for Open Media, which Intel is deeply involved with and is spending a lot of time optimising. https://github.com/xiph/rav1e - written in rust, also subject to a lot of optimising. It's not complete coverage of all features, intended to be used for places whe…
I have used x265 fairly easily to encode a 4K Bluray. None of the AV1 options seem to have the required performance (both quality and encoding speed) and ease of use.
Earlier quoted context omitted.
There's 3 that I know of, libaom https://aomedia.googlesource.com/aom , the reference implementation. https://gitlab.com/AOMediaCodec/SVT-AV1 - from the Alliance for Open Media, which Intel is deeply involved with and is spending a lot of time optimising. https://github.com/xiph/rav1e - written in rust, also subject to a lot of optimising. It's not complete coverage of all features, intended to be used for places whe…
I have used x265 fairly easily to encode a 4K Bluray. None of the AV1 options seem to have the required performance (both quality and encoding speed) and ease of use.
Earlier quoted context omitted.
I think you might have that backwards. JPEG can be losslessly converted to JPEG XL with better compression (~20% smaller), but I haven't seen anything about going the other direction. I'm not sure how it would be possible with JPEG XL's different sized blocks and different available transforms. https://en.wikipedia.org/wiki/JPEG_XL
The JPEG -> JXL conversion is reversible, so you can encode JPEG -> convert JXL -> convert back to JPEG as needed. You could potentially encode a JPEG-XL directly with the subset that can be converted back to JPEG, but it's not clear to me if libjxl currently implements that. Either way, it's not that useful for anyone that's already deploying post-JPEG formats; even WebP should save more than 20%. Mostly it's useful…
Also like mkl said, there doesn't seem to be any evidence that JXL->JPEG can be done losslessly.
> Suppose you have some strange coin - you've tossed it 10 times, and every time it lands on heads. How would you describe this information to someone? You wouldn't say HHHHHHHHH. You would just say "10 tosses, all heads" - bam! You've just compressed some data! Easy. I saved you hours of mindfuck lectures. This is obviously an oversimplification, but you've transformed some data into another shorter representation o…
It's curious because where do you draw the line between an algorithm that compresses information and an algorithm that just stores the inforamtion in the algorithm.
