Questions about Hi10p.

[James Freeman]

What is the original content bit depth that being compressed to Hi10p.

Is there commercial video content (anime included) in 10-bit before compression?

Whats the point compressing to 10-bit, if the original video is a less than 10-bit, besides file size?

Isn't it better to let output renderer like MadVR dither UP the original bit depth instead dithering DOWN?

[sneaker_ger]

Whats the point compressing to 10-bit, if the original video is a less than 10-bit, besides file size?
File size/quality is the only reason.

http://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf

Isn't it better to let output renderer like MadVR dither UP the original bit depth instead dithering DOWN?
If you don't use 10 Bit encoding you don't profit from the lower bitrate needs. Your player/madVR doesn't reduce the file size, obviously.

[LoRd_MuldeR]

What is the original content bit depth that being compressed to Hi10p.

Whatever you feed into the encoder ;)

Is there commercial video content (anime included) in 10-bit before compression?

Whats the point compressing to 10-bit, if the original video is a less than 10-bit, besides file size?

"10-Bit" in 10-Bit H.274 is neither the bit-depth of the input video you feed into the encoder nor is it the bit-depth of the video that will be put out by the decoder.

Instead, it is the internal precision of all data processed by the H.264 encoder/decoder pipeline. This higher precision results in less rounding errors and thus gives better compression ratio.

This applies even if you feed the encoder with 8-Bit input and let the decoder output 8-Bit again. The encoder's internal precision is mostly independent from the input/output bit-depth.

Isn't it better to let output renderer like MadVR dither UP the original bit depth instead dithering DOWN?

I don't quite understand this question :confused:

When converting from a higher bit-depth to a lower one, then not all original values can be represented in the new (lower) bit-depth, obviously, so quantization needs to be applied. Dithering can be used to "distribute" the quantization error and thus avoid visual artifacts, such as banding effects. But when converting from a lower to a higher bit-depth, this is not required/possible - because the input can be represented 1:1 in the new (higher) bit-depth.

Anyway, in case of video renderers, we are mainly concerned with YCbCr to RGB conversions. That's because video is almost always stored in YCbCr format, while the screen output requires RGB format. During the YCbCr to RGB conversions, dithering may be applied when converting/quantizing the "intermediate" (floating point) RGB values to the final integer values, which are finally sent to the screen.

Furthermore, even if you had "true" 10-Bit footage, the video renderer still has to convert/dither the 10-Bit YCbCr video to 8-Bit RGB values for screen output - because "normal" screens and graphics cards are limited to 8-Bit precision.

[nevcairiel]

"10-Bit" in 10-Bit H.274 is neither the bit-depth of the input video you feed into the encoder nor is it the bit-depth of the video that will be put out by the decoder.

Instead, it is the internal precision of all data processed by the H.264 encoder/decoder pipeline. This higher precision results in less rounding errors and thus gives better compression ratio.

This applies even if you feed the encoder with 8-Bit input and let the decoder output 8-Bit again. The encoder's internal precision is mostly independent from the input/output bit-depth.

Eh, a decoder outputs a 10-bit image from a Hi10p file. Anything else violates the H.264 standard and potentially destroys image information. The decoder cannot know if the original image was 8-bit or was true 10-bit.

[LoRd_MuldeR]

The decoder cannot know if the original image was 8-bit or was true 10-bit.

Exactly. That's why it is totally up to the encoder implementation whether it outputs the final/decoded video as 10-Bit or as 8-Bit or even as 16-Bit ;)

(What of this makes sense or not, in a specific scenario, is a completely different question)

[nevcairiel]

The point is, if you encode as a Hi10p file, all the decoder knows is that its 10-bit now. If it was just encoded for this for effiency, or was truely 10-bit is irrelevant to the decoder, so the output image will always be 10-bit as well. There is no difference between "internal precision" and "output" here anymore, not in H.264 anyway.

[LoRd_MuldeR]

The point is, if you encode as a Hi10p file, all the decoder knows is that its 10-bit now. If it was just encoded for this for effiency, or was truely 10-bit is irrelevant to the decoder, so the output image will always be 10-bit as well. There is no difference between "internal precision" and "output" here anymore, not in H.264 anyway.

Even if the internal precision is 10-Bit, it doesn't say anything about what the decoder will put out. And in practice, I think, the decoder filter will output 8-Bit most of the time, because it has to agree on a format with the next filter/renderer in the chain. And those may not even support any 10-Bit format. The data will end up in 8-Bit anyway, unless you have a special "pro" graphics card with a special "pro" screen, which both support 10-Bit output. Consumer-grade devices don't.

See also:
https://forum.doom9.org/showpost.php?p=1509633&postcount=25

[STaRGaZeR]

What you're saying doesn't make any sense. Output is 10 bit in the High10 profile. If you convert this to something else after decoding it's a postprocessing step.

[nevcairiel]

I agree, the decoder will always output 10-bit. Any conversion *after* decoding is an entirely separate step. If i take a DirectShow decoder as an example, since you brought up a chain of filters/renderers, in my own LAV Video decoder, the internal avcodec decoder (which is the actual decoder) will *always* output 10-bit for a Hi10p file. LAV Video will also always offer this 10-bit material to any filters or renderers in the chain. If they don't accept it, it'll also offer an 8-bit image, but the conversion is done in a post-processing step after decoding, completely decoupled from the actual decoding process.

You have to strictly split the actual decoding and the output of the decoder from the final output send to your screen, which can be post-processed, filtered and whatnot, increasing and decreasing bitdepth who knows how many times.
The decoder outputs the native bitdepth of the file, for Hi10p thats 10-bit, if any filtering or processing steps alter this bitdepth afterwards doesn't change the fact that it was decoded to 10-bit.

[JEEB]

Output is 10 bit in the High10 profile.
Small nitpick, but the High 10 profile does let you have anything from 8 to 10 bits as the coded bit depth. It is mostly used for 10 bit encoding, of course. That said, using the High 10 profile to encode 8 bit H.264 is mostly a good way to have the stream never be fed to most hardware decoders ;) .

Quote from the specification:
– Sequence parameter sets shall have bit_depth_luma_minus8 in the range of 0 to 2 inclusive.
– Sequence parameter sets shall have bit_depth_chroma_minus8 in the range of 0 to 2 inclusive.

[LoRd_MuldeR]

What you're saying doesn't make any sense. Output is 10 bit in the High10 profile. If you convert this to something else after decoding it's a postprocessing step.

Feel free to call it "postprocessing". But that doesn't change the fact that the output that you will actually get from the decoder filter for a 10-Bit H.264 stream can have (and more often than not will have) a bit-depth of "only" 8-Bit. Just like pretty much any audio decoder outputs 16-Bit integer samples, despite internal processing is usually floating-point. And even if you get the output from the video decoder in a 10-Bit pixel format, the data will be converted to 8-Bit by the video renderer.

[STaRGaZeR]

Small nitpick, but the High 10 profile does let you have anything from 8 to 10 bits as the coded bit depth. It is mostly used for 10 bit encoding, of course. That said, using the High 10 profile to encode 8 bit H.264 is mostly a good way to have the stream never be fed to most hardware decoders ;) .

Quote from the specification:

Sweet, was ages ago since I read the mess that is the H.264 spec :D

Even if nobody uses this, if you set bit_depth_luma_minus8 and bit_depth_chroma_minus8 to 2, what are you supposed to get at output of the decoder? 8 bit? 10 bit padded?

Feel free to call it "postprocessing". But that doesn't change the fact that the output that you will actually get from the decoder filter for a 10-Bit H.264 stream can have (and more often than not will have) a bit-depth of "only" 8-Bit. Just like pretty much any audio decoder outputs 16-Bit integer samples, despite internal processing is usually floating-point. And even if you get the output from the video decoder in a 10-Bit pixel format, the data will be converted to 8-Bit by the video renderer.

You're completely mixing the concepts of "H.264 decoder" and "the H.264 decoder I use in DirectShow or whatever framework I use for playback". No point in discussing this further until you get that right.

[LoRd_MuldeR]

You're completely mixing the concepts of "H.264 decoder" and "the H.264 decoder I use in DirectShow or whatever framework I use for playback". No point in discussing this further until you get that right.

A (software) H.264 decoder is a software module - may it be in the form or a DirectShow filter or something else - that takes compressed H.264 bitstream as input and gives decoded/uncompressed pixel data as output. And the exact pixel format that will be put out by the decoder, e.g. whether we use a planar or an interleaved format and also whether we use 8-Bit or 10-Bit precision per component, is completely independent form the "bitness" of the H.264 stream. We can, for example, decode a 8-Bit H.264 stream to a 10-Bit YCrCb pixel format and we can decode a 10-Bit H.264 stream to 8-Bit pixel format. And, to get back to the original topic, using 10-Bit H.264 can be beneficial, even if the original input was "only" 8-Bit and even if the final output is going to be "only" 8-Bit again. It's certainly not like using 10-Bit H.264 is only helpful if your final output will be in 10-bit pixel format too. Or in other words: Having your H.264 decoder output a 8-Bit pixel format does not throw away the benefit of 10-Bit H.264 encoding. That's because the "10-Bit" in 10-Bit H.264 is not about the input/output pixel formats of the encoder/decoder, but about the internal precision of all calculations and intermediate values of the H.264 pipeline.

Now I urge you to stop the pointless hairsplitting and either get back to the topic or not post at all, because this is getting borderline to rule #11.

[Blue_MiSfit]

FWIW, almost all professional content is produced in 10 bit or greater. In broadcast for example cameras and other baseband video devices interconnect using HD-SDI which is always 10 bit 4:2:2. The end result is frequently recorded into an editing file format that supports 10 bit 4:2:2 natively, like ProRes or DNxHD.

Film scans are done at much higher bit depth, and converted to 8 bit 4:2:0 for BluRay encoding.