1. 为什么要在 NAS 上跑 FreeCut 而不是用电脑剪辑很多人第一次听到“NAS 剪视频”这个说法第一反应是NAS 那点性能能剪得动吗我一开始也是这么想的。直到有一次帮朋友处理一个婚礼跟拍的素材总共 200 多 GB 的 4K 片段他的笔记本只有 512GB 硬盘光是把素材拷进去就折腾了一下午剪到一半还因为空间不足卡死。那次之后我才认真考虑能不能把素材直接放在 NAS 上剪辑软件也跑在 NAS 上让剪辑这件事彻底脱离“本地硬盘容量”的束缚。FreeCut 就是在这个需求下进入视野的。它是一个可以跑在 Docker 里的轻量级视频剪辑工具核心思路是把剪辑工程和素材都放在 NAS 的存储池里通过浏览器访问操作界面渲染和导出也在 NAS 本地完成。换句话说你不需要一台高配电脑只要有一台能跑 Docker 的 NAS就能完成从素材管理到成片导出的完整流程。这件事的价值在于三个层面。第一是存储解耦素材永远在 NAS 上不用来回拷贝剪辑工程文件也直接存在存储池里换设备、换电脑都不影响。第二是算力复用NAS 通常是 7×24 小时开机的晚上挂着导出白天继续剪时间利用率比电脑高得多。第三是多人协作家里或者小团队几个人可以同时访问同一个 FreeCut 实例素材和工程共享不用再靠移动硬盘传来传去。当然NAS 剪视频不是没有门槛。CPU 性能、内存容量、Docker 配置、存储读写速度这些都会直接影响体验。所以这篇文章不会只告诉你“一键部署”就完事而是会把部署过程中真正会卡住你的地方、参数怎么调、导出为什么慢、素材怎么组织全部拆开讲清楚。适合已经有一台 NAS、想尝试本地剪辑、又不想被电脑配置绑架的人。2. FreeCut 在 Docker 里到底跑了些什么2.1 容器化剪辑工具的核心构成FreeCut 的 Docker 镜像本质上是一个打包好的 Web 应用运行环境。它内部通常包含几个关键部分一个轻量级的 Web 服务器负责提供操作界面一个基于 FFmpeg 的处理引擎负责视频解码、剪辑和编码一个任务队列负责管理导出任务以及一个工程文件管理系统负责保存剪辑时间线和素材索引。这和你在电脑上装的 Premiere、达芬奇有本质区别。桌面剪辑软件是“胖客户端”所有计算都在本机FreeCut 是“瘦客户端 服务端”模式浏览器只负责显示界面和接收操作指令真正的视频处理全部在 NAS 的 Docker 容器里完成。所以你的电脑性能不重要NAS 的性能才重要。理解这一点之后很多现象就说得通了。比如为什么在浏览器里拖动时间线会有一点点延迟因为每一次操作都要通过网络传到 NAS 再返回为什么导出的时候电脑可以关掉因为渲染任务在 NAS 上跑和浏览器没关系。2.2 为什么选 Docker 而不是直接装有人会问既然 NAS 本身也是 Linux 系统为什么不直接装 FreeCut非要套一层 Docker这个问题我在部署前也纠结过实际用下来Docker 方案有三个不可替代的好处。第一是依赖隔离。FreeCut 依赖特定版本的 FFmpeg、Python 运行库和系统编解码器。如果直接装在 NAS 系统里很容易和 NAS 自带的多媒体服务、下载工具产生库冲突。Docker 把这些依赖全部封在容器内部和宿主机互不干扰。第二是升级和回滚方便。FreeCut 更新版本时只需要拉取新镜像、重建容器原来的系统环境完全不动。如果新版本有问题切回旧镜像就行不会把 NAS 系统搞坏。第三是迁移简单。只要把容器配置和挂载的存储路径记下来换一台 NAS 也能快速重建工程文件和素材都在存储池里不受影响。提示Docker 方案的前提是你的 NAS 支持 Docker 或 Container Manager。群晖、威联通、绿联、飞牛等主流品牌的中高端型号基本都支持入门级 ARM 机型需要确认是否支持自定义镜像。2.3 硬件门槛到底在哪里NAS 剪视频的瓶颈通常不在 CPU 的绝对性能而在几个容易被忽略的地方。我把实际部署中影响体验的硬件因素整理成了一张表方便你对照自己的设备判断。硬件项最低可用推荐配置影响说明CPU四核 x86六核以上 x86影响解码和导出速度ARM 机型多数不支持内存4GB8GB 以上容器运行、FFmpeg 缓存、多任务并发都吃内存存储机械硬盘SSD 缓存 机械存储素材读取和工程保存速度直接受存储影响网络千兆2.5G 或更高浏览器预览和素材上传速度受网络限制Docker支持自定义镜像支持 Compose部分品牌需要手动开启高级容器权限这里要特别说一句ARM 架构的 NAS 基本可以放弃这个方案。FreeCut 依赖的 FFmpeg 和部分编解码库在 ARM 上要么没有预编译版本要么性能差到无法接受。如果你用的是玩客云、OES Plus 这类刷机设备建议先确认 CPU 架构再决定是否折腾。3. 部署前的环境准备与镜像选择3.1 确认 Docker 环境是否就绪在开始部署之前先在 NAS 上确认 Docker 服务是否正常运行。群晖用户可以在套件中心安装 Container Manager威联通用户在 App Center 安装 Container Station飞牛 NAS 和绿联 NAS 一般自带 Docker 管理界面。如果你用的是 Ubuntu 或 Debian 系统的 DIY NAS直接用命令行安装 Docker 即可。# 检查 Docker 是否已安装并运行 docker --version docker info # 如果未安装Ubuntu/Debian 下可以这样装 sudo apt update sudo apt install -y docker.io docker-compose-plugin sudo systemctl enable docker sudo systemctl start docker安装完成后建议把当前用户加入 docker 组避免每次都要 sudo。sudo usermod -aG docker $USER # 执行后需要重新登录终端才生效注意部分 NAS 品牌的 Docker 管理界面会限制容器权限比如不允许使用 host 网络模式或挂载系统目录。如果部署时遇到权限报错先检查 NAS 的容器安全设置而不是直接怀疑镜像有问题。3.2 存储目录规划素材、工程、缓存要分开这是很多人部署完才后悔的地方。FreeCut 在运行过程中会产生三类数据素材文件、工程文件、转码缓存。如果全部塞在一个目录里后期管理和备份会非常痛苦。我的建议是在 NAS 存储池里建三个独立目录# 在 NAS 的存储卷上创建目录结构 mkdir -p /volume1/docker/freecut/config mkdir -p /volume1/docker/freecut/cache mkdir -p /volume1/media/freecut/projects mkdir -p /volume1/media/freecut/assetsconfig存放 FreeCut 的配置文件和数据库体积小但重要建议定期备份。cache存放转码和预览生成的临时文件可以随时删除放在 SSD 上体验最好。projects存放剪辑工程文件体积不大但关联性强。assets存放原始素材体积最大放在大容量机械硬盘上即可。这样规划的好处是备份的时候只需要备份config和projectscache可以随时清理assets按需归档。如果后期要迁移也能清楚地知道哪些数据必须带走。3.3 镜像拉取与版本选择FreeCut 的镜像来源需要根据实际可用的仓库来确定。在 NAS 的 Docker 管理界面里搜索freecut或者通过命令行拉取。这里要提醒一点不要盲目追求 latest 标签。latest 通常是最新构建版可能包含未稳定的改动。如果镜像仓库提供了版本号标签优先选择带版本号的稳定版。# 拉取镜像具体仓库地址以实际可用源为准 docker pull freecut/freecut:latest # 查看本地镜像是否拉取成功 docker images | grep freecut如果拉取速度慢可以在 NAS 的 Docker 配置里更换镜像加速地址。群晖和威联通都有图形化的镜像源设置入口飞牛 NAS 和绿联 NAS 一般在 Docker 设置里也能找到。这一步不是必须的但能明显缩短首次部署时间。4. 用 Compose 把 FreeCut 跑起来4.1 编写 docker-compose.yml 的完整思路虽然很多教程会教你用docker run一行命令启动但我强烈建议用 Docker Compose。原因很简单FreeCut 需要挂载多个目录、映射端口、设置环境变量用docker run写出来是一长串后期修改和迁移都容易出错。Compose 文件把所有这些配置结构化保存下来改起来清晰重建也方便。下面是一个基于常见实践的 Compose 配置示例你可以根据自己的目录结构修改。version: 3.8 services: freecut: image: freecut/freecut:latest container_name: freecut restart: unless-stopped ports: - 8080:8080 environment: - TZAsia/Shanghai - PUID1000 - PGID1000 - CACHE_DIR/cache - PROJECT_DIR/projects - ASSET_DIR/assets volumes: - /volume1/docker/freecut/config:/config - /volume1/docker/freecut/cache:/cache - /volume1/media/freecut/projects:/projects - /volume1/media/freecut/assets:/assets devices: - /dev/dri:/dev/dri这个配置里有几个关键点需要解释。PUID和PGID决定容器内进程以什么用户身份运行。如果设置不对容器可能没有权限读写挂载的目录。你可以在 NAS 终端里执行id命令查看当前用户的 UID 和 GID然后填进去。devices里的/dev/dri是 Intel 核显的硬件加速设备。如果你的 NAS 是 Intel 平台并且核显可用挂载这个设备后 FFmpeg 就能调用硬件编解码导出速度会有明显提升。AMD 平台对应的设备节点不同需要根据实际情况调整。ARM 平台通常没有这个设备。restart: unless-stopped保证 NAS 重启后容器自动启动不用每次手动开。4.2 启动容器与首次访问Compose 文件写好后在文件所在目录执行启动命令。# 后台启动容器 docker compose up -d # 查看容器状态 docker compose ps # 查看启动日志确认没有报错 docker compose logs -f freecut日志里如果看到服务监听在 8080 端口、数据库初始化完成之类的信息就说明启动成功了。然后在浏览器里访问http://你的NAS IP:8080应该能看到 FreeCut 的操作界面。如果访问不了按这个顺序排查先确认容器是否在运行再确认端口是否被占用然后检查 NAS 防火墙是否放行了 8080 端口。这三个地方覆盖了绝大多数首次访问失败的情况。4.3 硬件加速到底有没有生效这是部署完成后最值得验证的一件事。FreeCut 导出视频时如果硬件加速生效CPU 占用会明显降低导出速度也会快很多。验证方法是在容器里执行 FFmpeg 的硬件加速检测命令。# 进入容器 docker exec -it freecut bash # 查看 FFmpeg 支持的硬件加速类型 ffmpeg -hwaccels # 如果输出里有 vaapi 或 qsv说明硬件加速可用如果输出里没有 vaapi 或 qsv说明核显没有被正确识别。常见原因是 NAS 的 BIOS 里没有开启核显或者 Docker 没有挂载/dev/dri设备。群晖用户还需要确认当前型号的核显是否被系统开放给 Docker 使用部分型号需要额外配置。提示硬件加速不是万能的。部分编码格式在硬件加速下画质会略低于软件编码如果你对画质要求极高可以在导出设置里手动关闭硬件加速用 CPU 软编换取更好的压缩质量。5. 素材管理与剪辑流程的实操细节5.1 素材怎么放才能让 FreeCut 识别FreeCut 通过挂载目录访问素材所以素材必须放在你映射的assets目录下。这里有一个容易踩的坑不要用中文文件名和特殊符号。虽然现代系统大多支持 UTF-8但 FFmpeg 在处理某些中文路径时仍然可能出错尤其是在容器环境里。我的做法是建立一个简单的目录规范assets/ ├── 2024-婚礼跟拍/ │ ├── A001_001.mp4 │ ├── A001_002.mp4 │ └── audio/ ├── 2024-产品宣传/ │ ├── B001_001.mp4 │ └── B001_002.mp4 └── 素材库/ ├── 转场/ ├── 音效/ └── 字幕模板/按项目分目录文件名用“机位编号_序号”的格式避免空格和中文。这样在 FreeCut 里导入素材时目录结构清晰找文件也快。5.2 浏览器里的剪辑操作和桌面软件有什么不同FreeCut 的操作逻辑和桌面剪辑软件大体相似都是时间线、轨道、素材箱那一套。但因为它是通过浏览器访问的有几个操作习惯需要调整。第一预览画质默认会降低。为了减少网络传输压力FreeCut 在浏览器里预览时通常会生成低码率的代理文件。这不是画质问题而是性能优化。导出的时候用的还是原始素材不用担心。第二时间线操作有网络延迟。拖动、裁剪、分割这些操作指令要传到 NAS 再返回。在千兆网络下基本感觉不到但如果用无线网络访问可能会有轻微卡顿。建议剪辑时用有线连接或者至少用 5GHz 频段。第三导出任务在后台跑。点击导出后浏览器可以关掉任务会在 NAS 上继续执行。你可以在 FreeCut 的任务列表里查看进度导出完成后文件会出现在指定的输出目录。5.3 代理剪辑让低配 NAS 也能流畅剪 4K如果你的 NAS 性能一般直接剪 4K 素材可能会很卡。这时候可以用代理剪辑的思路先把 4K 素材转成低分辨率的代理文件剪辑时用代理文件导出时再替换回原始素材。FreeCut 如果支持代理工作流通常会在导入素材时提供生成代理的选项。如果不支持也可以手动用 FFmpeg 先生成代理文件。# 批量生成 720p 代理文件示例 for f in /volume1/media/freecut/assets/项目A/*.mp4; do ffmpeg -i $f -vf scale1280:-2 -c:v libx264 -preset fast -crf 28 \ -c:a aac -b:a 128k /volume1/docker/freecut/cache/proxy/$(basename $f) done代理文件的码率和分辨率都低很多剪辑时读取速度快NAS 压力小。导出时 FreeCut 如果支持自动替换会直接用原始素材渲染如果不支持就需要手动在导出前把代理文件换回原始文件。这个流程稍微麻烦一点但对于低配 NAS 来说是唯一能流畅剪 4K 的办法。6. 导出慢、卡顿、权限报错的排查链路6.1 导出速度为什么比预期慢很多这是部署后最常见的问题。很多人看到导出进度条走得慢第一反应是 NAS 性能不行但实际上原因可能有好几个。我按排查优先级列出来。先确认硬件加速有没有生效。如果ffmpeg -hwaccels输出里没有 vaapi 或 qsv那导出就是纯 CPU 软编速度自然慢。解决办法是检查/dev/dri挂载和 NAS 核显状态。再确认导出参数是否合理。4K 导出用libx264的slow预设速度肯定快不了。如果对速度要求高可以改用fast或veryfast预设或者用硬件编码器h264_vaapi。然后检查存储读写。如果素材和缓存都在同一块机械硬盘上读写竞争会拖慢速度。把缓存目录放到 SSD 上导出速度会有明显改善。最后看内存占用。FFmpeg 在处理高分辨率素材时会占用大量内存如果 NAS 内存不足系统会频繁交换速度断崖式下降。用docker stats可以实时查看容器的内存占用。# 查看容器资源占用 docker stats freecut6.2 浏览器预览卡顿的几种可能预览卡顿和导出慢是两回事。预览卡顿通常和网络、代理文件、浏览器性能有关。如果用的是无线网络先换有线试试。4K 代理文件虽然码率低但多个轨道同时预览时数据量仍然不小无线网络的抖动会直接体现为卡顿。如果网络没问题检查代理文件是否生成成功。有些情况下代理生成失败FreeCut 会回退到原始素材预览那自然卡。还有一种可能是浏览器本身的问题。Chrome 和 Edge 对硬件解码支持较好Firefox 在某些编码格式下会强制软解导致 CPU 占用高、预览卡。换浏览器试试往往能直接定位问题。6.3 权限报错的完整排查过程权限问题是 Docker 部署中最烦人的一类错误因为报错信息往往很模糊。我遇到过一次典型的权限问题排查过程是这样的。第一步看容器日志。docker compose logs freecut里如果出现Permission denied或者cannot write to directory基本可以确定是权限问题。第二步确认 PUID 和 PGID。在 NAS 终端执行id看当前用户的 UID 和 GID 是多少然后和 Compose 文件里的设置对比。如果不一致改成一致。第三步检查目录权限。在 NAS 终端执行ls -la看挂载目录的属主和权限。如果目录属于 root而容器以普通用户运行就会写不进去。# 查看目录权限 ls -la /volume1/docker/freecut/ ls -la /volume1/media/freecut/ # 如果需要修改目录属主 sudo chown -R 1000:1000 /volume1/docker/freecut/ sudo chown -R 1000:1000 /volume1/media/freecut/第四步确认 NAS 的共享文件夹权限。群晖和威联通有独立的共享文件夹权限体系即使 Linux 层面权限对了NAS 的 ACL 也可能拦截。需要在 NAS 管理界面里给对应的用户或用户组授权。这四步走完绝大多数权限问题都能解决。如果还不行可以临时把容器以 root 身份运行测试一下确认是权限问题后再改回普通用户。7. 长期使用中的几个经验之谈7.1 定期清理缓存比扩容更有效FreeCut 的缓存目录会随着使用不断增长尤其是频繁预览和导出的时候。如果不清理几个月就能吃掉几十 GB 甚至上百 GB 空间。我的做法是设置一个定时任务每周清理一次超过 7 天的缓存文件。# 清理 7 天前的缓存文件 find /volume1/docker/freecut/cache -type f -mtime 7 -delete这个命令可以加到 NAS 的计划任务里每周执行一次。注意不要清理config和projects目录只清理cache。7.2 工程文件要单独备份素材可以重新拍但剪辑工程文件丢了就真的没了。FreeCut 的工程文件通常存在projects目录或者数据库里体积不大但包含了所有剪辑决策。建议把config和projects目录纳入 NAS 的定期备份计划用 Hyper Backup 或者 rsync 同步到另一块硬盘或另一台 NAS 上。7.3 多人同时使用时的资源分配如果家里或团队里有多个人同时用 FreeCut导出任务会互相抢资源。我的经验是错峰使用一个人导出的时候另一个人先做粗剪和素材整理等导出完成再精细调整。如果 NAS 内存足够可以限制单个容器的 CPU 和内存占用避免一个导出任务把整台 NAS 拖垮。# 在 compose 文件里限制资源 deploy: resources: limits: cpus: 4.0 memory: 4G这个配置不是所有 NAS 的 Docker 版本都支持但支持的话能有效防止资源争抢。7.4 什么情况下该放弃 NAS 剪辑说了这么多也要客观讲一句NAS 剪辑不是万能的。如果你经常剪 8K 素材、需要大量特效和调色、或者对实时预览要求极高NAS 方案可能还是不如一台带独立显卡的工作站。NAS 剪辑最适合的场景是素材量大、剪辑节奏偏慢、以剪辑和简单转场为主、需要多人共享素材。认清这个边界才能把 NAS 剪辑用在刀刃上。我自己现在的用法是粗剪和素材整理全部在 NAS 上完成精剪和调色如果要求高再把工程导出到电脑上处理。这样既利用了 NAS 的存储和常开优势又保留了桌面软件在复杂处理上的性能。两套流程配合起来比单纯依赖任何一边都更顺手。
