Broadcast safe

I am using the most recent version of Davinci Resolve Studio and note that View>Broadcast Safe Exceptions is grayed out. In the project settings I have broadcast safe turned on and at -10 -110. Why is this grayed out?

I tried different color spaces from sRGB and set the project for Davinci YRGB color managed. It is still grayed out. Is this a bug with the mac version of Resolve Studio?

Those safe exceptions are for analogue transmission which is basically useless these days.
Today you need your files to be EBU R103 compliant. By default every Resolve export should be fine (sometimes codecs overshoots may cause files not to be).

Thank you. I was doing a Linkedin learning tutorial and they had a large section about Broadcast safe and turned it on and off.

Problems is that it's totally obsolete measure. No idea why BM still keeps it there.
There is a lot of knowledge and tutorials which "live by the past".

I tried different color spaces from sRGB and set the project for Davinci YRGB color managed. It is still grayed out. Is this a bug with the mac version of Resolve Studio?

The menu item is only available from the Color Page.

Problems is that it's totally obsolete measure. No idea why BM still keeps it there.
There is a lot of knowledge and tutorials which "live by the past".

unfortuantly alot of delivery documents also live in the past, and if one has to deliver to meet out of date spec's to pass QC, then the tool can still be usefull in 2019

Not sure which country or station use this ancient method. I deliver a lot of masters world wide and not a single place ever asked about master to be normalised according to IRE. It's all EBU R103. Those 2 are quite different, so I would simply forgot about IRE normalisation (until specifically asked for it).

i get that and agree with you, but i find the "display exceptions" to be useful none the less

here's where i use it... after conform and first pass i turn on "display exceptions" and add Paul Dore's blanking error finder, and then hit go on my external error logging set slightly tighter than EBU, and hit play in Resolve and go home.

When i come back in the morning, i print the errors and go about sorting them as needed

my external error logging is what i rely upon, not the "exceptions" display

but it does help flag borderline chroma excursions, turns them into clearly visable/loggable artifacts, a safety valve really

anyway that's how i use that function, and leaving it there is not hurting anyone....

i have a few distb's i deliver to that insists on meeting spec's from 1972.. i was told there's still anlouge transmiters running in a few places, Porto Rico i was told is still running old skool, and that was enough for the distb to insist that we meet the standards from 1972

Maybe you can use it as some guide, but those 2 are based on very different principles, so 1 doesn't replace other.
In my opinion it's very confusing for those without specific knowledge. They see name and build wrong assumptions for what it does.

The problem with the broadcast safe function is that it will change the grade of parts of the image that are near the limits, rather than clamping them. That makes it totally useless.

The problem with the broadcast safe function is that it will change the grade of parts of the image that are near the limits, rather than clamping them. That makes it totally useless.

Hey tom, I've seen you reply to a number of threads regarding Broadcast safe and how the option in Resolves Color Management page is useless.

I've worked with it on and am still having issues with a program passing QC, so while i agree, i still feel a bit in the dark on how to effectively clamp the over and undershoots. Program needs to be 0mv - 700mv, when viewing Broadcast safe excursions it reveals there is a little over and under throughout. I tried soft clip, but it's elevating my overall black levels.

It's useless because it's based on IRE measure (old analog one) which has nothing to do with current digital world and gamut measurement which is used today. BM still keeps this about useless option which only misleads people.
Saying this you should not really have problems when exporting from Resolve as it operates in RGB, so this should never produce bad YUV output (if you use uncompressed output).
Any compression will create overshoots- even ProRes etc. and those will create problems, but only if you measure against perfect 100% signal. R103 standard, which is used by most (if not all) broadcasters has threshold which allow for small (or relatively not that small) deviation from ideal signal and any intermediate codec's overshoots should easily fall into this thresholds.

What codec are you exporting to?
How do you measure gamut? Is it against R103 standard?

Don't try to hit 100% perfect signal as it's basically impossible to do with compressed format (and without raising blacks and lowering whites).
Soft clipping (+ luck) slightly above perfect levels is the only option. This is what legalisers do as well- they soft clip slightly above perfect levels in order to give space for codecs to overshoot. This is all based on pure luck as no one can really tell how given codec will "damage" your signal. Heavier compression= more possible problems.

Here is EBU R103 standard. You have 5% allowed deviation at bottom and top+ overall area with those overshoots can account for max 1% of the frame.

Here is also very good summary about current reality:
"The EBU, considering that,
• video levels have traditionally been measured with devices that display a trace, such as a traditional waveform monitor,
• that readings in mV no longer give relevant information in digital signal infrastructures,
• television systems now include high dynamic range and wide colour space images as well as
standard dynamic range and colour space images in the same digital container,
• that a certain tolerance can be allowed in digital signal levels"




If you take your master and put through legaliser which will "fix your video" it all sounds good, but moment later this is encoded to some format and introduces overshoots again. As I already said- only way is to legalise stricter than ideal levels and pray that codec won't introduce overshoots which even so will go outside thresholds. If a place tries to measure against 100% perfect signal without any thresholds then good luck with it. Ask them to create such a file

Stay away from ticking 'super black/white' in export option as this is a special case for YUV codecs and you rather want to avoid it in general and specially for broadcast delivery. Make sure all looks good in scopes and it's clearly within 0-1023 levels. Places which cause problems are high contrast areas, specially any borders between dark/bright pixels.

Eyehegith use to have PDF about it. It was part of their BrodcastSafe plugins, but they don't sold them anymore. They had extra "stricter" preset to compensate for possible later compression overshoots.

I've worked with it on and am still having issues with a program passing QC, ...

I highly doubt the QC is checking for legal composite levels which is what this limiter is all about. The last time I saw this requirement in a spec sheet was around 2005.

Igor, Andrew, thank you for the information!

I'm aware that it's not helping me any as everything is within 0-1023 on my scopes yet QC keeps telling my image is not broadcast safe. Over or under, where exactly, they won't say.

I'm having to export DNxHR 10bit to then do a ProRes 422hq wrap in Media Encoder (because Windows Resolve doesn't support ProRes, thanks appple / black magic / whoever for that one!).

It's been quite a nightmare job so far. Director and DP loved the first pass I did, but QC said the blacks were elevated and we couldn't get it downgraded to a creative intent note, so since then i've worked on bringing black levels down while retaining the look as much as possible and now they are saying it's just not broadcast safe.

Probably getting canned off this one and it's a shame.

It's been quite a nightmare job so far. Director and DP loved the first pass I did, but QC said the blacks were elevated and we couldn't get it downgraded to a creative intent note, so since then i've worked on bringing black levels down while retaining the look as much as possible and now they are saying it's just not broadcast safe.

A lot of that boils down to understanding scopes. What's the specific complaint from QC? Too crushed, or blacks too lifted? Often, QC people are only looking at scopes and making very technical judgements that may veer from artistic intent. I have had cases where maybe there were 3 or 4 shots where the images deliberately looked very wonky, and we talked the QC people into accepting them due to "creative intent by director."

My advice would be (if you haven't already) read Tektronix' guide:

"Using Waveform Monitors as Artistic Tools for Color Grading"
https://www.tek.com/document/primer/gui ... resolution

This goes into what's acceptable for broadcast vs. what is not. (Note this paper is old enough that it doesn't deal with HDR, which is a whole separate matter.) What I usually do is, if I see a scene where we're going past the permitted gamut range, I'll drop in a Gamut Mapping OFX plug-in and let it force the image into legal Rec709. Generally, this does a more graceful job than I could do with curves and clips. I don't like using this for the entire show, because it tends to affect levels that are barely legal, and I'd rather leave those alone.

Usually during the session, I'll warn directors and DPs when we're getting into a really dark, really noisy, or really intense situation, and I try to get them to lean towards something a little more legal. For home video and broadcast, I think the way to go is "when in doubt... go lighter." Not too many people will complain that a dark scene is a little light, but they'll absolutely complain if it's a little too dark and the details start getting muddy.

I've had a few knock-down/drag-out fights with studio QC departments in the last 30 years, and usually I can take 3 pages of angry technical notes and -- after a discussion with the QC operator -- get them to compromise to maybe their top 4 or 5 shots where we may have crossed the line. A fix on 5 shots is trivial. You do have a problem if you have a feature with 1500 shots and they say the whole thing is bad.

Igor, Andrew, thank you for the information!

I'm aware that it's not helping me any as everything is within 0-1023 on my scopes yet QC keeps telling my image is not broadcast safe. Over or under, where exactly, they won't say.

I'm having to export DNxHR 10bit to then do a ProRes 422hq wrap in Media Encoder (because Windows Resolve doesn't support ProRes, thanks appple / black magic / whoever for that one!).

It's been quite a nightmare job so far. Director and DP loved the first pass I did, but QC said the blacks were elevated and we couldn't get it downgraded to a creative intent note, so since then i've worked on bringing black levels down while retaining the look as much as possible and now they are saying it's just not broadcast safe.

Probably getting canned off this one and it's a shame.

If you're going through Adobe then drop Video Limiter (it's now proper legaliser) on it and use 0-100% preset. This will fix any big overshoots from DNxHR, but of course ProRes will introduce own ones. I still have hard time to believe there is a "real" issue there. You can also try to minimise it by going to uncompressed out of Resolve, then AME. If you doing non 444 output then you go over YUV 422 10bit uncompressed, otherwise use 10bit RGB.

Also- be strong and say that you want a proper report with details: timecodes, etc. what exactly is wrong, otherwise you will waste weeks fixing it blindly. If they really know what they are doing they will have no problem proving you problems. I suspect otherwise. Them saying "it's not broadcast safe" is taking a pixxx. Don't let it go that easily.
There is small possibility DNxHR can be messing levels, so try other route (uncompressed or Cineform).

If you really want to be sure you can find some web based QC service (eg. https://www.veneratech.com/quasar-file- ... c-on-cloud ) which will let you check file against gamut etc errors (using proper R103 spec) and then send report into their face Sometimes this is the only way.

Over or under, where exactly, they won't say.

If they don't specify exactly how and where the excursions are taking place, they are not doing their job properly. You must insist they supply those details.

Also, when assessing broadcast safe on a Parade, make sure to have Video Level Scopes turned on under the 3 dot menu, and Low Pass filter turned on - any signal excursions that no longer show up with low pass filter turned on don't need to be worried about.

Yes, for broadcast you rather want things to be low pass filtered. This will already filter many overshoots on high contrast border areas.

Boris FX does sell a Broadcast Safe plug-in as an OFX component, and it does work. I think it's a little severe, and for me what I do is just keep an eye on the scopes during a second pass, and if anything looks borderline in Rec709, I'll drop in a ResolveFX Gamut Mapping plug on one of the last nodes, and make sure Luminance Mapping and Saturation Compression are both turned on, and then I look at the results. In general, the default settings will make things "legal" without stomping on it too much.

I'm OCD enough that I won't leave a plug-in like this turned on for an entire project, but I will drop it in on problem scenes provided there's no adverse effects. Bright neon lights are definitely a big problem.

Note this is only valid for display-referenced projects. For color-managed... it's a whole different thing. As soon as I dive deep into Resolve 17, I'll let you know how it goes. My hope is that it'll automatically tone- and saturation map to the delivery format, but the trick is whether it looks good.