Subtitle LoadFont check failing on Interop DCP

[jamiegau]

Hello all, Recently a studios DCP was flagged as having issues..

2021-02-27 14:44:43,534 - Clairmeta - INFO - Check report:

Status : Fail
Path : **_FTR-1_S_EN-XX-EN-CCAP_AU_51-VI_2K_XX_20200902_SIL_IOP_OV
Size : 44.30 GiB
Total check : 116
Total time : 367.09 sec

Error(s):
  + CPL_cb56387a-71ef-47cc-a8ef-220ea94635b6.xml (**_FTR-1_S_EN-XX-EN-CCAP_AU_51-VI_2K_XX_20200902_SIL_IOP_OV)
    + 641207c1-77ae-4e61-8cad-86b128ec65f0/**_FTR-1_S_EN-XX-EN-CCAP_AU_51-VI_2K_XX_20200902_SIL_IOP_OV_01_en_cc.xml
      . Text subtitle must contains one and only one LoadFont element.
        Text based subtitle shall contain one and only one LoadFont element, found 0
    + 0ad5bc3e-727b-42e0-821f-5322ecb241d8/**_FTR-1_S_EN-XX-EN-CCAP_AU_51-VI_2K_XX_20200902_SIL_IOP_OV_02_en_cc.xml
      . Text subtitle must contains one and only one LoadFont element.
        Text based subtitle shall contain one and only one LoadFont element, found 0
    + ea27fcfe-83a5-4ab7-9317-3fa44850917f/**_FTR-1_S_EN-XX-EN-CCAP_AU_51-VI_2K_XX_20200902_SIL_IOP_OV_03_en_cc.xml
      . Text subtitle must contains one and only one LoadFont element.
        Text based subtitle shall contain one and only one LoadFont element, found 0
    + 16386d7e-5cf6-4030-8955-a26368f1cfb6/**_FTR-1_S_EN-XX-EN-CCAP_AU_51-VI_2K_XX_20200902_SIL_IOP_OV_04_en_cc.xml
      . Text subtitle must contains one and only one LoadFont element.
        Text based subtitle shall contain one and only one LoadFont element, found 0
    + 26cf158c-545a-4e68-a877-311ae0711346/**_FTR-1_S_EN-XX-EN-CCAP_AU_51-VI_2K_XX_20200902_SIL_IOP_OV_05_en_cc.xml
      . Text subtitle must contains one and only one LoadFont element.
        Text based subtitle shall contain one and only one LoadFont element, found 0
    + 906489ef-1499-469f-8e9d-042d7800c206/**_FTR-1_S_EN-XX-EN-CCAP_AU_51-VI_2K_XX_20200902_SIL_IOP_OV_06_en_cc.xml
      . Text subtitle must contains one and only one LoadFont element.
        Text based subtitle shall contain one and only one LoadFont element, found 0

DCP - **_FTR-1_S_EN-XX-EN-CCAP_AU_51-VI_2K_XX_20200902_SIL_IOP_OV - Check failed

This was only apparent in a newer clairmeta, as an older version I have based into my online checking system did not find this error. This obviously cased some "Whats going on here". Looking at the code:

def check_subtitle_cpl_loadfont(self, playlist, asset, folder):
        """ Text subtitle must contains one and only one LoadFont element.

            As specified in SMPTE 429-2 8.4.1, only exception is PNG based
            subtitles. SMPTE 428-7-2014 5.11.1 also specify that the LoadFont ID
            attribute shall be a string of one or more character. This is
            not enforced at the XSD schema level so we explicitly check it
            here.

            Reference :
                SMPTE ST 428-7-2014 5.11.1
                SMPTE ST 429-2-2013 8.4.1

This appears to be a conformance check only. Should such an issue flag a WARNING, and not a FAIL? Does this error indicate Fail-to-play/Fail-to-show-captions in some DCI-Players?

Would refer this was at WARN before I adopt latest version (1.1.1)

[remia]

Thanks for reporting @jamiegau. I think this highlight a current weak point of ClairMeta in the way it deals with the requirement differences between Interop and SMPTE.

Assuming your subtitle file contains Text elements (and not only PNGs), if the DCP was SMPTE it would most definitively be an error, as can be seen in SMPTE 429-2, ClairMeta follow the norm and will throw an error whether it plays on server or not is not the matter.

429-2 When Text elements are present in the Timed Text essence, one (1) LoadFont element shall be present. Timed Text essence shall not contain more than one (1) LoadFont element.

However we are here with IOP and the actual TI specification says the following:

TI 1.1 If no LoadFont element is present in the XML file, then a default font will be used.

So it seems that we want to actually skip this check for Interop DCP here. We don't have ways of specifying different errors levels per DCP standard unfortunately but I don't think a warning would be necessary here either.

Any thoughts ?

[jamiegau]

We do have 2 different DCP standards, and I think this must be addressed in terms of the errors given. For example, if a test is not applicable to the older interop quasy standards then we should not flag an issue. Interop is yesterday and it will not change or progress, but there are many Interop DCP around and climate will be used against them. False positives like this do have to be addressed even if on a case by case basis as they surface.

Users who use clairmeta will predominantly use it to ensure a DCP is in good shape to use in real presentations/wide-distributions. If a non-conformance issues are present, warning should come out. If possible no-playback issues may result, errors should come out.

So yes, if this "check" is not applicable to Interop DCPs then it should be skipped when given an Interop DCP. And probably should indicate this in the array of checks done.

Like the adoption of RDD52, a set of recommendations that are not based on the strict specifications, RDD52 is a set of tests to ensure a DCP will play on as many DCP-Players in the world as possible. This falls into a similar category.

"Common sense rules the day"

[remia]

I pushed the change in #179. Unfortunately we have currently no way as tagging it as bypass explicitly.

ClairMeta was developed more in a mastering / preservation context where the requirements are more strict than for distribution. Fortunately we made checking profile for just this reason and anybody could implement it's own. We could imagine having a RDD52 like profile available in the future, that would be based on practical recommendations instead of strict respect of the standards.

I encourage anyone to create issues for RDD52 checks that would have the highest priority to add in the tool. Better still, create pull request for these, even if not perfect it can greatly help to get us started!

Thanks.

[matmat]

This is also in the TI Subtitle spec:

2.7 LoadFont

(..) Note: In the current version of the spec, only one (1) font can be loaded for a presentation. If more than one font is specified, only the first will be used.

Maybe a warning would be appropriate if more than one LoadFont element is present in an Interop subtitle XML file?

[remia]

Yes good point, will re-open the issue until this is fixed then.

We first need a way to specify various errors levels depending on the DCP standard / application to support this though.

[matmat]

Also found this document, which is probably a good reference on Interop subtitle constraints: https://web.archive.org/web/20140924153620/http://dlp.com/downloads/pdf_dlp_cinema_subtitle_operational_recommendation_rev_a.pdf

[remia]

ClairMeta 1.1.2, as just released, now bypass the LoadFont check on IOP.

Still leaving this open as we want to provide a warning when a mechanism for #194 is in place, as @matmat mentioned.