Locators/markers timecode in cmx3600 and otio formats

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.

Start with the cmx adapter and the screening_example.edl described in the report, then inspect how marker timecodes are represented for OTIO timelines. Use otioview.py and a CMX round trip to check that markers remain within their corresponding clip ranges and retain their intended positions after conversion.

Written by the indexing model from the issue text.