• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
0

How to export an EDL from a timeline using ExtendScript

Enthusiast ,
Feb 20, 2018 Feb 20, 2018

Copy link to clipboard

Copied

Is this possible?

TOPICS
SDK

Views

2.4K

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines

correct answers 1 Correct answer

Adobe Employee , Feb 23, 2018 Feb 23, 2018

The PPro API offers no direct EDL output.

It had been more highly requested a few cycles ago, but (I'm told) those requesters decided to export FCP XML instead.

For what specific flavor(s) of EDL, are you hoping? To what workflow(s) would you like to feed EDLs, from PPro?

Votes

Translate

Translate
Enthusiast ,
Feb 22, 2018 Feb 22, 2018

Copy link to clipboard

Copied

So far I've found

app.project.activeSequence.exportAsFinalCutProXML(fullPathToOutputFile, 1);

app.project.activeSequence.exportFramePNG(time, fullPathToOutputFile);

app.project.activeSequence.exportAsProject(fullPathToOutputFile);

app.project.activeSequence.exportAsMediaDirect(fullPathToOutputFile, outPreset.fsName,appencoder.ENCODE_WORKAREA);

But still looking for something along the lines of

   app.project.activeSequence.exportAsEDL(fullPathToFile,EdlSpecs);

Bruce Bullis? Would you and team have any insights?

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Feb 23, 2018 Feb 23, 2018

Copy link to clipboard

Copied

The PPro API offers no direct EDL output.

It had been more highly requested a few cycles ago, but (I'm told) those requesters decided to export FCP XML instead.

For what specific flavor(s) of EDL, are you hoping? To what workflow(s) would you like to feed EDLs, from PPro?

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Feb 23, 2018 Feb 23, 2018

Copy link to clipboard

Copied

The goal is to produce an accurate report of all items in a timeline -- all Source Names, Source TC Starts & Ends, Timeline TC Starts & Ends -- including (and this is key) those sources that have been sped up or slowed down in the timeline.

We got most of the way there by iterating all clips in the timeline using an approach hinted at here...

Samples/Premiere.jsx at master · Adobe-CEP/Samples · GitHub

under the randomizeSequenceSelection method, so the algorithm works using logic along the lines of.... (abbreviated for clarity, not accurate syntactically)

app.project.activeSequence.videoTracks[0 thru numTracks].clips[0 thru numClips]["name","inPoint","outPoint","start","end"]

app.project.activeSequence.audioTracks[0 thru numTracks].clips[0 thru numClips]["name","inPoint","outPoint","start","end"]

That process, however, misreported Source TCs for timeline items that had been sped up or slowed down.

Notes/questions on that issue here...

Timeline Clip Properties inPoint and outPoint give inaccurate results when clip speed / duration not...

PPro EDL exports, by contrast report Source TCs accurately even for sped/slowed items BUT they can't be exported programatically.

I haven't fully tested exportAsFinalCutProXML, if only because parsing XMLs gets involved and laborious

The ultimate goal here is to be able to do timeline-based reporting, including footage use etc.

Frankly I'd prefer iterating the timeline over exporting/parsing an EDL, but I'll take either.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Feb 23, 2018 Feb 23, 2018

Copy link to clipboard

Copied

Premiopolis  wrote

The ultimate goal here is to be able to do timeline-based reporting, including footage use etc.

Frankly I'd prefer iterating the timeline over exporting/parsing an EDL, but I'll take either.

Potentially helpful/relevant: The CueSheeter sample walks across the open sequence, looking for .wav files, and then writes a report.


https://github.com/Adobe-CEP/Samples/tree/master/CueSheeter

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Feb 23, 2018 Feb 23, 2018

Copy link to clipboard

Copied

https://forums.adobe.com/people/Bruce+Bullis  wrote

Potentially helpful/relevant: The CueSheeter sample walks across the open sequence, looking for .wav files, and then writes a report.

https://github.com/Adobe-CEP/Samples/tree/master/CueSheeter

Thanks for that one, Bruce.  Fascinating.

So getting your Active Sequence using

    qe.project.getActiveSequence()

          and

    app.project.activeSequence

Gives access to different sub-properties and methods?

In other words using your above-suggested "CueSheeter" approach I was able to access the following track clip properties:

name, start, end, duration, speed, reversed, type, mediaType, frameBlend, timeInterpolationType, scaleToFrameSize, multicamEnabled, numComponents

Whereas the approach I had been using gave props

name, start, end, inPoint, outPoint, duration, type, mediaType, projectItem, components

So on the one hand Cue Sheeter brings great news: speed -- just what I was looking for.

But it loses inPoint and outPoint, which is also key info.

We gained essential Source Clip Speed at the cost of the equally essential Source Clip TC In / Out.

I'll run some tests later, but in the meantime do you have any have-your-cake-and-eat-it-too for this?

Again, huge thanks.  Very helpful.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Feb 25, 2018 Feb 25, 2018

Copy link to clipboard

Copied

Yes, QE DOM and normal DOM elements are completely distinct.

That 'cake' won't be ready until our forthcoming release.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Feb 25, 2018 Feb 25, 2018

Copy link to clipboard

Copied

LATEST

https://forums.adobe.com/people/Bruce+Bullis  wrote

Yes, QE DOM and normal DOM elements are completely distinct.

That 'cake' won't be ready until our forthcoming release.

Very much looking forward to that.  ETA?  Would be fantastic.

Here's a bit of additional discovery:

After building a routine that iterates a sequence using both the "Normal" and "QE" methods simultaneously, in the hopes of heaving and eating a cake of my own, the following issues popped up:

The QE approach seems to intermittently fail at returning proper Program TC and clip names.  Sometimes getting it right, sometimes wrong.

e.g. returning clip name "undefined" at times and getting completely the wrong start and ends that seem to relate to nothing

e.g. picking up readings on filler at seemingly random intervals

By contrast the "Normal DOM" approach seems to consistently iterate the clips accurately without fail.

When the QE approach does work it returns ever so slightly different Program TC results than the Normal DOM approach.

e.g. Where Normal Start time might give Program start of 20.0416666666667, the QE method, for the same edit shows it starting at 20.0416679382324, a little over a millionth of a second difference, so not practically different, but different.

Overall it seems the Normal approach seems more reliable and robust than the QE approach, and trying to run and coordinate both approaches in order to use the "speed" property from QE to fix the "inPoint" and "outPoint" error from the "Normal" is no easy task.

Would a Feature/Bug request be helpful here?

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines