FFmpeg on shared hosting is possible and limited, and the limits are not the ones people expect. It is rarely the software that stops you; it is execution time, memory, and how many processes your account may run at once.
Knowing which side of the line a job falls on saves buying a server you did not need, and saves discovering mid-project that you did.
What works on shared hosting
Reading media files. ffprobe examines a file's header and returns in milliseconds: duration, codec, resolution, streams. It is cheap enough to run on every upload. Using ffprobe to Inspect Media Files has the detail.
Extracting a frame. Pulling a thumbnail out of a video reads a small part of the file and finishes quickly.
Stream copies. Trimming or joining without re-encoding moves data rather than processing it, so a two-hour file is handled in seconds. How to Trim, Cut and Concatenate Video with FFmpeg deals with when a copy is possible.
Short audio work. Converting a few minutes of audio is comparatively light.
The pattern: anything that does not decode and re-encode a whole video is usually fine.
What does not
Encoding video of any length. A few minutes of video takes minutes of CPU, and a shared account has an execution time limit measured in tens of seconds. The job is killed partway, leaving a truncated file that looks like a bug in your command.
Anything sustained. Live streaming, or a queue of files processed back to back, holds a process for hours. That is not what shared hosting is sold for and it will be stopped.
Batch work. Several encodes at once exhausts the concurrent process allowance, and the visible symptom is your website becoming unavailable in place of the encoding failing. How to Monitor Your Hosting Resources deals with seeing that.
The limit you will actually hit
Not disk, and not usually memory. Execution time.
A web request is capped at tens of seconds. A cron job usually gets longer, and still not the hours a real encode needs.
The symptom is characteristic: the job starts, produces a partial output file, and stops with no error from FFmpeg, because FFmpeg did not fail, it was terminated. People spend an afternoon adjusting the command when the command was correct. Troubleshooting Common FFmpeg Errors sets out reading what happened.
Never encode inside a web request
Even where it would fit, it should not.
A request that waits for an encode holds a PHP process for its whole duration. Two of those on a shared account can make the site unavailable to everyone else, and the visitor's browser usually gives up first anyway.
Accept the upload, record a job, return immediately, and process it from cron. How to Handle Video Uploads from a Web Application sets out that structure.
Ways to stay within the limits
Three that genuinely help if shared hosting is what you have.
Do the cheap work locally, the expensive work elsewhere. Validate and thumbnail on the server; send anything needing an encode to a service built for it.
Ask users to upload web-ready files. Accepting only H.264 in MP4 removes the need to convert at all, and a clear message about what is accepted is cheaper than a transcoding pipeline.
Use stream copies wherever the format already matches. Trimming, joining and remuxing are all copies, and copies are fast.
When to move to a VPS
The line is clearer than it sounds.
If you need to encode video regularly, you need a VPS or better. Not because shared hosting cannot run FFmpeg, but because encoding is a sustained CPU load and shared hosting exists on the assumption that nobody does that.
The same applies to a queue, to live streaming, and to anything running for hours. Getting Started with FFmpeg on Your AHosting VPS goes into the setup there.
What you gain is not a faster FFmpeg. It is the ability to run it for as long as the job takes, and to decide yourself how many run at once.
Being fair to your neighbours
Worth stating for anyone running FFmpeg on a shared plan legitimately.
Shared hosting is shared. A job saturating a core affects the accounts beside yours, and the provider's response is to stop it, which is the correct response.
Run one job at a time, at a low priority where you can, at quiet hours, and keep them short. That is the difference between using the resources you were sold and using somebody else's.
Check what is available before planning around it
FFmpeg is not installed everywhere, and where it is, the build varies, some encoders are compiled in and some are not.
Check the version and the encoder list before designing anything around a specific codec:
ffmpeg -version ffmpeg -encoders | grep -i x264
An encoder that is missing is not something you can install on shared hosting, and finding that out at the design stage is much cheaper than at the deployment one. For getting a shell to check, see cPanel Terminal and SSH Access.
If your application does accept uploads from the public, the limits matter for a second reason. For that, see How to Process Untrusted Video Uploads Safely.
Find out what the account actually permits
Limits differ between plans and between servers, and planning around an assumption produces a pipeline that fails on the first real file.
ulimit -a | head nproc free -m | head -2 timeout 5 ffmpeg -version 2>/dev/null | head -1 || echo "ffmpeg yok"
The process limit and the memory ceiling are what stop encoding work, and both are per account rather than per machine. A server with plenty of capacity can still refuse your job.
Test with a short clip before building anything around it. A conversion that works on ten seconds and fails on ten minutes is hitting a time limit, which is a different constraint from the ones above and needs a different answer.
Keep the work off the request path
The single rule that makes media work on shared hosting is that no visitor ever waits for an encode.
nohup nice -n 19 ffmpeg -nostdin -i in.mp4 -c:v libx264 -crf 23 out.mp4 > ~/logs/enc.log 2>&1 & echo $!
Accept the upload, record that work is pending, and process it separately. The visitor gets an immediate response and the encode happens when it happens.
Anything else fails in the same way every time: the request exceeds the execution limit, the process is terminated partway, and the result is a truncated file and a visitor who saw an error. Running FFmpeg jobs in parallel covers the queue that follows.