Non-linear editor (NLE) with multiple files

[mifi]

An often requested feature that would allow a more dynamic timeline, kind of like a traditional editor with multiple files. This is a very big feature, and I'm not sure if this is the direction LosslessCut should go, as many people like the current way of editing. But it's nice to be able to discuss it nonetheless. I think it would go something like this:

• Allow drag-dropping multiple files on the timeline
• Starts out with one big segment per opened file on the timeline, then the user can chop up, duplicate and move segments around like in a traditional editor
• Each segment would be connected to a file (or some other dynamic frame source, like say a fill color)
• Obviously all files still would need the same codec parameters for all their tracks
• Allows add pause between segments Add pause/black/title between segments #255
• Allows repeat/loop segments [Feature request] Ability to copy stream/portion of stream #284 Can you add the number of video loops or set the total duration of the video in the place where the video is merged in the tool? 能不能在合并的地方添加循环次数或者设置总时长 #2162
• Allows (lossy) adding images and other videos as segments (they would need to be encoded with the same codec)
• This would effectively make the current "Merge/concatenate files" dialog obsolete
• This kind of clashes a bit with the tracks editor (it would need to work per-file)

Design inspiration: #189

[14v]

Is it possible to implement duplicating segments first? This may solve many video editing issues and does not need file re-encode.

[mifi]

duplicating segments would require an NLE already implemented. But you can still duplicate segments as a workaround by first exporting the segment and duplicating the resulting file, then losslessly merge/concat the files

[worldpoop]

Here's how you do it without betraying the essence of Lossless Cut or getting into a quagmire of budding NLE design. Lossless cut just needs to allow two more things. Surely ffmpeg and some piping can handle this. Allow:

1. When setting up a batch movie file merge, on each imported movie you have the option of setting a single set of ying-yangable in and out points.

2. You have the ability to import the same file more than once to a batch, appearing in the batch as a separate instance.

Done. Now with two simple changes / additions, you have the ability to do things like this: I import video A and exclusively mark out a middle section for omission. Then I import and mark video B to be batch-merged to A. Then I import video A again (which gets treated like a unique file) and mark an inclusive in/out near the beginning that also happens to somewhat overlap the selection made in the first instance in A. And those are my batch instructions: Two parts of A, all of B, a different part of A. No timelines, just the same "left-side" vertical batch list -- Dear ffmpeg betwixt pipes, please merge this file portion to this file portion to this file portion.

Done. No multiple "right-side" exports. No re-imports. Ecstatic users!

If you discover this to be complicated for piping and such, then essentially behind the curtain Lossless Cut merely does the labor that users must do now: LC creates a temporary file from A, then a temporary file from B, then a temporary file from A, then a final output from Ta+Tb+Ta2. No machine time and cost, nor number or size of interim files, would be lessened (nor added to!), but human time and labor saved considerably. And Lossless Cut suffers no bloat, complex scripting or rewrite of existing code. Users still ecstatic.

(And if you think about, LC now could accomplish everything QT7 could do! And really, would be complete at this point. Anything from here would be a totally different animal, nothing any LC user is asking for, merely NLE territory to be avoided: speed changes, transitions, ui representation of a timeline, whatever, timeline stuff. That's not this.)

[FrisoDB]

This would be a great feature.
When I first used the concatenate tool/batch list I assumed it worked like @worldpoop described, but it did not.