How to get the Timecodes of footage used by a sequence, similar to an EDL's values?

Forum|Forum|4 years ago
March 12, 2021
2 replies
1812 views

I am developing a plugin that shall generate a text file for the purpose of documenting the _used_ footage. It's for a media design company that needs to know which and how much "foreign" footage it used.

For this purpose, the plugin needs to learn the actually used range of frames, or their TCs, of the footage that's references in a sequence.

How do I get to that information?

I know how to learn of the original footage tracks, but I have a hard time determining the TCs, especially if the footage is embedded into the sequence at a non-trivial time scale. For instances, if it's using speed-ramp, I cannot simply take the TCs from the track, as they do not directly translate into the range that they're taken from the footage (1s of play time in slo-mo) may mean that it's 10s in the footage - and that's the timing I need in order to know how much needs to be credited to the original footage.

When I export a sequence to EDL, then these TCs are right there, though! This means that there's code in Premiere that can calculate these values. The question is simply how I get to them from a plugin.

SDK

This topic has been closed for replies.

Bruce Bullis

Community Manager

You mention writing a 'plug-in', which are created in C++; I think you're writing an extension, in ExtendScript/JavaScript.

You can get the source media in/out points from the trackItem object, but as you point out, there are complexities.

Confirming: Even for time remapped track items, the values exported in an EDL are correct?

T

tempelorgAuthor

Inspiring

Bruce,

Yes, I mean an extension.

Confirming: Even for time remapped track items, the values exported in an EDL are correct?

Yes, that was my impression so far. Do you think I got this wrong, or are you not familiar with the content of EDL files?

T

tempelorgAuthor

Inspiring

That's possible today.

Test setup:

Project with one media item, many seconds long
Set in point at 00;00;10;00 and out point at 00;00;11;00.
Insert edit that one second, into a new sequence (thereby creating a trackItem)

var clip = app.project.activeSequence.videoTracks[0].clips[0];

if (clip){
    var start = clip.start;
    var end = clip.end;
    var inPoint = clip.inPoint;
    var outPoint = clip.outPoint;
}

In [above], start and end are the sequence time range occupied by the trackItem, and inPoint/OutPoint refer to the time range, in the original projectItem.

Alright - here's what I found:

It appears that

app.project.activeSequence.videoTracks[].clips[].inPoint.seconds

gives me the same value as I find in the EDL.

However:

When I use a time remapping operation on the clip, then the inPoint/outPoint values get shifted, and that appears to be totally wrong, i.e. a bug, in Premiere.

Reasoning: The clip's in and out points should be telling me which part of the original clip is actually appearing in the rendered sequence, right?

I've attached two sample projects that demonstrate this suspected bug. Yikes - why can't I attach projects here? Even as a zip file??!

Well, it should be easy to reproduce anyway: Make a new project, new sequence, add a clip.

Check the outpoint. I am using PropertyExplorer. If the clip was 10s long, then

app.project.activeSequence.videoTracks[0].clips[0].outPoint

gives me 10s, as expected. Same value I get when I export to EDL.

Now right-click on the clip in the sequence view, choosing "Speed/Duration". Change Speed to 50%.

Check the outPoint again. It's now 20s! And that's not right, as it suggests that the clip has 20s of content, but it only has 10!

The EDL, however, still shows the correct outpoint of 10s. That's the discrepency I had noticed: The EDL is correct, the clip's start/endpoints are not.

And I have even more complex examples that use time remapping / speed ramps, where it all gets even worse (if I could just attach them here). There's no way I can calculate the correct in/outpoints in these cases myself.

That's what needs to be fixed or where the API needs to be improved.

Can you confirm my findings? If so, do you agree that the moving in/outpoints for the clip are a bug?