SafeColorLimiter

[poisondeathray]

Well all this is happening in YUV, but our TV work in RGB and we know that RGB is always full range,

But it's not true... In general, "normal" TV's use limited range RGB. Computer monitors use full range RGB. (Of course newer TV's support both, and you can set GPU to output either, but I mean by default)



About the short spikes I don't remember where I read it, but it was actually to take into account compression overshootings rather than other things, but maybe it wasn't an ITU standard but rather an EBU recommendation and I'm just confusing the two...

EBU r103 is just a set of recommendations, like ITU documents, but all broadcasters, even in North America follow those r103 guidelines.

The RGB range in r103 is referring to limited range RGB (or studio range RGB). The R,G,B out of gamut check uses studio range equations, not the computer range equations that you typically see (ie. studio range RGB, RGB 16-235 black to white in 8bit, 64-940 in 10bit - NOT RGB 0-255, RGB 0-1023 )

In 8bit 0 and 255 code values are strictly reserved for SDI timing (for 10bit, code values 0 to 3, 1020 to 1023 for 10bit)

[cretindesalpes]

In case the flag is limited TV range and the content is limited TV range but out of range, 16 will be mapped to 0 correctly, but 235 will be mapped to 255, so what happens to those values above it (that shouldn't be there)? Well they're just not displayed...
It depends. If the display contrast is not set to the maximum, “superwhite” values may be displayed correctly instead of being clipped. And after resizing (or trapezoidal stretch for projectors), these values may fall back in 16–235 range because of the interpolation. Or conversely, out-of-range values may be generated at this step with significant overshoots from perfectly limited values. It all depends if the display system clips at intermediate steps of the calculations or just at the end, when sending voltages to LCD controller (or whatever technology is used).

to take into account compression overshootings rather than other things, but maybe it wasn't an ITU standard but rather an EBU recommendation and I'm just confusing the two...
Maybe EBU R 128 for audio? They recommend a maximum of -1 dBFS true peak. This is not written in the rec, but the well-known reason is that data compression can slightly change the peak output level, compared to the lossless input. Anyway the level is measured true-peak (as per BS.1770), which is not even the case with video.

[Balling]

"That's debatable." You can use --gamut-warning of mpv to see that all movies have out-of-range chroma and Superwhite. You need to remember that not only 420 FIR for left or top-left chroma siting in by itself introduces out-of-gamut gamut, but unless you use lossless avc/hevc/vp9/av1 the YCbCr 4:4:4 will get superwhite and superblack introduced due to how lossy encoders work.

"All displays are RGB " LG C9 has white subpixel for every 3 4k subpixels, so no. It is not that simple at all. Yes, it cannot simultaniously do the white subpixel and all 3 color subpixels, but still. Also, it is not THE VERY SAME RGB that is defined by matrix. Remember: BT.601 matrix is actually BT.470 System M primaries, white point CIE C (not even CIE series D), while BT.709 and BT.2020-ncl use BT.2020 and BT.709 primaries.

"the TV expects 16-235, " No, it expects 1-254, where 0 and 255 are used for sync. Wrong.

"namely a signal raging from 0.0V, 0.7V, "

Just like IRE units, this mV stuff is not to be used, you know that, right?

"therefore it expands 16 to 0 and 235 to 255" Nobody does that, unless you output RGB.

"Math error as it won't fit in 255, therefore it will be clipped out."
There is no math error. The definition includes matrix to XYZ, which is used.

"If a stream however is flagged as full range and the TV supports full range, 0 will be mapped to 0 and 255 will be mapped to 255."

YCbCr full range is not supported except in sYCC digital format of HDMI or Adobe YCC. xvYCC601 and xvYCC709 are mandatery limited range. In particular it is very hard to get full range YCbCr in any digital format (that includes newly defined in January 2021 ICtCp) for nvidia.

"serious QC Department and it will be refused." That is their problem.

"software don't have a way to flag it" Yet ffmpeg since before a week ago was flagging x11grab content to libx264rgb as limited range. It was fixed. https://github.com/FFmpeg/FFmpeg/commit/7ca71b79f2b3256a0eef1a099b857ac9e4017e36 (We had full RGB tagged as limited, yet we have no support in swscale for RGB limited. Yeah.)

[DTL]

" you can be absolutely sure that it perfectly sits within the available limited TV range values without anything clipped out unless the camera didn't have enough stops to record it"

There may be another long-read about how real scenes dynamic range compressed in SDR video cameras (up to 600% typical for broadcast-graded and more in selected products) and encoded to output but today too few time to type.

Look at least at Knee function and for example https://pro-av.panasonic.net/manual/html/AK-UB300G(DVQP1279WA)_E/chapter04_03_03.htm
[AUTO KNEE LEVEL]

Sets the maximum level of the auto knee.

[100%] - [109%]

Factory setting: [108%]

Panasonic also votes with factory defaults for >100% auto knee highest target level and in >235 in 8bit encoding.

[Balling]

"But for the ITU, the full [1, 255) range is legit."

Yes, it is 1, 254. 0 and 255 are reserved for sync. Bit levels used for sync “from 0 to 2^(N-8)-1” and “from 255 × 2^(N-8) to 2^N-1". See xvYCC standard, IEC 61966-2-4, it has those formulae.

[Balling]

And, BTW. Originally it was supposed to be level 72-252 not 16-240 to capture sync levels too. See: https://tech.ebu.ch/docs/techreview/trev_304-rec601_wood.pdf

[FranceBB]

You can use --gamut-warning of mpv to see that all movies have out-of-range chroma and Superwhite. You need to remember that not only 420 FIR for left or top-left chroma siting in by itself introduces out-of-gamut gamut, but unless you use lossless avc/hevc/vp9/av1 the YCbCr 4:4:4 will get superwhite and superblack introduced due to how lossy encoders work.


I know that, lossy encoders can create overshooting, however those are minimal. On top of that, the master is perfectly within the limited tv range, I can tell you that.
Every masterfile I received, especially for movies, is perfectly within the limited tv range levels and I haven't seen any overshooting due to the high enough bitrate, let it be AVC Intra Class 100 or XAVC Intra Class 300 or any high bitrate flavor of Apple ProRes. Sure, they're still lossy, but due to the high enough bitrate, I don't see overshooting, so the masterfile is perfectly valid and that's what I'm concerned about. If then the live H.264 encoder creates some overshoots due to the relatively low bitrate at which it has to encode, it's none of my business and it's perfectly supported by TVs, but that's only 'cause it's generally minimal.


Just like IRE units, this mV stuff is not to be used, you know that, right?


mV is still a perfectly valid unit in the Digital World as well as it's provided by an hardware Waveform Monitor from Tektronix taking the input from the playout port playing the TX Ready mezzanine file via SDI, so it's the most reliable way to measure that. Of course, people may argue that it's better to specify it as bits values, but nonetheless the millivolt map exactly to the bits values, so it's perfectly fine to use a perfectly valid working waveform monitor that uses volts as a scale. Just FYI AVID Media Composer and other NLE still support this kind of scale in their built-in waveform monitor.

https://i.imgur.com/HRLItw3.jpg

(check the waveform in the middle in the top-right quadrant SDI->FlatLumaChroma)


EBU r103 is just a set of recommendations, like ITU documents, but all broadcasters, even in North America follow those r103 guidelines.

Gotcha.



The RGB range in r103 is referring to limited range RGB (or studio range RGB). The R,G,B out of gamut check uses studio range equations, not the computer range equations that you typically see (ie. studio range RGB, RGB 16-235 black to white in 8bit, 64-940 in 10bit - NOT RGB 0-255, RGB 0-1023 )


Right.


In 8bit 0 and 255 code values are strictly reserved for SDI timing (for 10bit, code values 0 to 3, 1020 to 1023 for 10bit)


Yep, absolutely.

[Balling]

Okay, so there is this thing called VideoProcessorBlt in DirectX11. You can select Intel's or Nvidia's one if you have both GPUs. Intel does this: it first decodes 160, 160, 160 Y'Cb'Cr' to limited range R'G'B' (209.27, 139.49, 218.05), then rounds (209, 139, 218) and then converts to full range R'G'B' (225, 143, 235). That is a bad idea, of course. Y'Cb'Cr' is much bigger colorspace than R'G'B' and has less gradations in R'G'B' part of it, so by decoding to limited range R'G'B' you lose some possible precision.

And anyway you are supposed to operate on float and only quantise in the end (whether it is integer optimisation or not).

Nvidia does this correctly and gets to 225, 144, 235.

Intel may have done it because for some colors you will get not perfect full R'G'B' values (like 100% red).
Any comments?

This of course assumes that the display is BT.1886 already, so no change of transfer function happens...

[FranceBB]

And anyway you are supposed to operate on float and only

speaking of 32bit float, you come from the FFMpeg community, right? Any plan of adding support for this kind of Avisynth input in yuv? So far we're limited to 16bit planar... :(

[DTL]

Rawsourceplus plugin can import YUV444PS, YUV422PS YUV420PS . Though it is mostly useful for working with linear RGB data after final discarding all awfull inheritance from the past like sub-sampled and transfer-compressed (sub-bitted) Y'CbCr formats.
Also GREYS may be used to input float32 separated planes and combine to whatever need inside Avisynth enviroment.

[DTL]

Any comments?


+-1LSB error after processing is very great result. If you do not like errors level of 8bit systems you can freely use 10bit and more with current Avisynth+.

Also about issues with Y'CbCr systems - I hope in the future they will be discarded because it is just to make step to subsampled chroma that is not very good idea. It is shadows from the poor past with too poor MPEG codecs so they was supplemented with build-in distortions in the 2:1 compression rate R'G'B' 4:4:4 to Y'CbCr 4:2:0 system.

Now every generation of MPEG promise to provide close to x2 compression rate in compare with previous generation so using of more distortion-less R'G'B' 4:4:4 (bit-reduced or linear RGB full-bitdepth distortions-free) only equal to get previous -1 generation MPEG total compression rate. And (todays and future advanced) MPEG compression I hope introduces less distortions in compare with R'G'B' 4:4:4 to Y'CbCr 4:2:0 method.

With skipping RGB to R'G'B' compression stage increase MPEG loading to about 1.2:1 for SDR and abou 3:1 in HDR systems. But allow to get less distortions if even +-1LSB is important.
Ofcourse all mentioned systems must have headroom and footroom for transients encoding ('video-makeup look' especially) without additional distortions.

[Balling]

speaking of 32bit float, you come from the FFMpeg community, right? Any plan of adding support for this kind of Avisynth input in yuv? So far we're limited to 16bit planar... :(

There is a perfect float support in ffmpeg, ported from GIMP or GIMP's bable from 4 years ago.
As for quantising that float to integer and back, that is total garbage still, which makes it unusable, though this improved it https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200912090714.66582-3-mindmark@gmail.com/#58418 Still no tiff support though. https://trac.ffmpeg.org/ticket/5303#comment:11

But that is rgb.

[qyot27]

FranceBB is talking about libavutil/pixdesc.c and libavutil/pix_fmt.h not having I/O descriptors for AV_PIX_FMT_YUV(A)[420|422|444]F32[BE|LE], as those descriptors are the only thing the AviSynth demuxer in libavformat cares about (whether swscale can convert between them even passably doesn't enter into it).

AV_PIX_FMT_GBR(A)F32[BE|LE] and AV_PIX_FMT_GRAYF32 are the only ones defined in pixdesc.c/pix_fmt.h, so those are the only ones the AviSynth demuxer can open, even though AviSynth+ supports all those YUV(A) float formats (along with GBRAP14, YUVA420P12, and all of the YUVA*P14 formats, which also are missing in pixdesc.c/pix_fmt.h).

[FranceBB]

FranceBB is talking about libavutil/pixdesc.c and libavutil/pix_fmt.h not having I/O descriptors for AV_PIX_FMT_YUV(A)[420|422|444]F32[BE|LE].

Precisely.

[richardpl]

Balling is neither FFmpeg developer or contributor, so you knocking on wrong door.

[Balling]

Balling is neither FFmpeg developer or contributor, so you knocking on wrong door.

I am though. https://github.com/FFmpeg/FFmpeg/commits?author=ValZapod

And you are not Elon Mask either, like what is this?? https://trac.ffmpeg.org/timeline

[Balling]

Very cool commit, negate no longer clips: https://github.com/FFmpeg/FFmpeg/commit/97b5b9dbea2fd51861218416dafc46984e286826

BTW, chroma sample location in zimg (wrapper only) was wrong all along, ahahaha! Good I always used swscale. https://github.com/FFmpeg/FFmpeg/commit/27c0dd55609daf440a7744e96ac20c119bbeb80f

[DTL]

Very cool commit, negate no longer clips: chroma sample location in zimg (wrapper only) was wrong all along, ahahaha! Good I always used swscale. https://github.com/FFmpeg/FFmpeg/commit/27c0dd55609daf440a7744e96ac20c119bbeb80f

It is better do not use ffmpeg for serious processing at all. AVS+ + x264 + mp4box for muxing is good for everyday encodings.

[Balling]

It is better do not use ffmpeg for serious processing at all. AVS+ + x264 + mp4box for muxing is good for everyday encodings.

But we do not do everyday encoding. We need PQ and HLG and stuff.

[richardpl]

It is better do not use ffmpeg for serious processing at all. AVS+ + x264 + mp4box for muxing is good for everyday encodings.

You are not serious, AVS is crap.

[FranceBB]

AVS is crap.

Mind you, we use Avisynth everyday to handle every content encoded at Sky, including HDR PQ to HDR HLG conversion using custom made LUTs.

[cretindesalpes]

I think it was a sarcastic answer. FFmpeg is used by major video broadcast companies.

[DTL]

FFmpeg is used by major video broadcast companies'

May be in the very poor regions. Yes - our company also use it but only for proxy preview encodings where quality is not required at all. Only very small filesize and embedded timecode in the frame for the workers for create metadata (transcribing) before master editing at adobe nle.

[richardpl]

AVS is half-broken product used by incompetent people across the globe,
Proof is unlimited RAM usage as mentioned in one of this forums threads.
NLE are different thing and I'm rather not going into incompetent broadcast companies across the globe.

[FranceBB]

AVS is half-broken product used by incompetent people across the globe

Mind your language.
Not only this is not true, but it's also disrespectful towards the people who spent countless hours developing it and making it better and better, which Doom9 is full of.


Proof is unlimited RAM usage as mentioned in one of this forums threads.


That is ONE scenario I faced for a very PECULIAR use-case.


NLE are different thing and I'm rather not going into incompetent broadcast companies across the globe.

How funny. Avisynth is a frameserver, AVID Media Composer is a NLE, the two don't do the same freaking job! One is for post-processing, the other is for editing, is it too hard to understand? Besides, you said we're incompetent? Really? Do I have to remind you that literally the whole world is based on AVID Media Composer, which, mind you, IS a NLE? Not just broadcasters but the whole movie industry, just take a look at the logos at the end of a movie of your choice: the odds are that it has almost definitely been edited in AVID Media Composer and there's a reason for that. Not just as an editing product, but the whole environment AVID offers is second to none: AVID Nexis as RAID6 Storage, AVID Interplay Access to handle assets inside a MAM by abstracting the view and giving Media Managers lots of tool to handle it, the fact that you can have the Dynamic Relink to work on assets on different resolution and bitrate and only restore the original masterfile at export time and only in the bit you want, the integration with Spectralogic for LTO6 archive, AVID Airspeed Capture as hardware recording ports... Do I have to go on?

Yes I work in broadcast.
Yes I'm offended by your statement.

There are tons of broadcasting people who are very smart and skilled. The fact that you work in movie industry shouldn't put you above broadcasters.
There's no League A and League B workers, those working in broadcasting are just as skilled as those working in the cinema.
Besides, the concept that broadcasters are only those who receive readily available files and put them on air is totally wrong!
There are TONS of broadcasters who produce their own show, tv series and sometimes even movies, so this concept you have is totally wrong and misplaced!
You see lots of companies producing their own show despite not being a Hollywood company, so what? We have the people, we have the skills, we can do it.


This is gonna be my last reply.
This is a topic, my topic, about clipping to bring footage to legal range using an Avisynth Filter, so if you don't like Avisynth as frameserver and you don't use it and you don't have anything insightful to add to improve it, just don't reply any further.

[DTL]

"Proof is unlimited RAM usage "

It looks the feature of multi-threading multi-frame cache system. Yes - it sometime limit the complexity of the projects very fast and no way to free RAM memory for step by step processing. But for simple home projects like transcoding only it possibly may be faster and created with limited resources of freeware developers.

Really both ffmpeg and avisynth were created by 'personal computer pixel-based developers' not 'moving picture experts' and so were started and still loaded with lots of incorrect for broadcast industry processing algorithms. But with avisynth it looks like easier to avoid more or less destructive or errorneous processing of valuable data or put slow but working script workaround. Ffmpeg looks like much less controllable tool of what happens inside it. Also with every version and all in one patch the result of ffmpeg processing may become more buggy. The plugins-based structure of avisynth processing allow to keep the tested plugins separated with other parts.

[Boulder]

I think we've seen plenty of examples of the fact that just being in the movie industry doesn't mean a thing. We are often correcting their screw-ups here you know..

And being nasty towards fellow developers is something I consider very unprofessional and generally something that a person with a low self-esteem would do. You don't like it, do not use it or participate in the discussion as FranceBB said. In my almost 20 years of membership, I've found the place generally as a very supportive community and I would like it to stay so.

[Dogway]

If you work in the "movie industry" it's common knowledge software crashes every now and then, Maya, ZBrush, Substance, Mari... For me where people work means nothing if they don't show their competence

[FranceBB]

SafeColorLimiter v1.1 Released! (https://github.com/FranceBB/SafeColorLimiter/releases)

Changelog:

- Introduced Frame Properties Support as now the _ColorRange flag is correctly set to 1, namely Limited TV Range when filtering is applied on YUV (and Y only) at any bit depth, while RGB is passed through untouched.