I’ve been bringing in edited MLT files to use as an generic intro to my YT videos but I have been encountering some odd things which is making me wonder if there is a better method?
I found that the MLT clip I brought in lost one of it’s many filters (in this case a colour filter) and the playback became incredibly choppy with jerky sound (having already used it numerous times without issue).
Things got worse when I was in the middle of exporting the completed project (following an export that did not render the imported MLT part correctly) and I cancelled the export mid-way. This seemed to corrupt my project with the sound, clips and transitions getting moved all over the place (which I unfortunately saved before I noticed and so lost a whole day’s worth of editing).
I can’t help but think it was the MLT import that was upsetting things.
Would I be better off rendering clips and importing a video file instead, and if so, which file settings would be best? I tried a lossless H264 but I don’t think I did it correctly as it did not render properly.
I have an intro and an outro for all of my YT videos; once made, they are simple and easy to use.
In my case, I also have several templates for making title PNGs with transparency in The Gimp, which I then overlay on top of the intro clip.
I have for a long time wondered why some prefer to import an MLT as a clip; I have yet to understand what advantages that MLT-as-clip method might have over a rendered clip.
I assume a rendered clip should run more smoothly when editing but it means that you’ll be effectively rendering that part twice, so obviously a lossless clip would be preferable. But I’m not sure which format/settings would be best?
When you create an MLT file, you create it with a project video mode. That video mode stays with the MLT file. When you import an MLT file as a clip, it is very important that the project video mode matches the video mode that the MLT clip was created with. It would be good to double check that the video modes match. Maybe they do not match and that is causing a problem.
Thanks. I think you could be right. I just checked and the background video clip is only 25fps. I’ve only just learned about making sure to set up the video mode / FPS at the start of a project so will make sure it’s the first thing I do from now.
I would say space, time, and accuracy considerations. If I could group/link tracks, that would be the better solution, but I don’t think that can be done yet. If you know of better way, then perhaps you can tell me how you would handle my workflow:
Record video through microscope, using audio cues to notify myself of objective lens changes.
In MLT file #1, apply appropriate scale bar overlays to video sections based on the audio cues I made.
In MLT file #2, import MLT file #1 and chop/trim footage to the clips of interest.
If you insisted on doing everything in a single file, I guarantee there would be mistakes where you didn’t slice through and delete all the corresponding track sections, which would desynchronize the footage from the scale bars. Ultimately, what it comes down to is that there are tracks that have to undergo identical treatment, and using nested MLTs is the easiest way I could see to do that. Having to export MLT #1 first would only succeed in doubling the hard drive space requirements.
A possible disadvantage to this approach is MLT file format compatibility.
Let’s say you made that intro a year ago. That would have been Shotcut v20.05.whatever and now it’s being imported into Shotcut 21.05.18. If there have been any breaking changes to the MLT format or its interpretation during that year, your intro quits working.
An example of this is the way blending changed around 18.03.06 when keyframes were introduced, and the “compositing” track head button was removed. Old projects didn’t render the same as new projects. A pre-exported video would not have this concern because video is just video.
Also, a pre-exported video can be turned into a proxy to speed up your editing. The MLT clip cannot, last I checked.
Also, a single video file is easier to archive with your project than copying all dependencies of a separate MLT project. That’s a big deal if you’re archiving then need to restore a project later, such as a “greatest hits” compilation.
An intro is probably short enough that even a lossless file wouldn’t be prohibitive in terms of disk space. But the intermediate formats like ProRes and DNxHR are also designed for this purpose and take less space than lossless. Lossless H.264 is also a good option, but hardware encoding will probably have to be turned off unless you’re sure your GPU supports lossless mode (many do not).
Ripple All Tracks seems like it would handle your scenario perfectly. Apply scale bars to the source video, then split and ripple remove the dead air across all tracks.
I can see where there is a space consideration, when one is doing many sets new source material, each time doing a pre-edit on one file before combining it with another.
But that is not the case the OP is discussing.
The context is when there is one edit of one boilerplate into for many following videos.
In that case, if space is a consideration, after the intro is exported, the originals for the intro can be offloaded. Only the exported intro needs to be retained on the working disk.
For accuracy, I can begin to see one advantage, which only applies if the work done on the “MLT file #1” is done on a single track only.
That is, that filters on that one track are retained, and can be manipulated in the Source window in the project where it imported.
But again, I do not think this is the case under discussion.
In my intro (and I believe this is also true for @RowZed’s intro), the intro is created on many tracks.
I just now did an experiment, I imported an MLT of a project with multiple tracks into another project. I could see and manipulate, in Source, the filters on the V1 track of the MLT-imported-as-clip, but not the filters on the other tracks of the MLT-imported-as-clip. So that “advantage” applies only to one very limited case.
But if that limited case is the majority of ones work, then i can see an advantage there, as a pre-setup of filters on single tracks.
Sort of. The biggest problem with using multiple tracks (that must remain synchronized) in a in a single file is when you want to rearrange clips. I do not know an elegant way of rearranging clips from multiple tracks in Shotcut. It’s easy enough on a single track, but as soon as you want to rearrange multiple clips that have to stay together (same track or different tracks, for that matter), so far as I can tell you kind of need to do it one at a time, which introduces a lot of possibility for error.
Excellent point about the version changes, which I didn’t consider. I have now been exporting Lossless H.264 (default settings at 60 fps) to use instead but have been finding that sometimes they render fine and sometimes they don’t which is strange. I’ll try the ProRes and DNxHR instead. Thanks.
I do see the potential value of rendering clips that will be re-used over time as lossless video. Where I have found the use of imported MLT files to be super-helpful is in generating more complex editing - in other words, as part of one large editing process. Probably it reflects my limitations more than anything else, but a time or two I could not achieve what I wanted in one MLT file … but it was easy to achieve by breaking it down into pieces. Since it was all part of one larger project, the resolution and fps were the same, and using the MLT files meant not having to render and re-render and re-re-re-re-re-render something that I didn’t get right the first time - just change it as a MLT file and voila, it is already ready to go in the higher-level file that imports it.
Now that makes sense, if I understand you correctly.
It appears you are speaking of a partial (I’ll call it “MyBranding”) that cannot be judged except in the context of the whole project (MyVideo).
(I am assuming here in both cases that either MyBranding.mlt or MyBranding.mp4 occupies one track of the MyVideo project already)
So for a corrective edit -
Workflow “L”:
Open MyBranding project
Edit MyBranding
Export MyBranding.mp4 using lossless codec.
Close MyBranding project - Open MyVideo project
(possibly edit MyVideo)
Export MyVideo.mp4
Judge results
—repeat—
Workflow “M”:
Open MyBranding project
Edit MyBranding
Close MyBranding project - Open MyVideo project
(possibly edit MyVideo)
Export MyVideo.mp4
Judge results
—repeat—
By eliminating “Export MyBranding.mp4”, time is saved, especially if one is able to sufficiently judge the edit in Preview.
OK, I can see how, in such a scenario, there is an advantage.
