Timecode support for EDL Export


#1

I am very impressed with what Shotcut can do, especially for a free program. On a lark, I found you can export and .edl file and load it into Adobe Premiere Pro. The only problem is the lack of timecode. In Premiere Pro, the clips are in the correct order but they all start from the first frame of the clip, not the in and out you set in Shotcut. If you can fix that issue, it would be huge for the industry. We could do rough cuts in Shotcut and finishing in Premiere Pro, or other editing programs. I am a journalist that writes for a major industry publication that talks production and Post production. If you can make this work, I have been approved to do an article about Shotcut. I’m ready when you are!

While you are at it - In addition to .EDL files, if you could export as Final Cut .XML files, I think Premiere Pro reads the transitions better. However, reading clip timecode is an absolute priority, and will get you more users.


#2

What import settings are possible in Premiere Pro? I can import edl files from Shotcut in Resolve with these settings: Lost timecode XavcS

You can open the Shotcut-edl in ex. notepad and check if the time codes matches your cuts in Shotcut. If they match, it may be a PP import problem.


#3

ShotCut starts every clip I import from 0:00:00:00. So when I imort the EDL into Premiere Pro it starts every clip from the first frame, and cuts it at what ever the duration is in ShotCut, making the in and out points way off. The only way to make it acceptable for any pro needs would be to have the timecode read. Is that a big deal?


#4

Shotcut does not use embedded time codes or embedded reel names in source files. However I guess you can import the edl in Resolve with the suggested settings and then save the edl with embedded time codes from there, if pp has no edl import settings?

I’m not a coder of Shotcut, so I can’t tell you how much effort it would take to implement it.


#5

I’m not sure how to attract more attention here but I am having the same issue. I am a professional video editor and I really like the idea of using shot cut on different projects or as a front end to my MLT workflow automation. Is there anyway to insist on using source based timecode? It’s really the main thing keeping me from using this otherwise great application for my work.


#6

No. However Resolve can import using framecount instead of embedded timecodes(but doesn’t import audio clips from EDL). Or you can use Eyeframe Converter to quickly zero the embedded timecodes of the source lips like this:


#7

Thanks for the reply. I visited the thread you mentioned and am aware of zeroing the embedded timecode. I’m new to this software and it’s preferred workflow but I’m wondering why there isn’t a way to reference the starting timecode from the metadata. Even in Shotcut’s own clip metadata panel it displays the embedded start timecode. What’s the reasoning behind not using source TC? Unfortunately the work I do involves referencing the embedded TC so zeroing out is not an option. Is there some limitation in MLT or Ffmpeg that is causing this or is it a choice by the developers? I appreciate your insight.


#8

I’ve done a simple test both into Premiere and Resolve using the ‘export EDL’ feature in Shotcut. Both as expected do not import the correct clip segments that were selected in Shotcut. This does not seem correct to me. Using melt I can generate an xml of the clip data that clearly references the embedded timecode;
<property name="meta.attr.0.stream.timecode.markup">00:00:49:03</property>
If there were a way to reference this attribute when creating the EDL, Shotcut would rapidly become a contender for post production pipelines. Otherwise, I will need to create a ‘corrected’ EDL using melt and some scripting. Is there some way to make an official request to Shotcut developers?


#9

What do you mean by official? There are thousands of requests in the forums but only a little more than one developer. Most users are not interested in working with embedded timecode and want more stability and performance. Your request is heard but barely over the crowd. Generally, feature requests are not accepted, and I work against my road map and inspiration, which comes at times from the forum.


#10

I’ve done a simple test both into Premiere and Resolve using the ‘export EDL’ feature in Shotcut. Both as expected do not import the correct clip segments that were selected in Shotcut.

In Resolve, did you use the “Use Timecode > From source clip frame count” mentioned here: Lost timecode XavcS - That should give you the correct timings.

If you’re able to code, maybe you can make a commit adding this feature to the Shotcut project(if Dan agrees?). The EDL generating code is written in node js as far as I know?

Alternatively, you can contribute to the MLT adapter of this project(for conversion to ex. edl, fcpxml or aaf) : https://github.com/PixarAnimationStudios/OpenTimelineIO/issues/267


#11

Thanks for the reply and insight. I was not aware of the development on shotcut until now but I am impressed with it’s capabilities. Most NLE workflows utilize the embedded timcode so imho an exchange format should do the same. It could simply be an option of ‘Export EDL.’ the times used in the shotcut mlt xml playlist would stay as is but the EDL would reference the metadata timecode property. I am familiar with Python and somewhat with JavaScript so if I can contribute in any way that could potentially solve my problems at least.


#12

I did not try that feature of Resolve but I’ll give it a go. Thanks!

Also, I just stumbled upon the OTIO project and it looks promising.


#13

If Resolve does not work out for you, and you need a quick here-and-now code fix, maybe my very old mlt2edl python script only needs a few changes to fit your purpose: https://eyeframeconverter.wordpress.com/mlt2edl/ Though contributing to Shotcut or OTIO would help other people out too.


#14

Basically, take the “meta.attr.0.stream.timecode.markup” mentioned before and add it to all timecode values for that clip?
This cannot be done simply in the export JavaScript code. That code simply converts the MLT XML with no access to Shotcut or MLT APIs. Some C++ code before it needs to make a copy of the project and compute the new time values that will appear in the XML.


#15

I don’t think it would need to be applied to all timecode values of the clip. Just to the in and out on the EDL if that option is specified. Either way I think I understand the limitation. It seems the only way to have it work would be to have the metadata timecode value as an attribute in the original mlt XML. Is it possible to have the embedded timecode element in the xml in a way that doesn’t affect Shotcut’s functions but can be referenced by the EDL exporter? Or would that be considered too much of a complication?


#16

https://mediaarea.net/en/MediaInfo can also be used as a command line tool to extract time codes and reel names. Actually you may also need the embedded reel names inserted into the EDL files for fail-safe EDL import in ex. Lwks(which doesn’t read the commented lines in th EDL files).


#17

Yes, quite easily with a small modification. The export script uses this timecode library that also makes it possible to add timecodes. The XML would also contain the source clip’s framerate that could parsed out for interpreting that timecode as time.


#18

This seems like a perfect solution in that case. Would someone need to submit that or could it be implemented easily in a subsequent update? TBH I’m not entirely familiar with the development process.


#19

Two clarifing questions:

Did you manage to import the EDL correctly in Resolve with the frame count setting?

Does Premiere use the embedded reel names to locate files? If it does then the reel names must be extracted from the source files too.


#20

I have yet to test the Resolve setting but will do so today and share my experience.

For Premiere’s EDL, the file name is referenced but not the full path. Using Premiere’s relinking tools makes quick work of rebuilding the timeline. I think using the file name makes the most sense since most exchange situations will reference the file name and path for importing clips. Ideally, the option to specify an EDL based on either clip TC or embedded TC means that a user can better target their specific pipeline.