Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
@Bruce Bullis can you assist @tempelorg?
Copy link to clipboard
Copied
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?
Copy link to clipboard
Copied
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?
Copy link to clipboard
Copied
I'm familiar with EDL files; I'm surprised that EDLs offer full source timecode information, for time remapped trackItems.
Copy link to clipboard
Copied
I must admit that I'm "only" the programmer. I do not edit Premiere projects myself, that's not my forte. Instead, my client provides me with real-world sample files.
So, with the little things I tried in Premiere, such as changing the frame rate of an included track, I had the impression that it would also affect the output of the EDL's.
Here's what I tried:
Track 1 uses a clip at normal play rate, for about 4 seconds. This results in an EDL entry as follows:
001 AX AA/V C 00:00:00:00 00:00:04:13 00:00:00:00 00:00:04:13
Then I changed the track's "Speed/Duration" to 20%, and then adjusted its length to play the same 4s seconds. Clearly, the footage is now using only a 5th of the source. And the EDL reflects that:
001 AX V C 00:00:03:08 00:00:04:05 00:00:00:00 00:00:04:13
Or do I misinterpret the first two TCs?
Copy link to clipboard
Copied
That seems correct.
Copy link to clipboard
Copied
Thanks for confirming. However, marking my own explanation of what I'm doing as the Correct Answer is not helpful, as I still have no answer to my actual question.
So I guess there is no solution, i.e. there's no Extension API that gets me the information that I need?
Is there a way to request this being added to the API? My client is a large media producer and has more than a few licenses of Premiere Pro.
Copy link to clipboard
Copied
Your solution, computing the result from the data provided in the exported EDL, seems correct. There is no API which will allow you to get the parameters used in speed adjustments for trackItems.
We're tracking your API feature request as DVAPR-4230269, and will keep you informed of our progress.
Copy link to clipboard
Copied
You seem to have entirely misunderstood my request:
@Bruce Bullis wrote:There is no API which will allow you to get the parameters used in speed adjustments for trackItems.
I never asked for that. I am asking for the footage TCs of the used clips. What's in the EDL. I don't want the speed adjustment parameters (which, BTW, I have ways to find) because that would require me to calculate the TC values myself - but that's exactly what I do NOT want because that's a can of worms I can never be sure to get correct for all cases.
So I'm now afraid that the request you're tracking even got wrong what I'm asking, and thus will never get my what I need. Would you please share with me what the feature request actually request so that I can verify it gets it right?
Copy link to clipboard
Copied
DVAPR-4230269: Provide API to get speed parameters used on trackItems
This, together with the in/out point information already available via trackItems, should allow you to get to the values you're currently getting from the EDL.
Copy link to clipboard
Copied
The title is indeed off as I feared, because I'm not looking for speed parms but for the TCs of the inserted clips.
Would you please update it, using a title such as (I may not use the correct terms, though, so please fix accordingly):
Provide API to query the source time codes of a track's original clip.
And then add:
What is needed are the same TC values that are also provided in an EDL file: A track line in an EDL file contains four TCs: First two are the start and end times of the original clip, and the latter two specify where they're inserted in the final sequence. The latter two values can be queried with existing APIs, but the first two cannot, and those are what we need.
In other words, this is a request to have read access to the original clip's start and end TCs used by each track.
The purpose: We need to learn which parts of the footage clips are actually used in the sequence, e.g. in order to document the footage credits (and their lengths).
Thank you.
Copy link to clipboard
Copied
That's possible today.
Test setup:
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.
Copy link to clipboard
Copied
Thank you, I'll check whether this is what I need and report back (and mark it as the correct answer).
Copy link to clipboard
Copied
A quick test suggests that the clip values do not always give me the same values as I'd get from the EDL.
I will try to provide an example project with a tiny video clip that demonstrates the issue. May take me 2 days, though. I'll be back then. Until then, please keep this open.
Copy link to clipboard
Copied
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?
Copy link to clipboard
Copied
Also, I am not computing anything from the EDL values. It's the EDL values that I need, nothing more.
Copy link to clipboard
Copied
It would even be helpful if I could just have an EDL file generated from my Extension so that I could then parse it and extract the values from it, but that feature doesn't seem to exist either:
For a function that's already implement in the core code of Premiere, I find it really sad that it's not exposed to the scripting API if customers had asked for it in the past.
And the FCP export file does not contain the TCs I seek either, it appears.
Sigh.
Copy link to clipboard
Copied
Correct, there is no API for exporting EDLs; I've added your vote to that feature request.