29

I record a few hours of video footage every day, which I set in queue for encoding with ffmpeg. I use the veryslow preset with x265, so a single hour of video may take up to 20 hours or more to encode.

Since my computer is working day and night, I'm wondering if ffmpeg has a way to pause and resume encoding? I'm using Terminal for OS X.

If so, can I also continue encoding even after shutting down Terminal and rebooting the computer? I think the Terminal session is restored when you log in again in OS X, at least the Terminal history is.

9 Answers 9

34

Suspend

A simple method is to suspend it with ctrl+z. Or you could get the PID with pgrep ffmpeg then use kill -s SIGSTOP <PID> to suspend.

Then resume with fg command or kill -s SIGCONT <PID>.

Unfortunately this will not survive a reboot.

VM

If you use a virtual machine, with something like VirtualBox, you could perform your encoding in a guest VM. It will allow you to "save the machine state" at any time which can survive a reboot. It can also allow you to assign max CPU resources for the guest so your host will always have available resources.

Possibly overkill, but if you're familiar with VMs or using one already it is a possible solution.

5
  • I love that VM solution, however, unless you're already using one it's a pretty big hassle.
    – user3643
    Commented Feb 1, 2017 at 17:56
  • The VirtualBox way didn't work for me. Tried just to save the state in mid-encoding, and tried to suspend by [Ctrl]+[z] and then save the state. After restoring the state and trying to resume, ffmpeg stops with an error (decode_band_types: Input buffer exhausted before END element found or Invalid NAL unit size and Error writing trailer / Protocol error). Maybe it's related to the jump in time, I don't know. Commented Apr 1, 2019 at 6:39
  • @JānisElmeris I can't seem to duplicate that issue. I tried it on Ubuntu 18.04 VM and it worked.
    – llogan
    Commented Apr 1, 2019 at 17:07
  • OK, I'm probably not lucky enough. :) Tried with a fresh Linux Mint 19.1 (based on Ubuntu 18.04) VirtualBox VM. Commented Apr 2, 2019 at 11:34
  • my ffmpeg has many threds and as many PID. Do I have to SIGSTOP and SIGCONT each of them? is there a timely constraint?
    – wuppi
    Commented Jul 16, 2019 at 8:00
23

On Windows, pressing the "Pause/Break" key (the top-right most key) will pause it. Enter will resume.

If it doesn't work, click on the command prompt window to give it focus.

5
  • This is the easiest and best answer for Windows (verified on Windows 10).
    – lidsinker
    Commented Aug 6, 2018 at 13:14
  • 2
    This frees up the cpu completely but the ram is still bottlenecked. In my case I have 8gb ram and it's using almost all of it still while the operation is paused. Any fix for that? Can I transfer this to the hdd or something? I don't mind a bit of a windup for things to get going when i unpause.
    – kite
    Commented Jan 4, 2019 at 18:45
  • @kite Applications that run in Windows terminals are called TSRs, Terminate and Stay Resident. They allocate pieces of available system memory to reside in. Removing them from that memory allocation effectively stops the application. The only way to "save" a running app is to wrap it in some sort of memory manager that proxies the actual memory allocation. So, short answer, yes you can but it's not easy or simple in any form of the word(s).
    – dsanchez
    Commented Jan 29, 2021 at 17:58
  • @kite The native way to of transfering application memory to hard drive is to increase your virtual memory size. Windows will move allocated memory of inactive applications to swap file, effectively freeing up physical memory for other applications. If it's a common scenario for you, you can increase virtual memory size far beyond physical memory, but take in mind that in order to actually work without slowing down 10x, applications do need physical memory.
    – Athari
    Commented Jun 3, 2022 at 11:56
  • Do note that "selecting/marking text on the command prompt window to pause ffmpeg" won't work on the new Windows Terminal, and works only on the old conhost. Commented Jun 16 at 6:50
17

It didn't seem possible as of Sep 30 2015. I would suggest segmenting the source file, encoding the segments and then stitching the resultant files.

This isn't a true pause/resume facility but the piecemeal division will allow you to have a break from encoding.

A rough overview of the commands to issue:

Break the fullfile into parts

ffmpeg -i recording.mp4 -c copy -flags +global_header -segment_time n -f segment file%03d.mp4

This should create file000.mp4, file001.mp4 and so on. Because of how the segmenter works - it only cuts at I-frames - these files won't be exactly n seconds long and the video part may not play properly, but the data's all there and you can convert each of the parts e.g.

ffmpeg -i file001.mp4 -{filter/encoding parameters} -fflags +genpts file001-new.mp4

Rejoin the encoded parts

Create a text file and put in the name of each rendered file like this

file 'file000-new.mp4'
file 'file001-new.mp4'
.... 
file 'filelast-new.mp4'

And run

ffmpeg -f concat -i textfile -c copy -fflags +genpts recording-encoded.mp4
2
  • 2
    Having only 6GB memory, and an estimated time of 12h to enconde from x264 to x265 and having no no-break (desktop), I cant use the VM trick, but this sounds great! I just expect the rejoining step is fast, but as there will have no encoding on it, I think it will be. Have to try it, thx vm! Commented Dec 22, 2018 at 6:04
  • it creates a warning when joining: "Codec for stream 0 does not use global headers but container format requires global headers" but the final result is a usable video, I saw no problems at all Commented Dec 24, 2018 at 0:16
9

I sugest instead of pausing, you give the encoding process the very least system priority (aka "renice"), so you can work daily comfortably and the encoding will take place in background with the unused system ressources. So your encoding will take place seamlessy 24/7 without interruptions, without conflicting with day work

as AFAIK OSX lacks the pidof command, you need to know the ffmpeg process number (PID)

then you can renice the process to idle background with

sudo renice 20 yourPID

if needed you can also renice the process to more agressive foreground priority

sudo renice -10 yourPID
2
  • Hi! Good suggestion. Will have to try it.
    – P A N
    Commented Jan 29, 2017 at 12:01
  • Much easier to just start the process with nice -19 ffmpeg ... to begin with, rather than renicing it later. I find this allows you to browse and perform other tasks nicely. And when your machine isn't doing anything else, encoding proceeds with no visible impact on performance/speed.
    – kontextify
    Commented Apr 14, 2022 at 11:08
6

Suspending the Thread works on Windows too, not with ctrl + Z, but in the resource manager, you can also resume it there.

1

(This for Linux)

As you all probably know, pressing 'q' ends the recording file.

ffplay has the 'p'-possibility. Why doesn't ffmpeg have the same thing? Maybe because it can lead to desync between video and audio?...

I just ffmpeg-encode to x264-aac-mkv with crf (23) and always with the same video conditions, 'quit' (q) the recordings and join all the segments in a specific dir, where this script resides, to 1 file in streamcopy mode with this bash-script:

#!/bin/bash

# FFMPEG MERGE

# File path must be absolutely absolute...

ffmpeg -f concat -safe 0 -i <(printf "file '%s'\n" /home/me/Videos/FFmpeg/FFmpeg_Merge/*.mkv) -c copy merged.mkv

exit 

After that I check the resulting merged video and paste it to another dir. The segments are removed from the merge dir.

But, a hasslefree 'Pause & Resume' button would be welcome indeed;)

1

Places windows in hibernate will pause the job if you need to shut down your machine for awhile.

1

In Windows... Just click and drag to select some text from the CMD terminal, then you can see that the process has been "paused", so no CPU usage is registered until you hit "enter" on the terminal (that unpause the process)

0

This is just an idea, but if you have some budget, it'd be a good idea to upgrade either the processor (to 8th gen Intel) or even better, the video card (to NVIDIA GTX 1050 or above) so you can encode h.265/HEVC with hardware acceleration instead of CPU-intensive x265. Your video encoding will be finished in much less than 20 hours, saving you electricity costs too.

1
  • ffmpeg page on hwaccel says the quality of output from gpu may not be the same. just a warning
    – qwr
    Commented Jan 30, 2022 at 8:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.