Locators/markers timecode in cmx3600 and otio formats

[jafyvilla]

Hi all,

If I'm not mistaken, OTIO stores the EDL information without absolute time codes for the edited timeline, but using durations instead. That is, it keeps an ordered list of gaps and clips and accumulates their duration, so we don't have the explicit start time for each segment (although we can compute it easily if we have all the data, as it is implicit).
This is becoming problematic in the case of the locators in the cmx format. From the screening_example.edl, the position of the first marker is specified as:

004 ZZ100_50 V C 01:00:10:01 01:00:14:20 00:59:58:00 01:00:02:19

• FROM CLIP NAME: ZZ100_504C (LAY1)
• LOC: 01:00:01:14 RED ANIM FIX NEEDED

That is, using a time code in the absolute range (edited timeline). If we use the cmx adapter to read it as 'otio', that same time code is used, but it does not mean anything in the OTIO world, because we lost all the rest of absolute time codes. After conversion, it looks like this:

"start_time": {
"OTIO_SCHEMA": "RationalTime.1",
"rate": 24.0,
"value": 86438.0 # corresponds to 01:00:01:14
}

Then, after this point, every time we want to use this otio edl, this marker won't be read correctly. For example, trying to visualize it with the otioview.py tool, it won't be displayed, as it tries to place it in the clip range and that value is out of it. Also, if we try to save it back in the cmx format, it will be written as:

004 AX V C 01:00:10:01 01:00:14:20 00:00:04:13 00:00:09:08

• FROM CLIP NAME: ZZ100_504C (LAY1)
• LOC: 01:00:01:14 RED ANIM FIX NEEDED

which is incorrect, as it is using the original absolute time code, and in the new cmx edl the start-end range of the corresponding clip changed, so the marker falls out of it again.

I'm not sure if this behavior is the expected, but in my opinion the absolute time code of the markers should also be stored as a relative time code within the corresponding clip, so we can always convert it between ranges and formats. I have a fix that does this, and works for my use cases, but I wanted to check with you guys to see if I'm missing something (I started with this a few days ago, so I might be confused) or it is an actual problem. If this is the case, I could push my changes and send a pull request.

Thanks in advance.

[jminor]

Thanks for the detailed bug report!

OTIO supports markers at the clip level, at the sequence level, or on any other subclass of Item. In this case it sounds like the EDL adapter is not doing the right thing with the markers. It should either put them at the sequence level with a time value relative to the whole thing, or it should put them inside the clip with a time relative to that clip. Currently it does a mix of the two which is incorrect.

In your use case, do the application(s) making or consuming EDLs support markers at the clip level vs the sequence level? I'm not sure if there is a way to distinguish the two in an EDL, so we might have to just pick one.

Either way, we should provide some sample code for moving a marker from a clip to the sequence and vice versa to illustrate the difference.

If you have a fix already, you can make a pull request so we can look at it in detail.

[jafyvilla]

@jminor thanks for your reply!
So far, we evaluate markers in cmx3600 EDLs at a sequence level, but we still don't have a real life definitive use case, so I think we can adapt to any of both alternatives. In our provisional fix, while reading, I convert the time code of the marker and use a time relative to the clip where it is placed. Then, if needed, I convert it back to absolute, e.g. for writing in cmx format.

I'll try to make a pull request in the following days, so we can discuss further after you have a look.

[ssteinbach]

@jafyvilla Did you get this worked out? Its been quiet for some time, just wanted to clean out old issues in the issue tracker.

Thanks!

[jafyvilla]

Hi @ssteinbach, sorry for the late reply, I overlooked your comment.
Unfortunately I had to stop working on this for some time but during the next few weeks I'll probably need to get back to it. I will post an update if I face the issue again, and if my patch does the trick I'll send a PR.
Thank you!