--coding-eq parameter problems with (at least) VC-3 #6
Description
Up in front, the purpose of this issue is not only to write down the issues i stepped over but also for pointing out which kind of issues possible future maintainers need to deal with. I'm completely lost without the knowledge about when and why certain features have been implemented (like all the avid specific workarounds).
Before i can submit patch/pull suggestions for this, i'll need to do lots of research and testing, FAR more than needed to finish my project (likely from a commercial perspective not worth the efforts). It is pretty simple to apply the changes to make it work for me but a totally different beast to figure out changes that are worth to be added to the BMX. For example, what i would not like to do is to introduce additional features like switches for transwrap that allow me to solve the specific problems i stepped over. This would just raise the complexity and therefore testing efforts.
The goal here is to create OP-Atom files with Slog3 characeristics which will be handled correctly by Avid MCP.
Problem: --coding-eq user switch is completely ingored (at least for DNX* files)
File: bmx\src\mxf_helper\VC3MXFDescriptorHelper.cpp
Line 238: SetCodingEquationsMod(ITUR_BT709_CODING_EQ);
This is called after applying the value from user parameter and therefore it will overwrite any previously set coding equations, e.g. the ones i set using --coding-eq parameter. Therefore, whatever i set in --coding-eq will never end up in the file when using -t avid.
Also i am not certain about this:
File: bmx\src\mxf_helper\PictureMXFDescriptorHelper.cpp
Line 652: if ((mFlavour & MXFDESC_AVID_FLAVOUR)) {
What this does is slicing the provided primaries UL into half and swap it (if "-t avid" is used).
Example:
Original (normal) UL for primaries 709:
060e2b3404010101 0401010102020000
After this function and using "-t avid":
0401010102020000 060e2b3404010101
I am relatively sure that this is how they do it in AAF but at least Avid MCP 2022 creates OP-Atom files with the "normal" UL instead of the swapped one.
Edit:
to get the files from BMX finally working in MCP, i also needed to disable the avid specific code part of
File: bmx\src\mxf_helper\VC3MXFDescriptorHelper.cpp
Line: 221: if ((mFlavour & MXFDESC_AVID_FLAVOUR))
Error: when writing the avid_pc_label, MCP 2022 was not able to ama_link the op1a file, media type not supported. MCP itself creates the pc_label in it's Atom files
Also, i reverted the avid specific (non SMPTE 377 compliant) 9-byte product version to a 10-byte product version. Not sure if this would prevent MCP from importing the file but it leads to conformance errors in all the mxf checkers.
File: bmx\deps\libMXF\mxf\mxf_avid.c
Line: From 1087
Did Avid change something or do i get something fundamentally wrong?
Steps to reproduce:
Let avid produce some DNXHD into Avid Media Files folder, rewrap it with BMX e.g.
bmxtranswrap -t avid --tape ffastrans --project ffastrans --import sourcefile.mxf --coding-eq urn:smpte:ul:060e2b34040101010401010102020000 --color-prim urn:smpte:ul:060e2b34040101060e06040101030105 --transfer-ch urn:smpte:ul:060e2b34040101060e06040101010605 -o "C:\Users\Public\Documents\Avid Media Composer\Avid MediaFiles\MXF\1\rewrap.mxf" "C:\Users\Public\Documents\Avid Media Composer\Avid MediaFiles\MXF\1\V01.68EC237A_13CE913CE996AV.mxf"
after that, try to import (ama link) the rewrapped file.
TODO (note to myself):
- Create clean patch with the changes i needed to make to get it working
- Check why things are as they are (all the avid exceptions that appear not valid anymore)