Text and large projects

Hello everybody,
As a former software developer, an open source program like shotcut would of course be my first choice for my films.
But unfortunately there is no support for larger projects. Something like a structured playlist, markers and a search function for clips in the playlist and in the timeline.

It would help a lot if the following were fixed:
When I enter a text and add it to the playlist, I only see a black box with the name transparent. The same thing happens in the timeline. I have to click on it first to see what kind of text that is. This is very bad when I want to use a lot of texts.
In addition, one could divide the playlist into at least sections with visible texts: "
Scene 21, take 50, script on page 213, the murderer appears
Scene 22, take 56, screenplay page 230, the murder happens. etc"
You could drag these texts into an invisible track in the timeline and at least have a very simple connection to the playlist and the script. Isn’t that feasible in one of the next versions?
Or does someone have another solution how to manage over 200 source files sensibly?
regards
Robert Leininger
( Translate Google )

Name or rename them in Properties.
2020-11-02_13-21-08

2020-11-02_13-26-52

2 Likes

I make long films without issue, but I use an adapted workflow. The following description is not meant to invalidate your feature requests… this is simply to say alternatives exist if you need something fast in the meantime.

For starters, I absolutely never ever use the playlist for films. Maybe for family slideshows, but not for films. Managing the playlist is wasted time the audience will never see or appreciate. That media could have gone straight to the timeline and accelerated a finished product.

Instead of a structured playlist, I use a structured file system to organize my media. The media has file names that reflect the slate (scene 4 take 8 etc.) and I use file folders underneath the .mlt project file location to group related clips and scenes. If the file system is organized like this, a playlist becomes redundant. I know this is not Hollywood Standard and would not receive Netflix certification. But it’s still extremely effective. Search is done directly on the file system with the OS file manager, then videos are dragged directly onto the timeline (or source window for trimming) when ready for a new clip.

I haven’t needed markers because I almost never make a project longer than 20 minutes. I do a reasonable number of related scenes in a project, then export it as a segment. The next scene starts in a new project of maybe 20 minutes length. As a bonus, Shotcut performance stays snappy and responsive with the smaller projects. When all the segments are done, I stitch the exports together into the final hour-plus movie using FFmpeg concatenation. If there is a problem in a segment, only that segment has to be fixed and re-exported rather than the entire movie. Management is easier at all levels this way. If I make a bad ripple adjustment at the beginning of a project, I damage at most 20 minutes of movie. Had the entire movie been in a single project, a bad ripple could affect the ending and potentially go undetected.

We once did an 11-day shoot that generated around a thousand source clips, and had no problems with media management using this method. Most files we didn’t even bother to rename to match a slate because it was already easy to locate them with the folder structure, large file thumbnails, and if needed, a media player.

As for text, @Hudson555x provided a great workaround to that. But in our case, we don’t apply any text until after the rough edit is made, so text becomes a non-issue. There is no reason for us to label or search when it is created exactly where it is supposed to go in the first place.

2 Likes

This is a highly redundant suggestion. Also see Road Map.

Indeed. But this is one of only a few threads to offer a workaround, and now people can’t see it.

What makes you think people see anything that already exists given the amount of redundancy in this forum? :wink:

Touché. :rofl: I was thinking more in terms of support people that know this workaround is here and can direct future inquiries to it.

Hi Austin,

interesting workflow you describe, i would appreciate that.
When you export the segments what format / codec do you use to minimize quality issues?
I would try to avoid Multi-GB intermediate files as this slows down your computer and SC probably if you have too many segments.
Also the concatenation process with FFmpeg - how is it working? Is this without any quality loss? Isn’t that a tedious manual job?
I tend to use the playlist segment-wise with clips and images and after completing a longer scene, i delete it and use it for the next segment. A good directory and file management with speaking names is always a good idea for bigger productions :slight_smile:

Correct. Concatenation means to take the stream data in each segment and stack them back-to-back, then write a new container around all of them (MP4/MOV/whatever) that represents the new total length. There is no re-encoding of the actual stream data.

My selection of an export format goes one of two directions depending on the video being made…

If I’m making something simple like a senior graduation slideshow/video montage that is a long project but the audience is not professionally demanding, then I export the segments straight to the delivery codec. Since there is no re-encoding of the segments (and therefore no intermediate files with quality loss issues), I use whatever is specified as the final delivery codec, usually H.264 or ProRes or DNxHR. The concatenated video will look identical to a monolithic export from one large Shotcut project.

However, if the project is required to have an archive-grade master or if the project needs to be delivered in multiple formats, then I will export the segments as Ut Video and concatenate them into a Ut Video master. Generational loss doesn’t happen because the master is a lossless file. With a lossless master, I can now transcode an XDCAM file for one TV station, a ProRes file for another TV station with different ingest requirements, and a downscaled H.264 file for smartphone viewers. Transcoding a master file is significantly faster than doing three separate exports out of Shotcut. I do the transcodes with FFmpeg command line, not Shotcut.

Putting together the statements above, simple projects that have segments exported directly to the final codec format do not produce any intermediates. But complex projects that require a lossless master or require delivery in ProRes/DNxHR format are going to be multi-GB by nature, and it’s the cost of doing business with that client.

Provided the export destination is RAID or SSD or NVMe or something relatively fast, Shotcut can export to Ut Video much faster than H.264 or H.265 because Ut Video has virtually no compression overhead. It’s so fast that disk write speed usually becomes the bottleneck at export time rather than CPU. Even DNxHR HQ is over twice as fast to export as H.264 Medium for the same reason. If given fast disks, these low-overhead codecs can radically speed up the Shotcut export time.

Large files are also an opportunity to speed up the computer. My dedicated fast export drive is formatted to use 64K allocation units. (Later versions of Windows have introduced 128K which I have not tested yet.) Had I used the 4K NTFS default, the OS would have to issue 16 times as many disk read requests (each with potential for fragmentation) compared to issuing a single 64K read request to get the same amount of data. The read queue is much shorter with 64K. But efficiency loss gets even more pronounced at 4K units when writing data because 16 times as many free-block searches have to be conducted. Obviously, the 64K variant is faster. But due to potential wasted space on small files, 64K isn’t recommended for a general-purpose disk (mixture of photos, documents, executables, etc). For a mixed media disk such as family memories, I use 8K allocation units as a compromise.

As for segments slowing down Shotcut, I’m not sure how that’s possible. A segment is shorter than the entire movie and only one segment is loaded at a time, so it actually speeds up Shotcut. The exported segments are never brought back into Shotcut, so that isn’t a concern.

I’ll let you be the judge. :slight_smile: I make one script (batch file) per project, the shell of which is part of my new-project template. Customizing the shell to a new project takes less than a minute. Invoking the batch file is as simple as double-clicking it. This method is way faster than waiting for a full-movie export out of Shotcut when I go back to fix things. The FFmpeg commands and concatenation process are described here:

2 Likes

Many thanks for this detailled explanation, Austin!
Much appreciated! Will give this excellent workflow a try for my next big project.
Have to admit my IT equipment is not ideal for really demanding video editing but still is very o.k. as i stick with FullHD and not going to 4k so soon.

1 Like

Thanks, I’m curious to know how it works for you and if you find any improvements along the way! There are many ways to structure a large project, and this is by no means the end-all-be-all.

Boss—Ever since I started using Shotcut years ago, Markers has been on the todo list. There is ALWAYS something that gets moved in front of Markers. Just sayin :slight_smile:
Not meant to complain–as I said-- just sayin :slight_smile:
Ron

I can concur with @Austin on using concatenation on FFmpeg. It’s amazing and a life saver.

In fact, I used that technique in creating one of my first Shotcut projects and saved me a ton of time when I had errors in one of the segments.

Below are the components:
https://youtu.be/MA5XzEIK2RQ - Segment 1
https://youtu.be/r381T0MwOeI - Segment 2
https://youtu.be/ktvUxRjJS_Y - Segment 3
https://youtu.be/coEveIW7s-k - Segment 4

https://youtu.be/YjmGz-BolP8 - Joined Segments with Intro Using FFmpeg

2 Likes