AS-11 Vidchecker Fail due to structural problems/picture essence

[ScottDon]

Hi all,

I’ve recently had a video fail on multiple occasions going through the Vidchecker.

The file is an AS11 for broadcast, and uses the same template project as the last 40 or so exports which have passed Vidchecker with no issue.

The main error to come up is:

Found 3 structural - problems with AS-11

UK DPP conformance:

- Picture Essence

Descriptor item 'Black Ref Level' must be 64 (when present) but was 0. - Picture Essence Descriptor item 'White Ref Level' must be 940 (when present) but was 1023. - Picture Essence Descriptor item 'Color Range' must be 897 (when present) but was 1023.

This is something the techs themselves have not seen before.

It has occurred to me that this may  be related to what I have on the timeline - I have two colour mattes over the top of everything - a black and a white, with their blend modes set to lighten and darken. This is to prevent any stray pixels from going above or below legal luma levels. A technique learned in “The Cool Stuff in Premiere Pro” by Jarle Leirpoll et al.

My question is, does anybody else use this method for broadcast safe levels, and if so have they encountered any errors recently with their videos going through Vidchecker?

If anybody uses other methods to ensure Broadcast safe levels would they care to share them? I personally find the video limiter effect on its own to be less effective.

It is also worth noting that during these passes through the Vidchecker, it at one point indicated the colour bars were not at 100, when they definitely were. It also flagged a title sequence for harmful flashing, when the title sequence has remained untouched in 35 weeks of broadcast with no issue.

Could this just be a error with a new Vidchecker update? If so how best to proceed and avoid such issues again as there are many more TXs to deliver.

All help appreciated.

Scott.

[Jim_Simon]

Are there other checking programs that might be used as a control against Vidchecker?

[chrisw44157881]

some people have had luck using my preset. i haven't tested it in cc2019

premiere pro cc broadcast safe preset.

this will legalize all video to lumin 16-235

and chroma to 90% YUV and fit in all boxes of vectorscope YUV

CreativeCOW

[JasonBow]

The built-in video limiter (new in CC2018) handles all of this without issue. You can feed it both luma and chroma out of gamut and it will fix it fairly seamlessly.

It sounds like its failing as its expecting a file that is "video level" but the file you're providing is video levels. If its for broadcast, its going to require video levels, not data levels (which is what you're providing).

[ScottDon]

Thanks Jason. I will give it a try - using the Limiter on an adjustment layer over the whole timeline.

Are you able to elaborate a little more on what you mean by it's expecting "video levels", and I'm providing "data levels"?

Thanks!

[Jim_Simon]

http://www.hingsberg.com/2014/10/video-data-levels-demystified/

[ScottDon]

Hi all,

After sending back a  sample AS-11, having used just the video limiter effect over top of my timeline, I still received the same errors.

I have also tried with the video limiter effect and the "levels" effect over top which brings everything into RGB values.

So to the best of my knowledge I am providing "video level" media.

Would it be safe to assume that these "structural errors" are an error on the part of the Vidchecker? Am I missing something?

Note: To answer a previous enquiry, no I'm afraid there is no other comparison to use as a control against Vidchecker at this time.

Thanks all,

Scott.

[PeteChap]

Vidchecker isn't complaining about your levels in the actual video, so don't mess with vectorscopes or legalizers. It's complaining about the nominal black and nominal white levels which are set as metadata in the MXF header. They have nothing to do with the actual content (which may or may not be fine). These nominal values are mandated by the DPP.

Adobe's AS-11 exporter is writing files which are flagged as "full range", i.e. blacks are at 0 and whites are at 1023. This is incorrect, and it should be flagging its exports as "broadcast range" where black is 64 and white is 940.

Adobe have certified a previous version of Media Encoder as DPP compliant, see:

https://www.amwa.tv/certification/AS-11_DPP/certificates.shtml

However this current output appears not to be compliant.

A chap called Al Mooney is listed as the Adobe technical contact on that web page but I suggest you contact Vidchecker support and they can take it up with Adobe directly.

[windmilll16586147]

Having this exact same problem from PP2019 and Media Encoder 2019 put the file through Media Encoder 2017 (11.1.2) and it has fixed the issue so at least I can deliver but it really needs to be sorted Adobe

[zodiakr96211160]

We are having the exact same issue here - it's a shame Adobe have still not sorted this... We've found that re-wrapping the file using the DPP MAC / PC application will producer an mxf file that has compliant metadata, but anything outputted from Adobe Media Encoder throws these errors in Vidchecker (and presumably other checking software although we do not have access to any to test).

[windmilll16586147]

Have just updated to 13.1.5 and this issue still persists. Luckily I had held on to PP2017 and am able to re-encode the files. Ridiculous!!

[Ben26717275q14a]

I am having a similar issue  when exporting DPP AS-11s directly from Adobe (all versions including most recent 64bit).

We are running up to date Vidchecker 8.2.2 and have tested with the new supplied templates.

The issue is any DPP AS-11 exported from Adobe Premiere or Media Encoder will fail for “AS-11 UK DPP Structural Metadata” with reason:

Found 1 structural problem with AS-11 UK DPP conformance:

- Picture Essence Descriptor item 'Coding Equations' must be [060e2b34.04010101.04010101.02020000] (when present) but was [060e2b34.0401010d.04010101.02020000].

Has anyone found a fix for this?

[R Neil Haugen]

@Fergus Hammond would be the person to know this.

Neil

[Ben26717275q14a]

@Fergus Hammond Did you have any feedback on this issue? Thanks

[Mike Dziennik]

It's been a couple of years since I was exporting AS-11s regularly so I'm not up to date with the latest.

Out of curiosity, have you tried importig into the DPP Metadata app and then re-exporting a new file out of there? Not a fix obviously, but it might give you a workaround.

[Ben26717275q14a]

Hello, 

Yes we have tried that but we were hoping to elimanate the extra step of wrapping in the DPP metadata app. 

[rynprc]

It's mad that Adobe haven't fixed this one. I guess no-one is shouting loudly enough, despite the complaints on this forum. Not sure what else to do.

Anyway, there's a program called AMCDX that can correct this metadata flag, withouth having the extremely time-consuming re-wrap through the DPP app.