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

Adventures with ffmpeg and color ranges

facebook.com

Post reply on HN
Print view View original

81–90 of 94 posts

Re: Adventures with ffmpeg and color ranges

#81

Post by zbobet2012 »

zaroth wrote: post #7

> This is usually visible as ugly banding or blocking in dark scenes. I was just complaining about this a couple weeks ago with some friends after the “Dark” episode of GoT. I was saying the codecs don’t seem to have caught up or they are just being fed at too low a bit rate to really excel at dark scenes. It’s hard to imagine this is just a scaling issue with the color ranges, and if so, how could it possibly not ha…

A) Having a different color space is a violation of spec (H.264 profile's Baseline, Main, and High all define yuv420p). Don't expect your decoder to present these properly.

B) The issues you're seeing with background banding are _not_, primarily colorspace issues. While having a larger colorspace helps, these are largely related to the way quantization is done for the macro blocks in h.264.

The original h.264 spec (which is baseline and main profiles) only had a exponential quantization matrix.

During quantization we are "rounding" to the nearest integer for pixels. If we imagine each macroblock only had _one_ frequency coefficient. Dark scenes would have a low coefficient, say 1.4 If we round to 1 that's a 28.5% error in the rounding. A brighter scene which is at 9.4 has a rounding error of only 4.3%.

Custom quantization matrices and non linear quantization matrices(which are available in newer codecs) help deal with this.

Advanced h264 encoders have variance adaptive quantization technologies to help choose what level of quantization to apply to a block.

In short: h264 has technological limitations that are not caused by colorspace and the encoder doing this encode doesn't have strong AQ.

Re: Adventures with ffmpeg and color ranges

#82

Post by busterarm »

GuB-42 wrote: post #69
Quarrelsome wrote: post #61

I still find it kinda odd that this is still the best tool out there for this sort of work. Archaic parameters and options and exceptionally hard to read documentation. Maybe I'm just dumb and not in the domain enough to get a decent handle but everytime I use ffmpeg I feel like a Norse Shaman trying through trial and error to locate the correct orientation of runes for the blessing.

I wonder how Avisynth is doing now. In the early 2000s it was my tool of choice for video conversions. It used scripts, and it required external tools to do the encoding but despite the complexity, I found it less arcane than ffmpeg command lines for similar operations.

I've used both. AviSynth 2.6 is really long in the tooth (honestly it's kind of a disaster) and 3.0 never happened. AviSynth+ seems interesting, but I don't know anyone using it outside of piracy communities.

Once I got better at understanding FFmpeg's filters there really was no looking back.

Re: Adventures with ffmpeg and color ranges

#83

Post by klodolph »

dearrifling wrote: post #35

Fun fact: sRGB also has a non-black black point that is (fortunately) virtually ignored by everyone.

The sRGB black point just means that (0,0,0) is assumed to have a luminance of 0.2 cd/m^2, because your screen reflects ambient light and other factors.

Ignoring it will give you nonsensical values when you try to do conversions into other color spaces or when you try to do color comparisons.

Re: Adventures with ffmpeg and color ranges

#84

Post by klodolph »

devit wrote: post #66
dearrifling wrote: post #35

Fun fact: sRGB also has a non-black black point that is (fortunately) virtually ignored by everyone.

Source? As far as I can tell in XYZ black is (0,0,0) and the only sRGB value that maps to that is (0,0,0)

This is incorrect.

If sRGB (1,1,1) is XYZ (1,1,1), then sRGB (0,0,0) is XYZ (0.0025,0.0025,0.0025).

Or if you are using absolute XYZ values, sRGB (0,0,0) is XYZ (0.1901,0.2,0.2178).

Re: Adventures with ffmpeg and color ranges

#85

Post by roghummal »

tqi wrote: post #32
jakear wrote: post #27

Earlier quoted context omitted.

More that the company’s culture says you should post things using the company’s platform, and to not do so might be making a statement he doesn’t want to make. Otherwise, why would he move away from .plan?

Could it be that a lot of people don't know what a .plan file is, or how to read content from one?

If John Carmack started updating a .plan, people would figure out how to check a .plan.

Re: Adventures with ffmpeg and color ranges

#87

Post by zaroth »

stevenwoo wrote: post #38
zaroth wrote: post #7

> This is usually visible as ugly banding or blocking in dark scenes. I was just complaining about this a couple weeks ago with some friends after the “Dark” episode of GoT. I was saying the codecs don’t seem to have caught up or they are just being fed at too low a bit rate to really excel at dark scenes. It’s hard to imagine this is just a scaling issue with the color ranges, and if so, how could it possibly not ha…

The Amazon 720P version had noticeable banding several times during that episode that was distracting even the day after so it's probably not a bandwidth issue, the Dothraki charge into the dark might have been a cool idea on paper but what a disappointment in execution. I think the director and cinematographer are just ignorant of how stuff gets delivered to consumers. https://news.avclub.com/was-game-of-thrones-the…

From a tweet linked from that article:

https://pbs.twimg.com/media/D5SmDG7WwAAMhdf.jpg:large

I think that particular screenshot makes it look even worse than it was, but it was definitely sub-par. I assume that a hardcopy 4K Bluray would not exhibit the same effects?

Re: Adventures with ffmpeg and color ranges

#88

Post by thrwaycolor »

JohnCarmack wrote: post #73
m0dest wrote: post #53

For all of our sanity, please don't start producing 8-bit H.264 videos with full 0-255 range. If you have enough control over the decoder and renderer to make that hack work, you should just be producing 10-bit HEVC/AV1 video – which does not suffer from these 8-bit banding issues – with a modern color space (Rec 2020, PQ, etc.). And if you don't have choice or control over the decoder and renderer, then it's a good…

My primary concern is for immersive VR media on our Go and Quest platforms, which use Snapdragon 821 and 835 SoC, respectively. The 821 doesn’t support 10 bit on anything, and the 835 only supports it on h265. Software decoding a 4k60 video on mobile isn’t an option, and you can see every bit transition with dark adapted eyes in a vr headset, so getting full 8 bit range is pretty valuable.

You forget to mention which colorspace you're using. It matters.

From Rec. 2020 wikipedia article: Since a larger color space increases the difference between colors an increase of 1-bit per sample is needed for Rec. 2020 to equal or exceed the color precision of Rec. 709.

The "correct" solution is to use a modern colorspace (rec 2020) with 10 bits encoding (or 12 bits, if you can). UHD standard mandates at least 10 bits.

On the '821 you could gain 1 bit by degrading to an older color space - 709.

Full 0-255 range should never be used - they are invalid according to the standard. None of the hardware codecs are validated for 0-255 - you're asking for trouble here. Expect ghosting and weird motion artifacts accumulating from one I-frame to the next I-frame.

Re: Adventures with ffmpeg and color ranges

#89

Post by cloverich »

hiisukun wrote: post #41

Not sure if this kind of meta-comment is appropriate, but I find it difficult to follow a link like this because of the lack of human readable information contained in the URL. If the story was hosted on a personal blog I recognised (like Julia Evans to take a random example), then perhaps the domain would be enough for me to choose to read the article to see if the content is interesting. If the link was to a broade…

Stackoverflow solves this issue like so: stackoverflow.com/questions//, ex: https://stackoverflow.com/questions/56340579/i-could-not-set... Interestingly, you can change the slug and still end up on the same page, which just shows how simple a system it is. I'm sure there are trade offs but I always thought it was a clever idea (for its simplicity).

Re: Adventures with ffmpeg and color ranges

#90

Post by the-dude »

thrwaycolor wrote: post #88
JohnCarmack wrote: post #73

Earlier quoted context omitted.

My primary concern is for immersive VR media on our Go and Quest platforms, which use Snapdragon 821 and 835 SoC, respectively. The 821 doesn’t support 10 bit on anything, and the 835 only supports it on h265. Software decoding a 4k60 video on mobile isn’t an option, and you can see every bit transition with dark adapted eyes in a vr headset, so getting full 8 bit range is pretty valuable.

You forget to mention which colorspace you're using. It matters. From Rec. 2020 wikipedia article: Since a larger color space increases the difference between colors an increase of 1-bit per sample is needed for Rec. 2020 to equal or exceed the color precision of Rec. 709. The "correct" solution is to use a modern colorspace (rec 2020) with 10 bits encoding (or 12 bits, if you can). UHD standard mandates at least 10…

Are you sure about that? Logitech sells H264-encoding cameras which do yuvj420p ( which is full range as I understand it ).

YT and other platforms have no problem ingesting these videos. Also the RPi Broadcom chipset does not seem to care.

Post reply on HN