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

191–200 of 229 posts

Re: H.264 is Magic (2016)

#191

Post by jeroenhd »

chrisshroba wrote: post #135
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?

IANAL, but as far as my understanding goes, it means that the algorithm is patented and therefore requires you to pay a license fee if you want to redistribute the code in a country where software patents are practically enforceable (like the USA).

In other parts of the world (like large parts of Europe, for example) software patents are practically unenforceable and you can probably distribute your code as you see fit. Code is still copyrightable, so you can't just redistribute someone else's library, but your own code does not violate their copyright.

Some greedy American companies will probably still sue you if you do, hoping to enforce their patents regardless or at least scare you into paying them, but at legally you _should_ be in the clear.

When it comes to dedicated hardware for an algorithm, though, like hardware accelerated video codecs, you'll likely run into patent trouble in most of the world if you choose to build your own hardware for a patented system.

Re: H.264 is Magic (2016)

#192

Post by motoboi »

xiphias2 wrote: post #177
goeiedaggoeie wrote: post #171

Earlier quoted context omitted.

having a hardware encoder and decoder on a device is super useful for streaming content of that device. Not sure I would want to use other compute for that, that compute is much better used doing CV on the video stream :)

Why do you think so? Those tensor processors are actually already optimized for video processing: all of the complex postprocessing in the iPhone camera app is done by the tensor cores inside the M1 chip. I wouldn't be suprised if it would already far be able outperform the mentioned codecs, but of course it needs lots of software development that can only be done by the big companies.

A codec it’s static, almost not changing at all over a decade. This allow you to implement it as a single purpose hardware which is orders of magnitude more efficient and fast than code running in a multipurpose chip, tensor or not.

For things that evolve fast, as deep learning, an programmable chip is the right choice.

Re: H.264 is Magic (2016)

#193

Post by ksec »

joshspankit wrote: post #41
ksec wrote: post #33

Earlier quoted context omitted.

I often wonder what we could do with a truly patent free codec once all the H.264 patent expired.

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 I cant record the reason any more it was just too long ago.

Re: H.264 is Magic (2016)

#194

Post by pabs3 »

remram wrote: post #189
brigade wrote: post #162

Earlier quoted context omitted.

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…

Do you mean that you would want that to happen on the web server, if they detect a user-agent that doesn't support JXL, they would convert back to JPEG? That seems pointlessly costly in CPU. Also like mkl said, there doesn't seem to be any evidence that JXL->JPEG can be done losslessly.

I tried it locally on my computer, JPEG -> JXL -> JPEG results in two bitwise identical JPEGs.

Re: H.264 is Magic (2016)

#195

Post by las_balas_tres »

knolan wrote: post #127
vagab0nd wrote: post #125

I worked on a project where I extracted the motion vectors from the h264 encoded stream from the camera, to detect motion. It's like a basic motion detector for free.

Can you provide a reference where one could get started with this?

There is a github project called pikrellcam that utilizes motion vectors generated from the raspberry pi's gpu to detect motion. It's a relatively simple piece of code and it works very well

Re: H.264 is Magic (2016)

#196

Post by yakubin »

emkoemko wrote: post #110
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.

try out darktable, its way more capable of a raw editor then those two and usually gets support for new export formats fairly fast.

It has poor support for input formats though. E.g. it still doesn't support CR3. I prefer RawTherapee which supports CR3, doesn't look like a space station and still is miles ahead of Lightroom in terms of capability.

Re: H.264 is Magic (2016)

#197

Post by AtNightWeCode »

ricardobeat wrote: post #169
AtNightWeCode wrote: post #164

I stopped reading when the author started to do comparisons with PNG. PNG or alternatives should only be used when the errors created by lossy compression is too visible. With that said. Improvements of audio and video compression over the last 25 years are very impressive and have changed how the world works in several areas.

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.

Re: H.264 is Magic (2016)

#199

Post by randyrand »

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

impressive how quickly you coded that up.

Re: H.264 is Magic (2016)

#200

Post by rasz »

remram wrote: post #189
brigade wrote: post #162

Earlier quoted context omitted.

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…

Do you mean that you would want that to happen on the web server, if they detect a user-agent that doesn't support JXL, they would convert back to JPEG? That seems pointlessly costly in CPU. Also like mkl said, there doesn't seem to be any evidence that JXL->JPEG can be done losslessly.

Dont know about web servers, but there are people doing it on the backup/storage side. https://dropbox.tech/infrastructure/lepton-image-compression...
Post reply on HN