Incorrect Sample Rate validation for non App2E interlaced content

[harrietmiller]

Problem
When using com.netflix.imflibrary.app.IMPAnalyzer we get an incorrect (and confusing) error report for interlaced content that is not App2E:

EssenceDescriptorList represented by the ID urn:uuid:1172379b-1e95-4917-a460-c73ab91a4d5a whose indicated SampleRate value is =================== EditRate =====================
    numerator = 12, denominator = 1
    , however the Resource Edit Rate is =================== EditRate =====================
    numerator = 25, denominator = 1

For this example, in the App6 Image Track File the SampleRate and the EditRate are both 25/1 which is correct (the frame rate). The reported SampleRate value (above) is actually the SampleRate of the EssenceDescriptor divided by 2 (and then rounded down).

This issue potentially applies to all interlaced content that is not App2E. A similar issue has been reported here for interlaced ProRes content.

Proposal of solution
When Photon handles interlaced content the relationship between SampleRate and EditRate is dependent on the Application ID and not just the FrameLayout (therefore should not be checked as part of core constraints).

Problem details
In the IMFCoreConstraintsChecker (link) class, the SampleRateToEditRateScale is derived from looking at the FrameLayout. If FrameLayout is SeparateFields then the SampleRateToEditRateScale is set to 2 otherwise it is 1.

According to both Application 6 (SMPTE ST 2067-60:2023) & Application 2E (SMPTE ST 2067-21:2023) the FrameLayout of interlaced content must equal “SEPARATE_FIELDS”. However:

• In SMPTE ST 2067-21:2023, the image essence shall be wrapped according to mode I1 specified in SMPTE ST 422 ("Interlaced Frame, 1 field per KLV Element") and the SampleRate must be double the EditRate (which is the frame rate).
• In App6 “Two field-coded access units each shall be wrapped in a single KLV” and “Edit Rate and Sample Rate are equal to the image frame rate”.

Other Applications could have other rules.

Note:
This issue is more confusing as App6 (for example) is not in line with SMPTE ST 377-1 (because App6 is based on SMPTE ST 381-3).

[palemieux]

This issue is specifically about factoring out the application-specific check to the application-specific class. It is not about Application 6 support.