为 NAS 存储来个大瘦身 - 照片视频压缩方案

之前在 群晖、迷你主机还是捡垃圾，家用NAS怎么选 提到，我家里 NAS 存储的重要家庭数据已经达到 1000GB，主要就是家中多年积累下来的照片、视频，共计约 20 万文件。虽说存储量也不大，但在迁移过程中，还是感觉很吃力，大量小文件读写，用移动硬盘复制都得几个小时。为了解决这个问题，便于日后轻松上阵，我借鉴之前在 hugo 和 soomal 项目中的经验，对 NAS 文件来了次大瘦身，节约 75% 的空间。

清理重复文件

我的家庭照片视频存储

我以前备份照片视频的模式，基本都是采取每年一到两次的频率，将相机、手机照片视频冷备份到 NAS。大体是选择在春节、国庆长假这种时间节点，以及换手机的时候，一股脑把手机上照片视频通过移动硬盘复制过去。

在这过程中，有一个比较麻烦的事情是，每次我换手机都会将上一台手机的照片视频导入新手机，而上一台手机中很多照片、视频实际上都已经在 NAS 有备份。这种情况下，如果自己备份的时候认真一点，通常会考虑删除一遍重复文件，但很多时候比较懒就没管了。造成 NAS 中实际上有不少文件都是重复版本。

要清理群晖 NAS 中的重复文件，通常有三种方法。

群晖自带的存储空间分析器。打开群晖自带的存储空间分析器，查找“潜在重复文件”，通常会输出一个 csv 文件，列明重复文件。把需要删除的文件导出为 txt，然后在“任务计划”中通过命令 cat /volume3/video/delete.txt | xargs -I {} rm -f "{}" 就能把重复文件删除。

群晖存储空间分析器

这种方法只适合重复文件数量较少的情况。例如，我的群晖每次只支持查找 5000 个重复文件。如果重复文件显著超过这个数值，就不是很实用了。毕竟，每次查找重复文件都耗时颇多。

第三方应用工具。群晖第三方应用市场有几款删除文件工具比较实用。例如：dupeGuru fdupes 等。我也下载测试过，但查找速度比较慢，主要是因为我的群晖 CPU 性能太低了，几个小时都没输出结果，就没等下去了。另外，这种方式其实也相对不是很直观，如果对重复文件的表现形式不是很确定，设置起来也麻烦。
Windows 重复文件删除软件。通过文件挂载，在 Windows 上利用电脑 CPU 和电脑软件来查找重复文件。我使用的是 Duplicate Cleaner，进行了多次重复文件删除操作。包括：a. 查找相同 MD5 的文件；b. 查找相似文件名 + 相似大小的文件； c. 查找相似内容文件； d. 用图片模式。

Duplicate Cleaner

过程中也并不容易。一开始我用重复文件名模式，结果发现，很多手机都用同一种命名方式，比如我能搜索到 5 个设备拍出来的照片都是 IMG_001.jpg 这种命名模式，必然会有大量文件重名。然后，很多文件在传输过程中被重命名了，原本可能是 IMG_001.jpg 但另一个版本的名字可能是一串随机数字，而且 md5 也不同。其次，有不少文件因为微信传输等原因，内置 exif 都不存在了，导致相似的两张照片文件数据区别稍大，需要将重复文件匹配的灵敏度调至最低才行。另外，还有不少 live photo 的文件，出现不同的保存策略，有的保存为一个文件，有的存为两个文件，大体是因为群晖在不同时期对苹果、安卓各种 live photo 格式支持策略不同的原因。

最终，经过重复文件清理，我群晖中保存的照片、视频下降到了 817 GB。

删除重复文件后存储容量

将照片转为 WEBP 格式

图片批量转 WEBP 我也不是第一次操作了，去年已将本网站所有图片转为 WEBP，前几个月把 Soomal.cc 上近 10 万张照片也转为了 WEBP 格式。

我对 WEBP 格式非常喜爱，即便此前将 JPG 转 WEBP 只保留 70% 质量，肉眼也很难分辨出两者之间的差异。这次保险起见，我设置了 85% 的质量，拿两个 4K 显示器对测试图片进行对比时，也是看不出什么差距。也可能因为我是色弱的原因吧，我找小孩帮忙看看，她说除了颜色淡点，也没看出个所以然来。

左 webp 右 jpg

既然差距不大，那我将 NAS 中全部文件转为 WEBP 就不再有任何心理压力了。即便是 WEBP 色彩不如 JPG 丰富，也就是一个手机相册修图 AI 滤镜就能解决的事。但两者存储大小，可是差了三四倍。

我此前曾用 ChatGPT 写过一个简单转换代码，这次还是差不多。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
@echo off
setlocal enabledelayedexpansion

for /r %%i in (*.jpg *.jpeg *.png) do (
    set "newFile=%%~dpi%%~ni.webp"
    cwebp -q 85 "%%i" -o "!newFile!"
    del "%%i"
    rename "!newFile!" "%%~nxi"
    echo Converted %%i to "%%~nxi"
)

echo All images converted and originals deleted.
pause

不过，这次除了 JPG PNG 还得考虑 RW2 CR2 HEIC 等格式转换问题，同时还得确保前后照片 EXIF 信息不丢失，整体转换代码稍微复杂点。但只要提示得当 AI 基本都能一次过。

将视频转为 H265 编码

我家庭存储的视频，有很多都是相机原生格式，不少都是老编码大码率的 mp4 mov。这次我准备将它们来个瘦身。

一开始我盯上的是 av1 编码，毕竟原生视频压缩到 av1，存储容量压缩四五倍都是正常的。

但有两个问题比较头疼，一是我家里的 RTX 2080 显卡不支持硬解 av1 编码，如果要用 CPU 来软解，这个过程过于漫长了；二是我的飞牛 NAS 所使用的 i3-8300T CPU 也不支持硬解 av1，日后播放起来也比较麻烦。

最终，我还是保守起见，选择使用 H265 编码来压缩，没想到效果倒也很不错，即便是较新的 H264 转 H265，也能压缩一倍多容量。

H265 和 H264 大小对比

这种转换同样可以借助 AI 编写转换脚本，过程中注意几个问题就好： 1. 调用 GPU 参与转换；2. 注意保留原视频 EXIF 信息；3. 先测试再转换。其中，我在测试时发现，EXIF 信息处理稍微麻烦点，因为 GPU 默认无法处理这个事情。最后，我是分开两步走，先转换视频，再通过另一个脚本将源文件 EXIF 写入转换后的 EXIF。

转换脚本示例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
import subprocess
import os

def convert_to_h265(input_file, output_file, crf=28, preset='fast'):
    """
    使用FFmpeg和NVIDIA GPU将视频转换为H.265编码
    
    参数:
        input_file: 输入视频文件路径(MOV/MP4等)
        output_file: 输出文件路径(建议用.mp4后缀)
        crf: 质量参数(18-28，值越小质量越高)
        preset: 编码速度预设(slow, medium, fast等)
    """
    if not os.path.exists(input_file):
        raise FileNotFoundError(f"输入文件不存在: {input_file}")
    
    # FFmpeg命令
    cmd = [
        'ffmpeg',
        '-i', input_file,                        # 输入文件
        '-c:v', 'hevc_nvenc',                    # 使用NVIDIA的HEVC编码器
        '-preset', preset,                       # 编码速度预设
        '-rc', 'vbr',                            # 可变比特率模式
        '-cq', str(crf),                         # 质量参数(类似CRF)
        '-qmin', '0',                            # 最小量化值
        '-qmax', '51',                           # 最大量化值
        '-b:v', '0',                             # 不设置目标比特率
        '-profile:v', 'main',                    # H.265 profile
        '-tune', 'hq',                           # 高质量调优
        '-movflags', '+faststart',               # 流媒体优化
        '-c:a', 'aac',                           # 音频编码
        '-b:a', '128k',                          # 音频比特率
        output_file
    ]
    
    try:
        # 执行命令
        subprocess.run(cmd, check=True)
        print(f"转换成功: {output_file}")
    except subprocess.CalledProcessError as e:
        print(f"转换失败: {e}")
    except Exception as e:
        print(f"发生错误: {e}")

# 使用示例
if __name__ == "__main__":
    input_video = "input.mov"       # 替换为你的输入文件
    output_video = "output_h265.mp4" # 输出文件名
    
    convert_to_h265(input_video, output_video, crf=23, preset='fast')

转换结果

通过将图片和视频转换为更高效格式，最终，我原本 817GB 的照片、视频库，被压缩到 248GB。

转换结果

这个存储量，基本上我可以在现有各种存储方案，包括电脑、手机、移动硬盘、群晖、飞牛 NAS 以及 Onedrive 上都备份一遍，显著提升数据存储的可靠性。

同时，我也在移动硬盘和群晖中继续各保留一份原始文件，但其实必要性也不大。

我早年用佳能、松下拍过很多照片，都保留的 RAW 格式。当年想着，以后有需要时，再用 Photoshop 或 Lightroom 进行处理，但实际上最近 5 年以上，我电脑里连一个 Adobe 家的软件都没安装过。根本没有继续折腾的必要，一个轻巧的文件格式，直接用平板电脑或手机处理就够了，再不济，还有 AI 修图这种 Bug 级产品，再差的画质也都能修复。更何况目前保留的格式，跟源格式之间也没有显著差距，也就更心安理得。

EXIF 中 GPS 处理问题

在这次转换过程中，我无意间搞了个 BUG 出来，就是飞牛相册中，我的照片、视频里边，只有视频的 GPS 信息能显示到相册地图，所有 WEBP 都无法显示地理位置。

一开始我在飞牛的文件管理器中查看 EXIF ，并没有发现问题，无论是能显示到地图中的视频 EXIF 还是无法显示到地图中的图片 EXIF，在文件管理器中都能看到有 GPS 信息。

于是我在 MT Photos，群晖和手机中测试，发现这些 WEBP 照片的 GPS 显示都没有问题，图片都能正常加载到地图中。我一度以为这个飞牛相册的 BUG。毕竟，群晖、手机、MT photos 都显示正常，只有飞牛显示不正常，正常人都会认为这是飞牛相册的问题。

在官方论坛反馈多日后，开发人员才回复。让我上传几张样图供测试。

也就是在上传样图的过程中，我在飞牛相册中偶然查看了一下照片的 EXIF 详细信息（飞牛文件管理器中只显示 EXIF 简要信息）。这才发现区别。

1
2
3
4
5
6
7
8
9
# 源文件
"GPSLatitude": "23 deg 7' 47.54\" N",
"GPSLongitude": "112 deg 34' 56.19\" E",
"GPSPosition": "23 deg 7' 47.54\" N, 112 deg 34' 56.19\" E"

# 转换后
"GPSLatitude": "23 deg 7' 47.54\"",
"GPSLongitude": "112 deg 34' 56.19\"",
"GPSPosition": "23 deg 7' 47.54\", 112 deg 34' 56.19\"",

原来是我 WEBP 文件的 EXIF 中 GPS 信息丢了方位标识。也就是 E N S W 这种东经、北纬、西经、南纬符号，其他相册软件可能自动按照所属地区帮助补全了这些信息，而飞牛没有自动补全，自然也就无法识别这个 GPS 位置。

在知道问题所在后，解决起来倒也容易。由于我所有照片都是在国内拍摄的，也就是自动补全北纬、东经两个符号即可。在转换时，注意开启 CPU 多线程处理，实测 7 万照片，我的 AMD 9700X 8核16线程 CPU 满载半小时搞定。转换后，将照片增量备份到移动硬盘，然后将移动硬盘数据增量备份到群晖和飞牛 NAS 即可。