large temp storage requirements about ffmpeg-concat

[mifi]

I created a tool which is similar to this one, which does everything using streaming, thereby removing the need for temporary files and allowing much faster conversion: https://github.com/mifi/editly

[BrandonCookeDev]

I ran into this issue too, and when my C: drive ran out of memory the program just crashed.
I created a PR to allow you to choose a custom path for the temporary files (eg point to a new drive #18) but even when I used my separate drive 70GB wasn't enough to concat two files totaling only 500 MB.

I have an idea for the storage requirements.
Instead of re-encoding the entire shebang, is it possible to copy most of the original videos using ffmpeg's vcodec copy option?
And after this aforementioned copying, only re-encoding the transitioning frames using the ffmpeg-concat package you have written on the remaining pieces of video where the transition is desired to create the transition pieces.
Then finally using ffmpeg's native concat to splice them all back together?

I hope this isn't too confusing, but the strategy I've devised is detailed below:

First Video

#Get video file without transition at the end
ffmpeg -i {initial video file 1} --vcodec copy --acodec copy -ss 00:00:00 -t {video runtime until desired transition} {output file 1}

#Get Ending of the video where transition should occur
ffmpeg -i {initial video file 1} --vcodec copy --acodec copy -ss {start time for beginning of the end transition} {output end-file 1}

Subsequent Videos (N)

loop for video in N:

#Get video file without transitions at beginning or end
ffmpeg -i {initial video file N} --vcodec copy --acodec copy -ss {timestamp after runtime of opening transition} -t {video runtime until desired ending transition} {output file N}

#Get Beginning of the video until transition is over
ffmpeg -i {initial video file N} --vcodec copy --acodec copy -ss 00:00:00 -t {runtime timestamp for the transition} {output begin-file N}

#Get Ending of the video where transition should occur
ffmpeg -i {initial video file N} --vcodec copy --acodec copy -ss {start time for beginning of the end transition} {output end-file N}

Last Video (M)

#Get video file without transitions at beginning
ffmpeg -i {initial video file M} --vcodec copy --acodec copy -ss {timestamp after runtime of transition} {output file M}

#Get Ending of the video where transition should occur
ffmpeg -i {initial video file M} --vcodec copy --acodec copy -ss {start time for beginning of the end transition} {output end-file M}

After this we have the following list of files, all of which have a filesize that is a subset of the original files' totals:

file 1 #most of the initial video without the end where a transition will be placed
file 2 #most of the 2nd video without a beginning and end where transitions will be placed
...
file N
file M # most of the final video without the beginning where a transition will be placed

end-file 1   #to be ffmpeg-concat with begin-file 2. Produces 1-2-transition file
begin-file 2   #to be ffmpeg-concat with end-file 1. Produces 1-2-transition file
end-file 2     #to be ffmpeg-concat with begin-file 3. Produces 2-3-transition file
....
begin-file N    #to be ffmpeg-concat with end-file N-1. Produces (N-1)-N-transition file
end-file N       #to be ffmpeg-concat with begin-file M. Produces M-N-transition file
begin-file M    #to be ffmpeg-concat with end-file N. Produces M-N-transition file

After running ffmpeg-concat on the above files to be combined we have

file1
file2
...
fileN
fileM

1-2-transition
2-3-transition
...
(N-1)-N-transition
N-M-transition

Finally, we take these files and run ffmpeg's native concat process to create the final product (denoted by -o option or default)

In this fashion, we only need to run the ffmpeg-concat program on the begin and end files producing .raw files for only these tiny files where the transitions should occur, and leaving the original video mostly alone with its original encoding. No massive amount of additional MB or GB required.

This approach would also help to aid #4 as since most of the raw footage is maintained so are their audio tracks which will get concatenated by the ffmpeg native concat command.

[transitive-bullshit]

The amount of storage used is definitely an issue, though this seems like an extreme case. What resolution are the input videos?

Right now, we're storing all the frames for all input videos onto disk in an uncompressed raw format before starting the composition phase, which is really inefficient.

There are definitely ways we could make this more efficient, such as only storing the frames actually in use instead of all frames, but this would complicate the implementation quite a bit. PRs welcome :)

As a practical workaround for now, you can try using the --frame-format argument and setting it to png or jpg which should take up significantly less space than the default raw format. Note that the raw format is used by default because it is faster to read / write.

[BrandonCookeDev]

Followup: I plan on implementing the above strategy in a standalone, optional file for my fork. If desired I can open a PR allowing the addition of this component.

[transitive-bullshit]

Instead of re-encoding the entire shebang, is it possible to copy most of the original videos using ffmpeg's vcodec copy option?

@BrandonCookeDev this approach is definitely right on the money, however the vcodec copy thing won't come into play if you want to do things optimally. I've already implemented this for Automagical but haven't had time to port it back to this project. I'd definitely be happy to accept a PR for this though :)

The idea as you said is to only create temp frame data for the parts of the input videos which appear in transitions. The rest of the video can be ignored and concat'ed normally using ffmpeg.

There's no need, however, to create temporary video files for each of the sub-videos; you can accomplish the same thing much more efficiently using a single ffmpeg filter_complex filter graph and trim filters. If you want an example of what this eventual filter graph would look like, check out my other project ffmpeg-gl-transition.

Anywhere you mention .raw files, note that this is just an artifact of the defaults of the implementation. They could just as well be jpg or png files by changing the frameFormat option, so in future discussions let's refer to them as "frame data".

Cheers 💯

[BrandonCookeDev]

are you planning on implementing the known fix soon? Because the method I suggested, while should work, would be very tedious to write and test. If a fix is in the works I would prefer saving some time :)

[transitive-bullshit]

Hey @BrandonCookeDev, yes, I'd very much like to port it over tho free time is rare for me these days. Let me know if you'd like to chat about what the ideal situation would look like and maybe we can collaborate offline :)

[kraftydevil]

where are the temporary files stored? After the script crashed in the middle of concatenating, I am down at least 40 GB of storage. I'm on a Mac

[kraftydevil]

restarting my machine freed up the storage again

[transitive-bullshit]

See #23

[MitchellMonaghan]

Doing this with 17-18 clips with the range of 11-60 seconds of length this consumes approximately 130gigs on my machine. Works out be be about a 8 minute video, I really wanted 10mins but then I ran out of hard drive space.

[transitive-bullshit]

@MitchellMonaghan You can also use the --frame-format png option to store each frame compressed instead of the faster raw format that's the default. This will use significantly less hard drive space.