MediaInfo displays "Progressive" for MXF/JPEG2000 with SMPTE 422 I2 wrapping mode

[plondino]

Mediainfo displays "Progressive" for Scan type for an JPEG 2000 in an MXF wrapped with the I2 wrapping mode. The default is "Frame Undefined" (06 0E 2B 34 04 01 01 07 0D 01 03 01 02 0C 01 00) where the frame structure was not specified in the standard. ST 422:2013 defined new wrapping modes, including explicit interlaced modes.

I2 wrapping mode (06 0E 2B 34 04 01 01 0D 0D 01 03 01 02 0C 04 00) has the below frame structure:

MediaInfo should read this as interlaced. I can provide a sample file.

[JeromeMartinez]

Mediainfo displays "Progressive" for Scan type for an JPEG 2000 in an MXF wrapped with the I2 wrapping mode.

As far as we understand the spec, the 2 stored fields are expected to be displayed at the same time ("frame" sample rate), so scan type is "progressive" on purpose. Does HW display a different output at 1.5 frame than 1 frame or 2 frames? i.e. at 1.5 frame (0.050 second), 1 field of first frame and 1 field of second frame are displayed and not the 2 fields of first frame like 17 ms sooner?

IMO what is missing in the MediaInfo report is how the frame is stored. We already show a specific fields "Store method" and "Fields per block" for MOV, doing the difference between the different possibilities of "fiel" atom, we could do same for MXF.

[plondino]

I reached out to some SMPTE folks about this. Here is the response I got:

It looks like mediainfo might be using the FrameLayout property instead of using the Essence Container UL to determine whether the video is interlaced: in the case of I2, and as specified in ST 422, Table A.1, FrameLayout is set to FullFrame even though the video is interlaced.

This is my understanding as well - the old "Frame Undefined" wrapping was ambiguous and most implementations keyed off the FRAME_LAYOUT property. The new document defines three interlace wrapping modes (I1, I2, and F1) which are all interlaced content with different frame storage options. Progressive content should be wrapped with the P1 mode.

I do think having the store method is useful as well, but it doesn't supersede the fact that I2 wrapping is in fact interlaced.

[JeromeMartinez]

@plondino:

This is my understanding as well - the old "Frame Undefined" wrapping was ambiguous and most implementations keyed off the FRAME_LAYOUT property.

Now I remember, I implemented the parser a lot before 2019 so I was using ST 422 2006, which has not the UL byte 15 (set to 0, always) which is now "variant" in ST 422 2019.

But I still should have caught your case (FrameLayout of FULL_FRAME) due to 2 VideoLineMapEntry items (hence the field order despite it is "progressive" in MediaInfo output 😅), I implement the catch of 2 VideoLineMapEntry in addition to manage the Essence Container UL byte 15 (even if it is not needed, it is a security in case VideoLineMapEntry items are not present).

The new document defines three interlace wrapping modes (I1, I2, and F1) which are all interlaced content with different frame storage options.

I2 is indicated has having a frame layout of FULL_FRAME and ST 377 stipulates that Stored Height for FULL_FRAME is the frame height, but the I2 file you provided has a Stored Height of a field, isn't there an conformance issue in your file?

[plondino]

You're correct, the file I sent should have had the StoredHeight of FULL_FRAME. I will send you an update file which is correct*.

• I am still a little unclear on what the VideoLineMap property is supposed to be for I2 - ST 422:2019 says:

SMPTE ST 377-1 Annex F.4 and Annex G give normative provisions for specifying the values of other properties of the Picture Essence Descriptor, including Video Line Map, Stored Height and Width, Sampled Height and Width, and Display Height and Width. The correspondence between the values of these and frame or field is implied by the value of the FrameLayout property, as tabulated in SMPTE ST 377-1 Annex G.2.7, G.2.9 and G.2.14.

I read the table from SMPTE ST 377-1:2019 as implying that the value for full frame should be 42,0 - but I also feel like the VideoLineMap indicates where the video was sample from which would be lines 21,584. I may have to reach out to someone at SMPTE for clarification.

[JeromeMartinez]

@plondino,

You're correct, the file I sent should have had the StoredHeight of FULL_FRAME. I will send you an update file which is correct*.

Does this mean that such file is actually created by tools not in production? While fixing the issue with your file which meets ST 422-2019 I2 spec, I noticed that none of the files I have from different producers, including Library of Congress RDD 48 MXF Golden files (cc @kmurmur), are conform to the specification about FrameLayout for I2 files, and I had to implement several exceptions in my code for handling that because all other formats (DV, MPEG-2 Video...) use MXF FrameLayout SEPARATE_FIELDS even if both fields are stored in the same MXF frame, for JPEG 2000 MXF FrameLayout becomes a store method tip rather than a field temporality tip.

Anyway, it was more complicated than what I anticipated because of all the "non conforming" (which seem to be the vast majority of) files in the wild so I had to handle several cases (UL with essence container label Content Kind of 0 or 4 for the same content kind, FrameLayout of FULL_FRAME or SEPARATE_FIELDS for the same content kind, ...) by probing the JPEG 2000 codestream directly in some cases, development snapshots include the fix.

[kmurmur]

Thanks for the tip @JeromeMartinez and glad to hear you are using the LC sample files @plondino. I'll look into this issue - I think some of the 'golden' files turned out to have non-conforming issues after all. I have new sample files to add to the batch and I'll ping you when they are up.