php不处理视频，仅调用ffmpeg；超时主因是php等待或ffmpeg卡死。应改用proc_open()设流超时、加-t限制时长、异步转码、优化参数（如-ultrafast、-crf26）、限制线程并检查资源与权限。
PHP本身不处理视频，只负责调用ffmpeg进程；超时问题本质是PHP脚本执行被中断，或ffmpeg子进程卡住。解决核心是**不让PHP等结果，也不让ffmpeg无限跑**。
设置合理的命令级超时
直接用shell_exec()或exec()硬等，大视频可能几分钟甚至几十分钟，PHP默认执行时间（max_execution_time）通常30秒，必然超时。必须用更可控的方式启动ffmpeg：
- 用
proc_open()启动ffmpeg进程，配合stream_set_timeout()对STDERR/STDOUT流设超时，比如5分钟 - 避免用
shell_exec()——它会阻塞直到命令结束，无法中途干预 - 命令中加入
-t 3600（限制总处理时长1小时），防止异常卡死
把任务移出HTTP请求生命周期
用户上传完立刻返回“已接收”，转码在后台异步跑，这是最稳妥的生产方案：
- 上传成功后，把视频路径、目标参数写入数据库或Redis队列
- 用Supervisor或systemd管理一个常驻worker进程，持续监听队列并调用ffmpeg
- 前端通过轮询或WebSocket查转码进度，状态存在数据库里
优化ffmpeg自身耗时
不是所有大文件都必须“完整转一遍”。从参数层面压缩耗时：
- 用
-preset ultrafast或veryfast，牺牲一点体积换速度，适合预览或快速交付 - 加
-ss 00:00:00 -to 00:10:00先切片测试，确认流程再全量处理 - 分辨率高但不需要高清展示？提前用
-vf "scale=1280:-2"缩放，大幅降低编码压力 - 避免
-crf 18这类高质量参数，-crf 26~28对普通播放足够，速度快不少
检查系统级资源瓶颈
超时有时是假象，实际是服务器扛不住：
- top或htop看CPU和内存是否打满，ffmpeg多线程默认占满核数，加
-threads 2限制线程数 - 确保/tmp和输出目录所在磁盘有足够空间和I/O能力，机械盘处理4K视频容易IO阻塞
- Web服务器用户（如www-data）需对ffmpeg二进制和输出目录有执行、读写权限，否则卡在权限拒绝阶段，表现像超时
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
