Skip to content

Fixed indexEntry parsing bug #20

Open
swamikevala wants to merge 4 commits into
AMWA-TV:masterfrom
swamikevala:master
Open

Fixed indexEntry parsing bug #20
swamikevala wants to merge 4 commits into
AMWA-TV:masterfrom
swamikevala:master

Conversation

@swamikevala
Copy link
Copy Markdown

Moved DeltaEntry and IndexEntry registryInterfaceMapping calls to before call to Warehouse.registerTypes (as they were not getting run)

This bug manifests when there is a non-empty slice offset property in the index entries (The slice offset bytes are not parsed)

call to Wareouse.registerTypes (as they were not getting run)
that optional Index Entry properties (sliceOffset, posTable) are picked
up
@swamikevala
Copy link
Copy Markdown
Author

Added writeToBuffer() and lengthAsBuffer() methods to IndexEntryImpl so that optional Index Entry properties (sliceOffset, posTable) are picked up

key and length, since these are already read in
MXFStream.readRandomIndexPack() causing this method to read them twice.
@swamikevala
Copy link
Copy Markdown
Author

swamikevala commented Jul 25, 2022

Adobe Premiere 2022 will fail to import MXF files because of a dependency issue with the IndexTableSegment properties. IndexEntryArray (3F.0A) depends on SliceCount (3F.08) and PosTableCount (3F.0E). The assumption is that the ordering of properties in a local set should not matter and that the MXF reading application should handle any property dependencies properly. However, the spec (SMPTE ST 377-1:2019) doesn't actually mention this anywhere! Unfortunately, Adobe Premiere doesn't handle it, so we need to explicitly ensure that the IndexEntryArray is always after the NSL and NPE properties

@swamikevala
Copy link
Copy Markdown
Author

swamikevala commented Jul 25, 2022

Technically, in SMPTE RDD 32:2017 (XAVC MXF Mapping and Operating Points) published by Sony, it states on p.16

Optional properties that are not mentioned in this specification should be placed prior to Delta Entry Array and
Index Entry Array.

Both NSL and NPE are optional properties and not specified in this doc, so there you have it! Would be good if the MXF spec authors could remove this ambiguity, so that we don't have to buy spec documents published by all the different camera vendors, which kind of defeats the purpose of having a common spec in the first place!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant