-
Notifications
You must be signed in to change notification settings - Fork 282
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AAF Reader: Incorrect Clip Source Times #523
Comments
@jminor , @ssteinbach , @freesonluxo , Upon further inspection, I seem to have tracked down what appears to be causing the issue... or, at least, what is an indicator to the underlying issue. For the clips where the I was then able to simply add some text to the |
Hi @andrewmoore-nz, Thanks for the super detailed bug report! Do you know if this a regression from the most recent checkin? |
Heya @ssteinbach ... no worries. Trying to give all the info I had was the best way for me to try and make sense of it myself. Prior to the latest commit - #517 - we weren't able to actually read these AAFs at all, due to the Can send through some example AAFs for you to check out, but would prefer to do so through a private channel. |
Hey guys. Just wanted to give this issue a bump, as it's something that's just come up again trying to actually use a Media Composer AAF through OTIO. Any thought perhaps as to what might be happening here with the |
Sorry for the delayed response, @andrewmoore-nz. We're focused on landing the C++ branch and haven't been working on the AAF adapter these past few weeks. Do you have a work-around for this? Are you able/willing to dive into the AAF adapter code to try to fix this? My suspicion is that either the auxiliary timecode, mark in/out, or structure of how the clip refers to the tape-based media could be the culprit. There are some heuristics in the AAF adapter that attempt to find the correct start timecode which are likely not doing the right thing in this case. I have reached out to Avid for some guidance on understanding how timecode is represented in cases like this, as well as a few others (timing effects). I'm not sure when we'll hear back from them. If you can send example AAFs that aren't sensitive that would be ideal. |
Hey @jminor , Apologies for the delay on this one... just circling back around to look at some of the AAF issues still on our radar. I've got some examples of this that I'm able to send through, yes. I'd prefer to do it through a private channel though if possible. |
@andrewmoore-nz provided me with some test AAFs. File 1 has the correct timecode values as parsed by OTIO, and File 2 has incorrect values. I put a breakpoint just after this line:
Looking at the mobs found by Loading file 1:
Loading file 2:
I don't have any conclusions based on this, but it certainly seems that for some reason the timecode info isn't being hinted correctly, however there are some EdgeCode information. I'm not sure what role that should have in this context. I'll keep digging, but would love some thoughts from those more familiar with the AAF data model. |
@markreidvfx might have some insight into this |
These PRs still look like they're in progress, going to push them back a release. |
@stefanschulze @andrewmoore-nz did this stuff get folded into some of the PRs that were landed? #739 for example? |
@ssteinbach Heya. Doesn't look like #739 fixes any of these issues, no. Have just had a quick look at PR and it doesn't appear to be addressing any of the issues that are fixed in my PR. Have tried getting some input from people several times on that but to no avail. |
Referring this over to https://github.com/OpenTimelineIO/otio-aaf-adapter - all new development on the AAF adapter is being done there. |
Here's a branch porting this to the new adapter - @markreidvfx says it still needs some work: https://github.com/markreidvfx/otio-aaf-adapter/tree/AAF_Src_Timecode_Parsing |
So, bear with me on this one... it's a little complicated; a little confusing; and I'm still trying to piece together as many of the exact details as I can.
I'm just starting to notice a very serious issue with
available_range
's in a clip'smedia_reference
(andsource_range
) coming through from Media Composer AAFs.There appears to be inconsistency in when the the correct
start_time
is used from the underlying AAF data. I am yet to see a specific reason/pattern as to when this is happening, so best I can do at this point is just give as much info as I can for the situation.ExampleClip_col_mat12_v025_p005
This clip has source timecode values of In:
00:00:41:21
and Out:00:01:08:16
, but theavailable_range
/source_range
object generated by OTIO comes through as:Using this info, we get source timecode values of In:
00:00:00:04
and Out:00:00:26:23
. The correct timecode values above were generated by opening the AAF in Media Composer and exporting EDLs, and the incorrect timecode values (theavailable_rage
object) were generated by reading the same AAF using OTIO.Consulting this specific clip's info in the Media Composer bin we see:
From this, it appears that the
Start (TC)
andAux TC1
fields are being ignored, and simply the frames being used are determining theavailable_range
- frames 4 (00:00:00:04
) through 647 (00:00:26:23
) of the total 651 available.The inconsistency appears then looking at another version of the same clip that exists below this one on the multi-track timeline....
ExampleClip_col_v024
This clip also has source timecode values of In:
00:00:41:21
and Out:00:01:08:16
, but theavailable_range
/source_range
object generated by OTIO comes through correctly as:...and this specific clip's info in the Media Composer bin:
From this I might think that it perhaps has something to do with the
Mark In
field that has been set on the clip, but there is also another clip here (again, a different version of the same clip stacked underneath) that has these fields set:...and again the
available_range
andsource_range
objects are not correct, with a value of:...for both.
I have put together some examples files as best I can given the sensitive content of the AAF that these errors have come from. There is a screen shot of the relevant Media Composer clip info and the OTIO Clip schema for each clip, along with a screenshot of the Media Composer bin and the EDL info that MC exports for these clips.
AAF_SourceReadingError_ExampleFiles_190603.zip
Unsure as to whether this may be more something to address with PyAAF as opposed to here, but figured it worth raising the issue here so everyone's aware and see what the best approach to figuring out a solution might be.
The text was updated successfully, but these errors were encountered: