Live data from Hacker News

H.264 is Magic (2016)

sidbala.com

121–130 of 229 posts

Re: H.264 is Magic (2016)

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

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

Your new cut gets encoded from whatever you've chosen from frame-index numbers and timestamps in the various original raw yuv project files (or ProRes, etc, depending on what your camreas output).

The existence of the original cut should be irrelevent because what you're not doing is taking the compressed output product of C1 and re-cutting it into C2 unless for some catastrophic reason you have lost or deleted all of the original raw/uncompressed original camera files.

If you are generating new C2 from your original uncompressed (or lightly compressed) files, of course the encoder will be making new decisions on where to insert I-frames and P-frames based on the duration of each camera cut, changes you've made to CGI, other visual factors in the re-cutting.

> Suppose someone has an uncompressed source S. They compress it with a lossy compressor producing C and distribute C to you. You decompress C producing S'.

> You then compress S' with a lossy compressor (the same type that the original producer used--e.g.., if C is an MP3 you use an MP3 compressor) producing C'. I don't know about video, but for audio (at least back in days when MP3 was starting to get big) C' would be lower quality than C.

all of this is generally a bad idea unless you have no other option but to work with received files that are already compressed. say for example you're working on a documentary about something in a conflict zone and somebody sends you a highly compressed h264 file recorded on a smartphone. in this case there is no uncompressed original available.

you're going to want to first extract it into an uncompressed yuv raw file on disk so that you can work with it in your standard editor, and then whatever scenes you choose from within it will get re-encoded into your final output.

Re: H.264 is Magic (2016)

#122
post #109
post #49

PSA: 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/

Whatever happened to FLIF?

Got integrated into JPEG XL.

Re: H.264 is Magic (2016)

#123
post #15
post #6

Earlier quoted context omitted.

Well, if we're being pedantic here, raw RGB video as would be displayed on a RGB monitor does indeed take 3 bytes per pixel. Technically, YUV is either an optimization or a backwards compatibility measure, and hence the adjective "raw" does not apply to it.

Actually the "raw" data coming from most cameras are often already compressed somehow, otherwise the camera would not be able to write it to storage (or send it over USB) fast enough. In fact since decoding also often happens in hardware, the raw size may never materialize anywhere in the pipeline, other than the framebuffer of the video card. Even HDMI has compression now [0] The author probably choose a screenshot…

10 bit video 444 with 8294400 or 8847360 samples per picture for 4k (tv vs movie) tops out below 270mbit per frame, or at 60hz 16gbit, so you can fit half a dozen signals down a 100G transceiver, or two down a 40G.

Throw in YUV compression and you can shift 120hz 8k with relatively little problem.

Re: H.264 is Magic (2016)

#124
post #49

PSA: 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/

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.

Re: H.264 is Magic (2016)

#126
post #99
post #49

PSA: 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/

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.

Re: H.264 is Magic (2016)

#127

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?

Re: H.264 is Magic (2016)

#128
post #127

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?

It's been a long time. But I remember I started with this page [0]. There are also many resources on github, like [1] or [2], but I haven't tried them.

0: https://trac.ffmpeg.org/wiki/Debug/MacroblocksAndMotionVecto...

1: https://github.com/LukasBommes/mv-extractor

2: https://github.com/jishnujayakumar/MV-Tractus

Re: H.264 is Magic (2016)

#129
post #126
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.

Thanks for that info!

To save others from Googling, the Wikipedia page: https://en.wikipedia.org/wiki/JPEG

Re: H.264 is Magic (2016)

#130
post #49

PSA: 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/

What's fascinating to me as a web dev is that (unless I'm mistaken), if I store all my images as JPEG-XL, I won't need to create thumbnails or resized images anymore... I think I can literally just hold onto the originals and just truncate the image binary stream at whatever resolution is required.

I'm not sure how this would interact with "right-click to save image" though... what resolution would it be at that point?

Post reply on HN