Incorrect EDL in multi-fps playlists

[cedrik-fuoco-adsk]

Incorrect EDL in multi-fps playlists

Linked issues

n/a

Summarize your change.

The calculation of the frame and out properties in the EDL was incorrect for playlists containing clips with varying frame rates.

In _get_in_out_frame, the values for the in and out frames were not what RV is expecting. For all playlists, the in values must be the start_time of the clip at its rate - not the rate of the sequence/timeline (which is the rate of the first clip).

For the out value:

• In multi-fps playlists, it should be start_time at the clip’s rate plus the duration at the sequence/timeline rate.
• In single-fps playlists, it should be the end time (inclusive) at the clip’s rate (no conversion needed).

For the frame value in the EDL, I based the implementation on what RV is doing here:

OpenRV/src/lib/ip/IPBaseNodes/SequenceIPNode.cpp

Lines 785 to 800 in 673f2b7

	int accum = 1;
	for (int i = 0; i < ins.size(); i++)
	{
	const ImageRangeInfo& info = m_rangeInfos[i];
	const int start = useCutInfo ? info.cutIn : info.start;
	const int end = useCutInfo ? info.cutOut : info.end;
	(*m_edlGlobalIn)[i] = accum;
	(*m_edlSource)[i] = i;
	(*m_edlSourceIn)[i] = start;
	(*m_edlSourceOut)[i] = end;
	accum += (end - start + 1);
	}

Describe the reason for the change.

The current implementation of the EDL calculations for the frames and out were wrong. The values were not what RV was expecting. The original issue was that the clip were stuck at the last frame of the clip because the EDL values are wrong.

Note:
There are some cases in a multi-fps playlists where RV and CR does not interpret a frame calculation the same way. For example, RV will do a calculation similar to a floor() while CR will be a ceil()

Describe what you have tested and on which operating system.

MacOS, Linux

Add a list of changes, and note any that might need special attention during the review.

If possible, provide screenshots.

[pbergeron-adsk]

Ok, but can you specify in your pr comment what are the other issues you intend to fix in other PRs?

[cedrik-fuoco-adsk]

It's one specific issue. There are some cases in a multi-fps playlists where RV and CR does not interpret a frame calculation the same way. For example, RV will do a calculation similar to a floor() while CR will be a ceil(). There are no fix until we decide which one is right. @bernie-laberge and me decided to deal with that later.

[bernie-laberge]

LGTM
Please add the repro steps of SG-38200 for the post checkin test just to be safe.

Comment has been added