Video Line Map relevance for ST2067-x applications?

[dtatut]

ST377-1 mandates the use of the Video Line Map property in the essence descriptors. Currently no application defined in the ST2067 family makes use of this property.

In addition, there seems to be a lot of confusion about the correct values for some defined raster formats (UHD) as well raster formats with arbitrary dimensions (allowed by some ST2067 applications).

Is there a way to make this property optional or irrelevant for the ST2067 applications?

[gzander]

Video Line Map is used for topness detection in ST 377:2004. This was removed with revision of 2009 or 2011, but no one adopts the new way of topness encoding. To remove Video Line Map, all have to adopt ST 377-1:2011 topness encoding and write MXF version 1.3 compliant files.

[dtatut]

@gzander : Thanks Gregor for confirming this. We should get that fixed in ST2067 as it makes no sense there IMHO. @palemieux : Maybe at the next revision?

[palemieux]

This was removed with revision of 2009 or 2011

ST 377-1:2011 still specifies that VideoLineMap is Best Effort, so it is mandatory to encode.

What do you mean by "removed"?

[gzander]

I mean removing the content (values) of VideoLineMap. The values of VideoLineMap are needed for topness detection of MXF version 1.2 (2004). This is the answer to Dan's comment: "This property seems to be a source of confusion and nobody seems to be using it within the ST2067 family. Would it be unwise to remove this property from essence descriptors?" in the other thread referenced from the initial comment.

[mrmxf]

Should we treat it the same as timecode and draft a line map best practise (or maybe a topness best practise)?

[gzander]

My feeling is, that VideoLineMap don't have any use case for MXF version 1.3 and should be ignored or better removed. But we should have a best practise for topness.

[palemieux]

But we should have a best practise for topness.

+1

Are you volunteering by any chance? It would be great given your experience and interest.

that VideoLineMap don't have any use case for MXF version 1.3 and should be ignored or better removed

Yes. Should https://github.com/SMPTE/ST377-1-2011-revision/issues/19 be moved to the next milestone of ST 377-1?

[gzander]

But we should have a best practise for topness.

+1

Are you volunteering by any chance? It would be great given your experience and interest.

I like to volunteer, but have to ask my manager.

that VideoLineMap don't have any use case for MXF version 1.3 and should be ignored or better >>removed

Yes. Should this (issue)[https://github.com//issues/19] be moved to the next milestone of ST 377-1?

Yes, we should move this to the next milestone of ST 377-1.

[palemieux]

@mrmxf I think this should be classified as a bug since the specification states that Video Line Map shall specify the Line Numbers of the first line(s) in the video interface to which the Sampled Rectangle is mapped, but not all video essence originates from or is destined to a video interface.

[gzander]

@mrmxf I think this should be classified as a bug since the specification states that Video Line Map shall specify the Line Numbers of the first line(s) in the video interface to which the Sampled Rectangle is mapped, but not all video essence originates from or is destined to a video interface.

+1

[mrmxf]

agreed and have added a label - is it important enough to update the draft project proposal and address now?

[gzander]

I believe it is important to address this. I like to propose that we should add a clear description, how topness is signaled correct and VideoLineMap shall not be used to detect topness. 377-1:2019 have only a note, that the order of the VideoLineMap numbers should not be used for topness detection.

[mrmxf]

That's good enough for me - I've revised the bug to be phase 1 and will update the project proposal

Bruce