Combining multiple clips and saving without quality loss

Hey all,

So I am using my 4K camera and Atomos Ninja to record with and so far the quality is fantastic. Even out of my Sony AX53 HDMI out.

My problem is I am recording sports games, and there are typical breaks like half time or such, so I pause/stop recording, then start up again when the next half starts. That results in 2 (or sometimes more depending on if battery dies and have to swap, etc) files. The editing is simple, just put the clips together in order, convert to youtube and upload, so the teams can see the games. One of the big things I want to do is allow kids to pick out start/stop sections of a given video so I can take those as clips, and assemble a reel of clips of one kid into one video. What I have tasked the kids to do is to watch the video I post on youtube, and anytime they see a bit they want, to jot down the hh:mm:ss start point, and the end point as well.

The problem arises that I would like to avoid having to figure out where in the 2nd (or 3rd, 4th, etc) file their combined video start/end time is located. So I figured, if I can combine the source files into one file first, with no loss in quality, then use that for editing as well, that would greatly help me be able to pull clips accurately without spending time trying to figure out the offsets into multiple files with some math.

I am using DNxHR SQ source files, which is another reason I want to avoid any quality loss. I dont want to have to render it out of Resolve, losing any quality, to then use it as a single source file. I am not sure if I combine clips, and render out the same as the input files are, if there is any loss or if Resolve is smart enough to just combine/save it quickly?

So.. what is the right way to combine multiple clips, and save it, not render it, into one combined video file?

You could use concatenate with ffmpeg.

https://ffmpeg.org/

Funny that I didnt look that up either.. and I say that because the reason I want to combine clips now, is because I use ffmpeg to specify the -ss and -t in/out points to pull clips out with the -c copy option to not lose any quality.. spits it back out in the same format. It is very slick how fast it is. I found out a lot of video farms in the cloud use ffmpeg behind the scenes because of how robust and fast it is. Makes sense.. free software that does it all. Thankfully it supports DNxHR too! I figure why reinvent the wheel.

Thanks for the tip, Ill look to use this now.

So.. though the use of ffmpeg works well for the clips setup.. because I record multiple files in a game (usually 2 for the half time break, sometimes more if a battery dies and I have to change it), I have to combine ALL the clips (2+) into one before I can properly find the clips start/end points... e.g. if there are 2 files at 40 mins each, and a clip start is 53:12... I would have to do some math to figure out its 13:12 in the 2nd file. Sure..not hard.. but if there are more than 2 files, becomes more of a headache.

So my solution was to combine the files first, into one big one.. then be able to pull from that one source file.

Problem is I dont want to render as I combine.. losing quality. So thankfully ffmpeg has a demuxer option to combine clips into one. However, for the life of me I can not understand why, but I am lucky to get 3 to 5fps when this is used. In Resolve, I can render at about 15fps or so.. that is rendering it out to an mpeg4 format from DNxHR SQ. I am unclear why ffmpeg is so slow just combining clips into one file. I can copy each file in a few seconds to another location.. they are on SSD drives after all. So I would think, other than updating the header info of the final output file for the total length, it would be as simple as copying the files one after another. Yet.. it does .1 to 1fps, sometimes a few fps. Rendering with FX is 5x faster...

Frustrating. I was wondering if I could actually combine clips and export the thing as one file in Resolve without rendering..and no loss of quality?

However, for the life of me I can not understand why, but I am lucky to get 3 to 5fps when this is used.

That seems to indicate you are inadvertently re-encoding or there may be a problem with the seek operation. Some formats seek better than others, for instance .ts files can be problematic. If it is DNxHx make sure you have the latest version of ffmpeg.

Could you share the ffmpeg command?

The call I use is this:

ffmpeg -f concat -safe 0 -i demux.txt -c copy out.mov

and the demux.txt is the format for concat.. 2 files are listed:

file 'oct22-1.MOV'
file 'oct22-2.MOV'


This all seems to work.. just super super slow. I am running on a 6700K cpu, 64GB ram, NVMe drives. Should be about as fast as you can get on this system. I dont know if there is a way to use the GPU to speed things up.. I would assume not and that it is cpu bound.

I have done a lot of searching on the web and this seems to be the most common way to concat multiple files.

I record using an Atomos Ninja on SSD, so I dont know if I should be adding something somehow that helps with seek speeds, but I read that DNxHR typically is pretty fast with seeks, unlike mp4/hvec, etc.

I was wondering if there was a way to specify more threads..which there is, but everything I read indicated that makes things worse and to let ffmpeg use the optimal default thread settings to maximize speed.

I think your best option is to post a Window Dub. The kids choose based on the visible timecode, not the YouTube time.

What is a WindowDub?

So what I did just discover (thanks to what I think a WindowDub is), is using Resolve to burn in timecode into the video using the source timecode. That is pretty slick. That and adding the source filename (without the path) now allows me to ensure (at least I think it will) that the start/stop times of clips when using the overlay timecode should work perfectly in ffmpeg when pulling the clips.

You got it.