Earlier quoted context omitted.
Did they avoid the prohibitive licensing that left JPEG 2000 dead in the water?
JPEG2000 wasn't technically better enough; wavelets are too blurry and less efficient to decode. For some reason there was an epidemic of terrible codec designs for a decade or two, though it could've all been patent avoidance.
H.264 is Magic (2016)
201–210 of 229 posts
Re: H.264 is Magic (2016)
#202Earlier quoted context omitted.
PNG is a good baseline for image sizes before adding any kind of smart compression. Nothing wrong with that, and the comparison would not look much different against JPG (except it would probably look actually worse than the video).
There is no reason to use PNG today except for cases were image size does not matter.
Regardless, it’s useful as a comparison in the article to show just how good h264 is versus other compression techniques. They are not recommending PNG or anything. WebP would only produce a 20-50% smaller file, not 1000x smaller, so it doesn’t really matter which image format they compare to.
Re: H.264 is Magic (2016)
#203Earlier quoted context omitted.
The Broadcasting industry has definitely sided with VVC. So 8K broadcast will likely be using VVC along with possibly LCEVC [1] as announced by the Brazilian SBTVD standard. The AV1 question is harder to answer. One could argue VP9 is good enough and a few more years before it reach 100% VP9 hardware decoding on Smartphone. Of course Google could force the usage of AV1 in the future if they slowly phaseout VP9 video…
> Even to this day I still do not believe Apple will support AV1 decode, at least not until Google forced the AV1 usage. Even though they joined AOM four years ago: * https://venturebeat.com/2018/01/04/3-reasons-apple-just-join... * https://appleinsider.com/articles/18/01/04/apple-joins-allia... * https://bitmovin.com/apple-joins-av1-codec-consortium/ * https://www.streamingmedia.com/Articles/ReadArticle.aspx?Art...
Re: H.264 is Magic (2016)
#204For those interested in this topic, I highly recommend the approachable but more extensive technical introduction at https://github.com/leandromoreira/digital_video_introduction
Re: H.264 is Magic (2016)
#205PSA: For images, there's a finally successor to jpeg: JPEG XL (.jxl) - has lossy and lossless mode; is progressive (you can download just the first parts of the bitstream to get a lower resolution image; and other benefits!) https://jpegxl.info/
JPEG similarly has a progressive mode. The problem with these formats is that they don’t offer enough of an advantage to overcome the disadvantage of have less than the enormous install base of JPEG. Look how much better PNG is than GIF and realize it only succeeded in replacing it (for static images) because of the Unisys patent suits, not because it’s so much better.
GIF being limited to 8bpp would have meant that it would have been replaced eventually anyway.
Re: H.264 is Magic (2016)
#206Earlier quoted context omitted.
You don’t have to wonder: There have been many truly patent free codecs and the answer is mostly “Try to convince companies to adopt it even though they have a vested interest in using codecs they control” For example: FLAC
FLAC is actually much more widely supported than, for example, Vorbis.
Re: H.264 is Magic (2016)
#207Earlier quoted context omitted.
You don’t have to wonder: There have been many truly patent free codecs and the answer is mostly “Try to convince companies to adopt it even though they have a vested interest in using codecs they control” For example: FLAC
The problem was FLAC wasn't patent free but claims to be not covered by any patent. That is quite a bit of difference from a legal perspective. One could argue about patent system and its usage, but most companies ( ignoring Tech and Internet companies ) tend to avoid them. Especially when there are alternative. And consumer tends to just use whatever they want. I remember I picked Wavepack over FLAC in that era. But…
What is that difference? It's not like you can proove that anything is not covered by any patent without being sued by every patent holder and winning.
Re: H.264 is Magic (2016)
#208Earlier quoted context omitted.
The problem was FLAC wasn't patent free but claims to be not covered by any patent. That is quite a bit of difference from a legal perspective. One could argue about patent system and its usage, but most companies ( ignoring Tech and Internet companies ) tend to avoid them. Especially when there are alternative. And consumer tends to just use whatever they want. I remember I picked Wavepack over FLAC in that era. But…
> The problem was FLAC wasn't patent free but claims to be not covered by any patent. That is quite a bit of difference from a legal perspective. What is that difference? It's not like you can proove that anything is not covered by any patent without being sued by every patent holder and winning.
When you have a codec that have all patent expired after 20 years. That is guaranteed patent free, because you can no longer extract patent from it. Claiming you dont have any patent just means you think it is not covered by any patents until proven.
Re: H.264 is Magic (2016)
#209Is there as a (good) college-level text book on the topic of image and video encoders? I never took a digital image processing course .. curious if someone has a favorite book on this topic.
Would highly recommend it! We went over pretty much everything in this article, plus more :)
Re: H.264 is Magic (2016)
#210Earlier quoted context omitted.
A jpeg pixel is 64 (=8 x 8), 8 bit coefficients which are summed together for each pixel. That result is not 8 bits, but more; that is a misunderstanding, often repeated. A jpeg is capable of over 11 bits dynamic range. You can figure out that an 11 bit dynamic range image has more than 8 bits. See the wikipedia.
A jpeg pixel is not 64 eight-bit coefficients. Jpeg compresses an 8x8 pixel block at a time by taking a DCT (which mathematically is lossless, but in practice is not due to rounding and quantization at this stage), which turns those original 8x8 values into another set of 8x8 values, then some of these are thrown away and/or quantized for lossy compression. Decompression is the reverse: take these 8x8 quantized DCT c…
The cosine values are transcendental numbers, they can have an infinite number of decimal places, yes? So adding up 64 products of (cosine values * 8 bit integer) to get 1 pixel value can obviously have more than 8 bits.