AS-11 file fails AQC due to incorrect Coding Equation

[Mr Seaniepie]

MacOS Ventura

Exporting an AS-11 from Premiere Pro v23.0

When testing with the AQC from Telestream (Qualify) it reports the following error:

Found 1 structural problem(s) 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]

The second part of the descriptor is not what it should be. This is, I am told, an issue in the exporter from both PPro and MEnc and reported since at least 2019. It is embedded in the .mxf and cannot be edited externally. As this is a key element of getting programmes to broadcast it is essential that this gets fixed to live up to the 'Pro' part of Premiere's name.

[rynprc]

Agreed. DPP AS-11 is not a bendable format that needs to fit Adobe, Adobe need to make complient and on-spec files.

The most fusttaing thing is that it used to do this fine!

[michaelm11605974]

Too busy focusing on AI features than making the basics work. It's not the first time I've had issues with Adobe not working with industry standard kit - they often expect you to be the messenger boy between Adobe and the other company - rather than them just taking the time to do some actual testing themselves.

[Mr Seaniepie]

Or

Telestream should have followed the full AS-11 guidelines when coding their software and also included a lot more profiles in their hardcoded list, including something as basic as 709 (which is what Adobe defaults to) and not expecting the 8th value to be "0x0D" instead of "0x01"!

To reiterate what was said before:

• VidChecker shows that the 8th value in the UID should be 0x01 instead of 0x0D. 
• The SMPTE ST-400 doc states that the 8th byte represents a version number.
• VidChecker is expecting a hardcoded value of 0x01, which is incorrect.

[Mr Seaniepie]

This shows that they had tested with Telestream's software to know what it was expecting and to know it was incorrect. Telestream are the ones not following the 'Industry Standard' , namely SMPTE ST-400

[michaelm11605974]

I can put good money on that no one from Adobe has reached out to Telestream about this issue - given that this appears to have been going on for some time now. I had to chase Adobe for over a year to fix a Blackmagic issue, and they fully expected me to relay messages between the two companies.

[rynprc]

I think there's a lot of hangup on this really having anything to do with Telestream.. They are just creators of a couple of tools that creates a reject report. I'm sure other AQC tools would also.

If you can get any broadcast in the UK to accept a DPP AS-11 export from Premiere Pro, created in a version post approx-2017, then I'll be very impressed. It can't make them to the DPP AS-11 spec. I've provided an example of that specification from Sky upthread.

As noted a couple of tools can adjust the problematic value. One created by the DPP itself, slow, clunky, and one independent tool that happens to fix the value in question.

I've also noted that the SMPTE registry (https://registry.smpte-ra.org/view/draft/labels_view.html) seems to suggest something different to the Adobe expliainer for this upthread, as I read it.

I don't really think that Adobe are going to make this export DPP spec complient at this point, I would recommed users get AMCDX to edit that problematic value and obtain and acceptable AQC report for delivery to broadcasters. Adobe does at least get most of the way there at this point.

If Adobe really think the DPP are wrong in their spec I guess those to orgs should take it up with each other, but as we're approximately 6-7 years deep into this I don't really see any change happening.

[R Neil Haugen]

There are quite a lot rather of Premiere users in UK, Norwegian, and other broadcast shops exporting routinely without QC issues. Across national boundaries, different QC processes and all.

So ... this is to me one of those frustrating things that does hit a few users. And if very frustrating that Adobe and Telestream can't simply get that issue handled. I don't know if the Telestream QC can be site or organization specfic, though. If so, then it could be perhaps an issue only with that organization's implementation and option choices.

There's a few other things similar to this that are very, very annoying for those affected.

[michaelm11605974]

My guess for other Premiere users not having this issue is that they're using Content Agent or even Vantage made by Telestream to make the DPP AS-11 package and not using Premiere's AS-11 preset directly. I for one - export as AVC-Intra 100 for commercials and Promotions and don't use the AS-11 preset for internal deliveries at the broadcaster I work for.

I've only used the AS-11 preset today as I needed to export proper AS-11 compliant files for a programme.

My annoyance about this is that Adobe have made a preset that clearly doesn't work with one of the biggest AQC software packages. There's no use in which the other user is stating that Adobe have made the metadata correctly if it doesn't allow you to use it with Vidchecker.

It's worked at some stage, as I've done AS-11 exports on earlier versions with no issue.

[rynprc]

The use is Premiere gets me 99% of the way there without changing my workflow or software, although I've certainly looked at it. With AMCDX I can fix the issue in 10 seconds and get an AQC pass in (for example) Vidchecker. No need to use the DPP app, although we were doing that at one point.

I'd rather Adobe address this, I've been asking about this on Adobe bug fix, suggestion and feedback portals since weeks after they made the change that broke my workflow. I'm just not optimistic about a fix at this point.

I still think the water is well muddied here with talk of Telestream. If the fault is really that Telestream isn't looking for a correct value, then it's because The DPP are asking for an incorrect value. All Telestream is doing is looking for values that fit the spec that the DPP have provided for their AS-11 spec deliverables.

It's all got weirdly heated here.

[Mr Seaniepie]

There is good, professional reason for this. But I expect you wouldn't appreciate the reason. It is frustrating, I fully understand. But equally frustrating is that messaged Telestream with this an age ago and since and THEY have chosen to ignore despite it being a failure on their part and not following the SMPTE guidelines. Working for a company who put out several programmes per day that have to deal with this, you can imagine how annoying it could be. Patience is wearing thin. The bottle neck here has always been Telestream and are located in my hometown of Rochester, UK. I've known personally the professor who developed it and their sales rep from decades ago. I'm not big fans of theirs. I won't say anything liable against them but, well, as such I'm limited on saying anything at all. Awkward! 

Adobe AI, btw, is handled by a whole separate team for each app. APIs like those for AS-11 will be handled by another, separate team. 

[michaelm11605974]

Adobe's AS-11 preset worked at some stage in earlier versions. It now doesn't. If it ain't broke don't fix it. I would surely hope they didn't update the preset - test it against Vidchecker and seen that it doesn't work and decided to continue with the updated preset regardless. That helps no one.

[Mr Seaniepie]

The SPMTE Registry you linked to describes it correctly and shows that Adobe have it correct. It should be for 709 'CodingEquations = [060e2b34.0401.010d.04010101.02020000]'. It should have to be anything else. This is the correct indicator for 709. 
The BBC require programmes be output in 709. Hence the failure for every single programme submitted. 

Interesting fact. You don't need to pass a Hardings test for Netflix, Prime, YouTube or any other streaming platform. Only the main broadcasters. And only because they all follow the BBC standard. Once 'flashing images' and photo-epilepsy is removed from the requirements for broadcast (as it is for every other platform) Harding won't have the monopoly on the tests and it will be open to other developers like BlackMagic, etc to hardcode their own pass/fail certifiers. Ones that even other streaming platforms will automatically take advantage of. Bye bye Telestream. 

[rynprc]

I'm going to geniunelly assume that my read here is wrong, but I can't find an entry for 060e2b34.0401.010d.04010101.02020000.

I find the one in the screenshot above which seems to the value in contention, and is 0101 instread of 010d

[Mr Seaniepie]

It's listed in the row for the symbol 'CodingEquations_ITU709'. The underscored bit is not used so the actual symbol is 'CodingEquations'. It's marked with '_ITU709' just to make it easier to lookup. It is a lookup table. Follow that row along and you see it with its full SMPTE UID, 

urn:smpte:ul:060e2b34.04010101.04010101.02020000

[Mr Seaniepie]

Apologies for my earlier post where I had confused things by putting in the one VidChecker was expecting, with 0D rather than the correct one that Adobe is using which is 01. That's maddening that I did that. Sorry. 

[rynprc]

Hang on. DPP spec wants 01, not 0d. Premiere is coding 0d.

Found 1 structural problem(s) 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]

• 
  I still think talking about Telestream/Vidchecker is a red herring. They are just accurately reflecting the DPP spec. If it's wrong, it's on the spec. 
  but based on all other software and myriad broadcasters agreeing with the spec, and how much work and oversight goes into the DPP specs...

[Mr Seaniepie]

Again, from Adobe:

• The SMPTE ST-400 doc states that the 8th byte represents a version number.
• VidChecker is expecting a hardcoded value of 0x01, which is incorrect.

it should not be hardcoded. It is a version number. It could and is anything between 0x01 and 0xFF. But VidChecker is expecting ONLY version 1 of 709 and not v13 or anything greater than v1. Obviously, to allow for future iterations of Rec/BT 709, this should not be hardcoded and allow for any potential number. This is what the techies at Adobe were making the point about. 
I hope that description makes a little more sense. 🫠

[Mr Seaniepie]

This Doc, page 5

https://pub.smpte.org/pub/st400/st0400-2012.pdf