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.

[tomasz-lasko]

Hi, in the beginning of this issue you wrote a lot of complicated functionality, which is indeed nonlinear editor. However most of the questions in other issues, which you redirect here, as well as my personal questions is very simple and one could say linear:

I have a batch file list (A, B, C), each file has it's own cutting points set (A1-A2, B1-B2, C1-C2). So now when I want to merge/concatenate (assuming all required conditions like same codec etc etc), the only new functionality would be so that the concatenate using the selected cuts (output = A1-A2 + B1-B2 + C1-C2) - apart from simple merging whole input files as it is done now (output = A + B + C)

In conclusion, my opinion is that:

1. Honestly this doesn't seem complicated at all, I hope the libraries you use allow to easily implement that.
2. This should be a seperate issue (like Advanced editing (combine cutting and merging multiple files) #423), implemented first. And the NLE in current issue should be a long term far goal.

[mifi]

While your use case mighy seem simple at a glance, it is just one of many different use cases that are all covered by implementing NLE functionality. There isn’t any library in losslesscut to do NLE with ffmpeg. It’s all done manually and it’s not trivial to add such use cases.

[tomasz-lasko]

it is just one of many different use cases that are all covered by implementing NLE functionality

Thank you. Ok. So my question: if we first forget about all other use cases, and focus on the simplest cases, then what do you think - wouldn't these few cases be most needed, and all the other cases clearly less urgent?

If no then my suspicion was wrong. But if yes, then I suggest totally splitting these two sets of cases - in short term the simple and important ones, and in some long term all other cases that fall under NLE.

[mifi]

As as I see it, the amount of work needed to implement a «simple nle case» is not insignificant. Especially considering how complex the current implementation already is (multi tracks, smart cut, cut/merge and a multitude of options).

[worldpoop]

I agree, the objections are perceiving the asks in overly complicated fashion and kind of getting stuck there. All that's being asked for is functionality that LC can already do, but with the decision list being better organized. That's it. No libraries are needed to assign sets programmatically to a better organized decision list: essentially the cuts -- output either to temporary or intermediary ("keep") files, or "|" , "<" -- then merged. There is no change to the existing rudimentary timeline functionality represented in the LC GUI. Nothing needs to be added there.

LC already creates the decision list as it is now in the form of sets listed in a column representing the eventual outputted segments. The subsequent merge order of the cut sets that LC now lists in a column need not be represented in the GUI again! It's one nested step instead of having to end the program and restart it. LC programmatically remains aware of the sets instead of only the user, that's all.

And it must necessarily only go in one direction start to exit: either a merge list followed by cut list, end; or cut list followed by merge list, end. (No cutting A,B,C, then merge BAC but cutting A again for BA1CA2 or whatever -- that's an NLE. No, only cut A,B,C, merge BAC. In other words, it's NOT non-linear, certainly not a timeline based NLE.). One could practically do this with scripts and ffmpeg, except that in LC you have already done the hard work of representing a rudimentary timeline GUI and a decision list of operations to be performed. Just use them, but with a better (slightly more robustly) organized decision tree. You are so close already!

[worldpoop]

tldr:

Two text columns, two passes (with no more than two passes possible): cut list; merge order list of those cuts, then runs pass1 & pass2; end.

Note, LC already does one OR the other. But it could programmatically feed one TO the other. That's it. It's all in the coding, handling of the sets, no libraries needed. [Update: v.1 below represents Lossless Cut exactly as it is now in reality, nothing new. Hope that clarifies the rest.]

CURRENT existing LC process (v.1): Cut list (mode) OR merge list (mode), run. End.

Enhanced LC process (v.2): Cuts list, merge order, run. End.

Enhanced LC process (v.3): Cuts list, merge order, run (mode) OR merge list, cut list, run (mode). End.

On v.3, you would need to handle some math, so work on v.2. (which your users will LOVE you for). Assess later if v.3 is worth it -- don't worry about it now. Just make v.2, that's quick and gorgeous!

[mifi]

This sounds more like an extension of #89 mass export button - I think the first version should just have a function to export all files in the batch list using current settings (without showing the export dialog)