R14 - Broadcast Safe Exceptions

I can not handle „Show Broadcast Exceptions“. In my clips on the timeline, there are allways some blue and yellow spots left (whatever the settings and corrections are ...).

The exports seem to be ok:
- Check „Make Broadcast Safe“ in project settings (- 10 - 110)
- Export video with Data-Levels set to video.
- Import the video to your timeline.
The „Broadcast Save Exceptions“ are gone (even, if I uncheck „Make Broadcast Safe“ in the settings).

So with „Make Broadcast Save“ checked, should not the „Broadcast Exceptions“ in the timeline already be gone? (If the reimported videos don‘t have any?)

Is there a workflow, in which using „Show Broadcast Exceptions“ makes more sense?

Check this:

viewtopic.php?f=21&t=73379

Broadcast Safe does check against old analog, simulated composite signal, which is basically not used today?

Regardless this- you seems to have the same issue as Dany. I checked it in Resolve 15b2 on Mac and after importing legalised clip warnings are gone. Has to be some bug on PC.

Hello Andrew

Thank you for your replay.


Dany writes:

1. "Broadcast safe" ON
2. Check with "Viewing Broadcast Safe Exceptions" - all legal now
3. Render (Mov/Mxf - tested with Video & Auto)
4. Import rendert file back (Mov/Mxf)
5. switch "Broadcast safe" OFF
6. Check with "Viewing Broadcast Safe Exceptions" - all illegal again

What happens with my system (R14.3 / Sierra / Mac Pro 4.1 / GTX780 / Intensity Pro 4K):

1. „Broadcast save“ on.
2. Check with „Viewing Broadcast Save Exceptions“ - I can not get rid of them (whatever my corrections are, I have also tried with the qualifier ... in vain, I can alter their size and shape, but they don’t dissapear).
3. Render (ProRes Mov, Data Levels set to video)
4. Import rendered file back.
5. Switch „Broadcast Save“ off.
6. Check with „Viewing Broadast Save Exceptions“ - all is legal.

So my results are different. I just wonder, if the way „Viewing Broadcast Save Exceptions“ are shown in the timeline (on the project source-clips) is wrong. It seems to ignore „Make Broadcast Save“.
This would explain why the reeimported video does not show any „Broadcast Save exceptions“.

Andrew, you write:

„Broadcast Safe does check against old analog, simulated composite signal, which is basically not used today?“

A very good explanation can be found here:

http://www.fcp.co/forum/4-final-cut-pro ... ll-a-thing

Ok- sorry I read it wrong.

This is strange, but it may be related to fact that when you export to YUV things may be clipped, so when you import back they are within allowed levels.

Mentioned article is more about why you want to legalise overall, but not really why to use reference to old analog composite signal. This is basically irrelevant today.

Composite IRE+gamut checks are really outdated and not used as far as I can tell. It's all replaced by EBU R103 checks, which works on YUV signal, not composite.
If you stay in Resolve within 0-1023 RGB, without having some unclipped data outside scopes you should never end up with files outside Rec.709 gamut or some illegal YUV values (assuming exporting with video levels and codecs behave properly).
You can easily create out of gamut files within software which works in YUV- like Edius.

I don't really see a point for those IRE Broadcast Safe checks at all.

Andrew, thank you for all your explanations.

This is all quite complex. So I just could relay on the EBU R103 checks and stay in Resolve within 0-1023 RGB.

So would you also export with Data set to Data Levels or has this nothing to do with that?

(I remember having crushed blacks in this way (reimported to timeline & QuickTime Player).
When I exported with Data set to Video-Levels, the video could not be distinguished from the clips on the timeline).

No- you have to export with Video levels. Full levels for YUV codecs is a special case and should be use only in "controlled environment". You have to know it was exported this way and manually interpret as Full during import. Most tools will blindly assume Video levels and it all will be wrong.

If you stay within 0-1023 in scopes and export with Video levels to YUV codec you should always pass EBU R103 check which is what about every station check against today (at least in Europe).

Great thread with many insights. I am sorry for my late answers (due to lack of time).


I have misinterpreted how „Display Broadcast Safe Exceptions“ works.
What it displays, is related to the settings in Project Settings / Color Management / Broadcast Save / Broadcast Save IRE levels.
The checkbox „Make Broadcast safe“ has no influence on this!

Andrew, according to what you write, I am on the save side with EBU R103 as composite IRE & gamut checks are outdated. Like that, I could keep vidid colors, which is great news.

The follwing thread confirms this, but in the last post Nikhil still referres to „Show Broadcast Safe Exceptions“ as something, you should use (because of chroma bursts, ect, ...)
http://www.reduser.net/forum/showthread ... s-delivery

So should I ignore this or still use „Show Broadcast safe Exceptions“?

EBU R103 doesn't really care about how "strong" is chroma (you control it during grading). All what it checks are YUV levels+ it simulates YUV to RGB conversion and checks if this doesn't produce illegal RGB values, eg negative ones.
I'm 99% sure that if you stay with legal values in scopes (without any data out 0-1023 levels) you will never export files (assuming video levels used and codec behaves properly) which won't pass EBU R103. There may be some single pixels going outside YUV levels (and some RGB illegals values) due to compression overshoots, but this is why EBU R103 has thresholds with few % allowance over ideal values.

I'm 95% sure that "composite safe" doesn't automatically guarantee you EBU R103 safe, so I would not use it at all.
What is the point of trying to enforce something which is not used by broadcasters at all these days?
Resolve should be updated in this matter.
It's like car manufacturer working to standards from 30 years ago, yet when car hits public it's checked with government body using new standards which are totally different

I think the best answer is to ignore looking at the "Safe Exceptions" display and instead look at normal scopes (Parade and Vectorscope). If you want to be a real stickler and look for gamut problems, look at it on a hardware scope from Leader, Tektronix, or Videotek (or a software solution like Scopebox) and check the diamond display or a similar X/Y pattern.

The Gamut Mapping ResolveFX plug-in can be very useful with cases where you're very close to the line on certain shots and you just need to reduce only the highly-saturated areas but not anything else. Since this was released with Resolve 14, I have had zero QC kickbacks for gamut or levels (knock on wood).

Thank you Marc and Andrew.

So my conclusion is:
- Stay with legal values in scopes (0 - 1023 levels).
- Export with video-levels.
- Because I work with LOG video, (V-LOG, BMD Film) I will use the Resolve OFX plug-in „Color Space Transform“ (on the last node), which also does gamut maping. So LOG gets transformed to Rec709 and the highly saturated areas are reduced (with knee at 0.9 and saturation max at 1.0).

I hope this makes sense.

Yes, I think it all should be good.

Because I work with LOG video, (V-LOG, BMD Film) I will use the Resolve OFX plug-in „Color Space Transform“ (on the last node), which also does gamut mapping. So LOG gets transformed to Rec709 and the highly saturated areas are reduced (with knee at 0.9 and saturation max at 1.0).

I wouldn't recommend this, because Log levels from cameras (and film scans) vary widely, and a setting that works for one shot won't necessarily work for another shot. What will help with a color-corrected project is to use the Gamut-Mapping OFX plug-in to prevent illegal colors or white levels.

I think Color Space Transforms can work, but you have to be careful that it's affecting the clips in a predictable way that works for the specific shot and the project.