Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

H.264 is Magic (2016)

sidbala.com

Post reply on HN
Print view View original

131–140 of 229 posts

Re: H.264 is Magic (2016)

#131

Post by verall »

mihaic wrote: post #119
planck01 wrote: post #112

Earlier quoted context omitted.

I think backing companies like Google and Netflix don't care about that. They need hardware decoding support in phones and TVs, and they will serve av1 from their platforms and save a lot of money. It might become the dominant codec without you even noticing it.

Sure, but I meant that hardware support is implemented if vendors are forced to support something -- such as user downloaded files. Netflix will serve both av1, h265 and h264, so my TV doesn't have to implement av1 support.

HW vendors have already/are implementing AV1 because they were on the big consortium and the industry is a bit more grown up now.

AV1 is a big compromise between a bunch of vendors. It is definitely the future, the powers that be have already decreed this, but these things move slowly.

Re: H.264 is Magic (2016)

#132

Post by mekster »

FrenchAmerican wrote: post #72
Cthulhu_ wrote: post #67

Earlier quoted context omitted.

"Your browser does not support JPEG XL"; I'm sure it's cool technology but whoever is behind it needs to hire developers and advocates to push code to Webkit / Blink to add support for it, else it won't get mainstream adoption.

I have read that both Chrome and Firefox now support it if one enable the proper option in the about:config page (and its Chrome equivalent, but I avoid Chrome by principle). It's in my to do-list in the coming weeks, I have not verified this yet.

So, once again Safari isn't on the list which hinders adoption.

I really wish it stop behaving like IE by being on its own.

Re: H.264 is Magic (2016)

#133

Post by verall »

thrdbndndn wrote: post #32
jstanley wrote: post #21

Does anything interesting happen if you take the frequency domain representation of an image, represent the frequency domain as an image itself, and compress that with some sort of image compression? For example, encode the frequency domain representation as a low quality JPEG, and then undo the steps to turn it back into the "original". How do the JPEG artifacts on the frequency domain manifest in the resulting imag…

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.

Re: H.264 is Magic (2016)

#134

Post by AceJohnny2 »

astrange wrote: post #124
AceJohnny2 wrote: post #91

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.

Wavelets were a great idea... except AFAIK we never figured out fast algorithms or hardware implementations to optimize processing them, the way we did with Fourier Transform and the FFT algorithm and IDCT blocks.

Re: H.264 is Magic (2016)

#135

Post by chrisshroba »

userbinator wrote: post #20

H.264 patents are not expiring yet, if anyone was wondering. 2027 seems to be when that happens. On the other hand, I believe H.263 patents already expired, and MPEG-4 ASP (DivX etc.) is expiring this year.

What does it mean for developers that it is patented?

Re: H.264 is Magic (2016)

#136

Post by [deleted] »

webmobdev wrote: post #118
Auracle wrote: post #99

Earlier quoted context omitted.

As a professional photographer I can’t believe we’ve been stuck with jpeg so long - 8 bits simply aren’t enough and lossy saving is a bummer. I’ll need both Capture One and Lightroom to support whatever gets decided on though, and that could take a while.

JPEG2000 is a good option for lossless compression. JPEG XL seems to offer better result and improvements now, but it isn't yet mainstream and has competition.

[deleted]

Re: H.264 is Magic (2016)

#137

Post by madars »

pornel wrote: post #64
aikinai wrote: post #11

Earlier quoted context omitted.

Isn’t that exactly what HEIC is?

HEIC is this plus a kitchen sink of features for digital camera rolls, which aren't useful on the web, all wrapped in a ton of legacy ISO BMFF complexity reaching as far as Classic Mac Quicktime. BPG structure is much more minimal and pragmatic. However, BPG is unnecessary nowadays. Modern browsers support AVIF, which is HEIF+AV1, so basically HEIC with the painfully patented bit swapped for a freely licensed one.

Really hopeful for AVIF but you can't use it on iOS https://caniuse.com/?search=avif :(

Re: H.264 is Magic (2016)

#138

Post by SideQuark »

ibigb wrote: post #126
Auracle wrote: post #99

Earlier quoted context omitted.

As a professional photographer I can’t believe we’ve been stuck with jpeg so long - 8 bits simply aren’t enough and lossy saving is a bummer. I’ll need both Capture One and Lightroom to support whatever gets decided on though, and that could take a while.

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 coefficients, perform an inverse 8x8 DCT top get pixel values.

The 11-bit dynamic range part you claim is merely from a color profile, which takes the resulting 8 bits per channel (i.e., 256 possible values) and spreads them over a gamma curve to an 11-bit range. But there are still only 256 possible levels per channel, too few for quality image editing.

Think of it as squaring: taking [0,255] as your input and squaring every value gives you a range of 0 to 255^2 = 65025, but that does not allow you to store any value in that range. It only allows you the 256 values that are squares.

So the dynamic range is 11 stops, but the number of representable levels per channel is still 8 bit: 256 levels. This makes gradients band no matter how you do them in JPEG.

It's why photo processing software wants RAW, not JPEG. JPEG, besides being lossy, does not allow enough steps.

One example: given a so-so RAW, at 11 bits, you can pull out dark things or darken bright things smoothly. This is not possible once you go to jpeg, for any implementation of jpeg.

Re: H.264 is Magic (2016)

#139

Post by acchow »

jancsika wrote: post #57

> 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…

Right, you of course also need the decoder in order to reconstruct the data.

In this case, the "decoder" is the english language.

Re: H.264 is Magic (2016)

#140

Post by acchow »

tzs wrote: post #115

Two questions for the compression gurus here. Suppose you have a bunch of raw video. You take extracts of it and put them together to make a movie, M1. You make an H.264 encoded copy of that. Let's call it C1. You then make a new cut of your movie, M2, which is mostly the same footage as M1 except that you've shortened a few scenes and lengthened others. You make an H.264 encoded copy of that. Call this C1. When maki…

> If they just do something simple like make every Nth frame an I-frame then after the first different between M1 and M2 it is unlikely that C1 and C2 will have many I-frames in common, and therefore also not have many P-frames in common.

Modern encoders won't be using a fixed rate for I-frames unless you force it to. It will choose an I-frame when deemed optimal.

You're correct in that using a compressed source which goes through a video editor and then to another encoder will likely not pass through to the encoder which of the frames to encode were originally I-frames in the source. This is because video editors combine multiple sources together so there is no "single" source.

But if you're not actually editing and you're just "trimming" and "joining", this can be done with perfectly matched i-Frames and p-Frames, but probably not b-frames?

Even when using the commandline x264, you can specify which frame numbers you'd like encoded as I-frames.

Post reply on HN