18

I made a screen recording, but then accidentally left it recording overnight for an extra 6 hours. In total I think it’s around 9 hours - and the file has hit 15GB.

Luckily it managed to save to the desktop, but I’m struggling to open it to trim it down.

I’m thinking the best way it to split the file into ~30 smaller files. I could then reassemble the desired ones.

Equally I’m fairly confident of where the useful content ends - around the 2:30 mark. I could calculate it more accurately if needed.

Could I do either of these things with a tool which doesn’t load the entire video into memory? I’ve used ffmpeg on Ubuntu before but I do not know if it can do something like this.

Tim
  • 32,861
  • 27
  • 118
  • 178
  • Have you checked this answer? https://stackoverflow.com/questions/5651654/ffmpeg-how-to-split-video-efficiently – digiwizkid Oct 25 '19 at 07:18
  • 1
    Sounds like you're using mac OS. Is this related to Ubuntu in some way? If so, please [edit] your question and clarify. – pomsky Oct 25 '19 at 08:47
  • @pomsky removed the macOS specific section, didn’t realise I’d left that in. For clarity: the file is on my Mac but I have an Ubuntu VirtualBox which could access the file and perform this operation. I felt that Ubuntu May be better at this task, so I felt it sensible to post here as well. – Tim Oct 25 '19 at 08:50
  • @Tim is this answer not acceptable to you? – DK Bose Oct 28 '19 at 11:20
  • @DKBose not tried yet hence not accepted. – Tim Oct 28 '19 at 11:32

2 Answers2

30

I think ffmpeg would do it. This has the advantage of not decompressing and recompressing your file, so it should be quick. Use the -c copy argument to achieve this.

ffmpeg -i input.mp4 -ss 00:02:30 -t 00:10:00 -c copy output.mp4

To explain the above command...

  • ffmpeg is the application
  • -i input.mp4 is your input file
  • -ss 00:02:30 starting point (HH:MM:SS)
  • -t 00:10:00 duration of clip (ten minutes long)
  • -c copy copy audio and video without re-encoding
  • output.mp4 output file

See this link for more.


Additionally, a comment in the GitHub page (mentioned in the link above) suggests placing -ss 00:02:30 before -i input.mp4 to speed up things. You can test both routes using time. Compare

time ffmpeg -i input.mp4 -ss 00:02:30 -t 00:10:00 -c copy output.mp4

and

time ffmpeg -ss 00:02:30 -i input.mp4 -t 00:10:00 -c copy output.mp4
DK Bose
  • 42,548
  • 23
  • 127
  • 221
  • You can alternatively use -to in place of -t for end point. – pomsky Oct 25 '19 at 10:01
  • If you leave out the -c copy, will it run this on the original file? How could one cut the video itself, without doing a copy (or is that a totally different command, and it'd just be easier to do the above, then delete original)? – BruceWayne Oct 25 '19 at 16:34
  • 2
    @BruceWayne -c copy means "don't decode and re-encode anything, just copy the data directly from input to output"; ffmpeg always makes a new file. I'd recommend just using this and then deleting the original. – Draconis Oct 25 '19 at 18:10
  • 1
    @BruceWayneyou could copy the ffmpeg output to dd via stdout and count the # of bytes in the output stream then truncate the original file to that length but if you get that wrong you risk corrupting the original file. – kkron Oct 25 '19 at 18:36
  • Should it be -ss 00:00:00 -t 00:02:30 ? – reas0n Oct 25 '19 at 19:46
  • @reas0n Absolutely. "Equally I’m fairly confident of where the useful content ends - around the 2:30 mark". Emphasis mine. I think Andrew must've misread the question. In fairness, so did I at first glance. – Mast Oct 25 '19 at 20:04
  • 3
    -ss before -i isn't just faster, it's better in this case. -ss before -i with -copy will always start copying at a keyframe. -ss after -i will start output at exactly the requested timestamp even if that isn't a valid point for a decoder to start. When transcoding, that's okay, but when stream-copying, it's likely to create an output file with a garbled beginning. – hobbs Oct 26 '19 at 00:35
2

You can try lossless-cut.

www.github.com/mifi/lossless-cut

  • This, as well uses ffmpeg. After trimming gives a message that the trim points might be inaccurate. Same problem, over and over again. – Binyomin Dec 29 '20 at 23:12