NAS 媒体库自动整理与批量转码实战：用 Tdarr + ffmpeg 规范命名、转 H.265 省 40% 空间

摘要：家里影片越攒越多，命名乱、格式杂、占空间大。本文用 Tdarr 在 NAS 上搭一套自动转码流水线，把 H.264/MPEG-2 统一转成 H.265、文件名规范化，实测单库空间节省约 40%，且全程无需人工干预。

一、为什么要做媒体整理与转码

很多家庭的 NAS 里堆着多年下载的电影电视剧：有的封装是 MKV，有的是 MP4；编码有 H.264、VC-1 甚至老旧的 MPEG-2；分辨率从 480p 到 4K 都有；文件名更是 movie.1080p.WEB-DL.x264-XXX.mkv 这类让人头大的格式。

几个真实痛点：

空间浪费。同样一部 1080p 电影，H.264 可能 8GB，转成 H.265 后 4–5GB，画质肉眼几乎无差别。积少成多，一个 4TB 影库能省出 1.5TB。
播放兼容性。老编码在一些客户端（尤其手机、TV 盒子）需要实时转码，NAS CPU 扛不住就卡顿。
刮削失败。Jellyfin/Plex 靠文件名识别影片，命名不规范的资源识别率很低，海报墙一片问号。

把"整理 + 转码"做成一条自动流水线，新片拷进文件夹就自动被处理，才是根治办法。

二、方案选型：为什么用 Tdarr

能批量转码的工具不少：HandBrake 图形界面适合少量手动；ffmpeg 脚本灵活但要自己写调度；Tdarr 胜在"自动化"——它以「节点（Node）做计算、服务器（Server）做调度」的架构，配合插件栈（Plugin Stack）实现"满足条件才转、转完替换、失败保留原片"，非常适合 NAS 7×24 常驻。

它和 Jellyfin 是互补关系：Tdarr 负责把文件变成"干净、统一、省空间"的形态，Jellyfin 负责播放和刮削。两者都跑在 Docker 里，资源占用可控。

三、部署：Docker Compose

在 NAS 的 Docker 目录（如 /volume1/docker/tdarr）放一份 compose：

version: "3"
services:
  tdarr-server:
    image: ghcr.io/haveagitgat/tdarr:latest
    container_name: tdarr-server
    ports:
      - "8265:8265"
    volumes:
      - ./configs:/app/configs
      - ./logs:/app/logs
      - /volume1/media:/media:shared
    environment:
      - TZ=Asia/Shanghai
      - PUID=1000
      - PGID=1000
    restart: unless-stopped

  tdarr-node:
    image: ghcr.io/haveagitgat/tdarr_node:latest
    container_name: tdarr-node
    volumes:
      - ./configs:/app/configs
      - /volume1/media:/media:shared
    environment:
      - TZ=Asia/Shanghai
    devices:
      - /dev/dri:/dev/dri   # 启用 Intel/AMD 核显硬解
    restart: unless-stopped

关键点：把 /dev/dri 透传给 Node 容器，Tdarr 会调用 VA-API 走 Intel 核显硬转码，比纯 CPU 软转快 5–8 倍，且几乎不抢 NAS 的运算资源。

四、配置转码插件栈

Tdarr 的核心是「社区插件」。在 Server 的 Library → Plugin Stack 里依次加：

File Size Check：跳过小于 200MB 的片段（预告片、花絮不值得转）。
Transcode Configuration：目标编码 hevc_qsv（Intel 核显）或 hevc_nvenc（NVIDIA），CRF 设为 24–26，预设 medium。
Resolution Limit：4K 以上保留，1080p 以下不升频。
Audio Transcode：把 TrueHD 这类很多播放器不支持的音轨转成 EAC3，保留原始音轨副本。
Migrate / Reorder Streams：清理无用的数据流，保留一条视频 + 一条原音 + 一条转后音。
File Naming：容器统一为 MKV。

保存后把媒体库指向 /media/Movies、/media/TV，Tdarr 会扫描待处理队列自动开工。

五、命名规范化与刮削联动

转码只解决体积，命名还得靠另一条线。推荐按 {n} ({y}) [{resolution} {videoCodec}] 规则重命名，例如：

The Matrix (1999) [1080p hevc].mkv

规范命名后，Jellyfin 识别率从原来的约 70% 提升到接近 100%，海报墙不再缺图。注意：重命名要在转码完成、文件稳定后再做，避免 Tdarr 正在写入时被改名导致任务失败。

六、实测空间与资源占用

以我自己的影库为例：处理前 2.1TB，其中约 60% 为 H.264 老片。跑完一轮后降到 1.27TB，整体节省约 40%。Intel N5105 核显硬转，单部 1080p 影片约 6–10 分钟，全程 CPU 占用不到 15%，影音播放完全不受影响。

建议把 Node 的并发数（Workers）设为 1–2，避免多任务同时转码把核显占满导致播放卡顿。

七、常见坑

不要转已经很新的 H.265 片：File Size Check + 编码判断插件可跳过，避免"转了等于没省还费电"。
原片备份：第一批建议先拷到单独目录试转，确认画质可接受再开启"转完替换"。
字幕丢失：部分 MKV 的内封字幕在流重组时可能掉，转前务必勾选"复制所有字幕流"。
HDR 二次编码：4K HDR 走 hevc_qsv 时容易丢失 HDR 元数据，这类片源建议单独排除或改用 hevc_qsv 的 enable-hdr 参数。

小结

Tdarr 把"批量转码 + 命名规范 + 自动调度"整合到 NAS 上，是解决影库杂乱、空间吃紧的省心方案。配合核显硬解，几乎零感知地帮你在不动现有播放习惯的前提下，腾出近一半存储。