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.

  • Have you checked this answer? stackoverflow.com/questions/5651654/…
    – digiwizkid
    Oct 25, 2019 at 7: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, 2019 at 8: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, 2019 at 8:50
  • @Tim is this answer not acceptable to you?
    – DK Bose
    Oct 28, 2019 at 11:20
  • @DKBose not tried yet hence not accepted.
    – Tim
    Oct 28, 2019 at 11:32

2 Answers 2


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


time ffmpeg -ss 00:02:30 -i input.mp4 -t 00:10:00 -c copy output.mp4
  • You can alternatively use -to in place of -t for end point.
    – pomsky
    Oct 25, 2019 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, 2019 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, 2019 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, 2019 at 18:36
  • 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, 2019 at 0:35

You can try 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, 2020 at 23:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .