AcademySoftwareFoundation
Fixed reading of XML files exported from Hiero or NS
- Previously only the first occurrence of a file with an id was properly added.
We had issues reading XML files from Hiero and NS. Where clips magically disappeared. The issue boiled down to that otio was disregarding file elements with the same id.
This patch solves the problem but not being super familiar with XML or the code base I am not sure if it is solved in the correct way. Getting Foundry to fix their XML export seems like an impossible task so adding a workaround to otio seemed like the way to go.
Hi @Eiken, thanks for the submission!
It looks like this update may have broken the unittests for this adapter, we'd need that resolved before merging. Also, do you happen to have a sample file you could provide that exhibits the issue? It would be great if we could add a test to make sure this doesn't happen.
The FCP XML spec talks about how to properly handle id attribute. If I'm reading what you're saying correctly, it sounds like the adapter may not be properly doing a lookup for a given id when it's reused - but I'd love to get an example EDL to validate.
Let me know if you can provide something, I'd love to help get this fixed!
Yeah I saw the tests failing as well. Will dig them up and see if I can resolve them and make a small example file of the output.
Example file. Renamed from xml to txt because github dont accept xml foobar.txt
Steps to reproduce:
- Open blank project
- Import random clip
- Put in sequence
- Split in two with slice
- Export as xml
Result:
- id for file in both clips are the same
- Reading with the fcp_xml adapter disregards one of the clips
@Eiken Thanks for providing the example file and the steps you used in Hiero, that kind of context is super helpful. I'll try and take a peek in the next day or two, I suspect it should be a pretty straightforward fix.
@Eiken @jhodges10
Sorry for the delay in pulling this up. I loaded foobar.txt from above (renamed to foobar.xml in otioview and compared to what I see when I import to Premiere Pro (version 14.2 in this case).
See here:
I'm sure I'm missing something here.
@reinecke I'll check again tomorrow but what I was getting was just the clip before the cut. The other was thrown away by both otiocat and otioview
Now I cant reproduce it anymore either. Must have been some glitch in the matrix or a venv with some old version. Closing the PR
So this caused an issue again and I can reproduce it. If applying my fix it reads it correctly
Will try and write up more detailed reproduction steps soon
The problem seems to stem from how Hiero/NS decides on the id for files. If you have a track in Hiero/NS that looks like attached picture then it will write out a xml with the same id for all files:
<file id="Juliet">
This causes all clips having mediareferences to file with id= "Juliet" to all have the same media_ref instead of unique.
media_ref = c.media_reference
media_ref will be the same for both clips from picture even tho they actually reference different files.
Got some days off next week so I'll check on getting the CI to complete successfully then and rebase on current main branch
Dealing with out-of-spec files is always tricky. I'd love for the Foundry to address this case, but it would still be hard to address all the out-of-spec files floating around. Hopefully the solution I pitched may be helpful.
I'll throw an email to the foundry and see if they have any plans to follow the xml standard. If they are we can probably live with just having our hacky patch applied for a while until they do.
I'll throw an email to the foundry and see if they have any plans to follow the xml standard. If they are we can probably live with just having our hacky patch applied for a while until they do.
Even better, maybe they could adopt writing OTIO directly and we can be one step closer to deprecating the entire FCP XML adapter, pragmatic patch and all! 😉
I'll throw an email to the foundry and see if they have any plans to follow the xml standard. If they are we can probably live with just having our hacky patch applied for a while until they do.
Even better, maybe they could adopt writing OTIO directly and we can be one step closer to deprecating the entire FCP XML adapter, pragmatic patch and all!
I will for sure check the status on that as well. When I checked with em like a year ago it sounded like they where waiting for the C++ version but that is available now so they can't have that as an excuse anymore.
@Eiken does the new OTIO integration in Nuke 13 mean that this PR is no longer needed? https://www.youtube.com/watch?v=autieMqcgSU
Heiro and Nuke Studio both now have native OTIO support. I'm assuming that avoids this issue entirely, so I'm closing this PR. Feel free to re-open if this is still relevant.