copyparty 官方镜像为何不再支持 HEVC/HEICno265 构建的法律边界与 ffmpeg 定制构建实现【免费下载链接】copypartyPortable file server with accelerated resumable uploads, dedup, WebDAV, SFTP, FTP, TFTP, zeroconf, media indexer, thumbnails all in one file项目地址: https://gitcode.com/GitHub_Trending/co/copyparty本文围绕 docs/bad-codecs.md 展开它解释了 copyparty 官方 Docker 镜像与可启动 U 盘镜像为何出于法律原因无法解码 HEVC/H.265 视频和 HEIF/HEIC 图片iPhone 拍摄的照片与视频首当其冲包括缩略图。读完本篇你既能理解这一决策背后的专利池困境与作者的法律立场也能从仓库源码层面看清“HEVC 被物理剥离”的完整构建流水线——版本锚定、codec 移除清单、AAC-LC 专属补丁以及最终如何验证构建产物。一、受影响范围官方发行版丢失了哪些能力根据 docs/bad-codecs.md 的说明受法律因素限制copyparty 的Docker 镜像与可启动 U 盘bootable flashdrive镜像无法解码和显示某些特定编码的图片与视频iPhone 拍摄的照片和视频将无法工作部分三星手机可能同样受影响作者对此不完全确定上述媒体的缩略图同样无法生成——因为缩略图管线正是调用 ffmpeg 解码视频帧后生成的。这一变更在版本日志中有明确记录docs/changelog.md 中v1.20.8版本的标签即为 “no265”其中注明由于法律原因官方 docker 镜像与可启动 U 盘镜像从此无法为 HEVC/h265 视频和 HEIF/HEIC 图片创建缩略图。需要强调的是这不是运行时的“功能开关”而是二进制层面的移除——官方发行版里的 ffmpeg 里根本没有 HEVC 解码器。下文会解释为什么以及怎么做到的。二、为什么移除 HEVC专利纠缠与作者的法律立场文档明确声明以下分析是作者的个人理解“大概率是错的”IANAL我不是律师。以下是其梳理的完整逻辑链H.265/HEVC 是专利受限的编解码器分发在法律上有麻烦存在多个专利池各专利持有方的要求互相冲突且边界不清即使是 FOSS 也不被豁免——HEVC 标准虽有“免费软件条款”costless-software provision但作者认为该条款并未真正免除支付要求该条款的要求如按“销量”计费如何映射到 FOSS 项目作者毫无头绪而copyparty 没有 telemetry因此无论要求如何定义官方发行版在原则上都无法满足。主流浏览器集体回避Chrome 和 Firefox 都拒绝内置 HEVC 解码器。作者推测未咨询律师仅为推断原因在于它们做过法律评估。HEIF/HEIC 图片同样麻烦大多数 HEIF/HEIC 图片的压缩编码就是 HEVC因此问题同构。Safari 是唯一愿意解码显示 HEIF/HEIC 照片的浏览器——按作者的说法是“出于自身难辞其咎的原因”即苹果本身是专利利益相关方。替代方案已经存在作者认为根本没必要使用 HEVC——AV1 能在更小文件体积下提供更高画质、完全免费且其 HEIF 对应格式 AVIF 已在全平台浏览器中获得广泛支持。三、为什么只影响 Docker 镜像与 U 盘镜像文档给出了一个耐人寻味的比喻版税责任像拼图——谁放下最后一块拼图谁就有责任收拾那一摊子烂摊子。Docker 镜像把 copyparty 和它需要的一切软件打包成“一大坨”从源码结构看这正是法律风险的集中点。关键在于ffmpeg 是 copyparty 生态中唯一处理 HEVC 的组件。因此受影响的只有“内置 ffmpeg”的发行形态即 Docker 镜像与可启动 U 盘镜像。反过来如果你以其他方式pip、源码、包管理器、自托管等安装 copyparty你需要自行获取并提供给 copyparty 使用的 ffmpeg因此对你而言什么都没变——你提供的 ffmpeg 里有没有 HEVC 解码器由你的构建决定。仓库中多处源码印证了“copyparty 只是 ffmpeg 的调用者”这一事实scripts/docker/Dockerfile.ac 显示ac镜像copyparty Pillow FFmpeg用于图片/音视频缩略图、音频转码、媒体标签基于alpine:latest仅添加mimalloc2、bubblewrap、py3-pillow、py3-paramiko等少量包然后通过innvikler.sh ac安装 copyparty 及其配套的定制 ffmpeg 构建缩略图生成实现在 copyparty/th_srv.py 的conv_ffmpeg方法中先ffprobe探测流信息识别“视频套壳的纯音频”或attached_pic内嵌封面随后由_ffmpeg_im同文件 L951-L961拼装一条ffmpeg -i in -map 0:v:0 -vf scale... -frames:v 1命令解码一帧并写出 JPEG。整个管线完全委托给外部的 ffmpeg/ffprobe 二进制——copyparty 代码本身确实“不知道也不关心 HEVC 是什么”正如文档所抱怨的这一切都发生在 ffmpeg 那一侧。有趣的是conv_ffmpeg 中甚至对h265扩展名做了专门的 seek 策略分支但能否真正解码仍完全取决于所用的 ffmpeg 构建里有没有对应解码器。四、移除是如何做到的定制 ffmpeg 构建的源码剖析官方做法是用一套定制 ffmpeg 构建替换 Alpine Linux 仓库里的常规 ffmpeg 包HEVC 解码器被“物理剥离”——不是“禁用”disabled from use而是从构建配置中彻底排除使 HEVC 代码路径不存在于任何官方 copyparty 发行版中。构建脚本全部位于 scripts/docker/base/。1. 版本锚定verchk.sh 与 Makefile定制构建并非另起炉灶而是追踪 Alpine 官方源的 ffmpeg。scripts/docker/base/verchk.sh 的工作机制固定AVER3.24即 alpine 3.24-stable从 alpinelinux/aports 拉取该分支下musl、python3和community/ffmpeg三个APKBUILD与本地缓存副本逐一cmp一旦 ffmpeg 的APKBUILD发生变化即上游更新了构建配置就触发make -C.. ff重新构建定制包。scripts/docker/base/Makefile 中的ff目标注释为 “legally comfy”法律上心安理得它驱动构建脚本完成从源码拉取到打包成 Alpine APK 的全过程。构建脚本 arbeidspakke.sh“arbeidspakke” 即“工作包/任务包”之意生成的构建物以时间戳脚本 MD5 作为 configuration 字符串烧进二进制这一签名在 scripts/docker/base/ffmpeg-features.txt 中可见configuration: arbeidspakke-2026-06-26-...可用于核对线上镜像与仓库脚本是否同源。2. HEVC/VVC 移除清单“yeet h265”arbeidspakke.sh 首先拉取 aports 中 alpine 3.24-stable 分支的 ffmpegAPKBUILD及其全部源码包然后用一条sed把构建参数--enable-libx265原地替换为一长串--disable-*开关覆盖每一个HEVC/VVC 相关入口类别被移除的对象举例解码器hevc、hevc_qsv、hevc_rkmpp、hevc_v4l2m2m、hevc_amf、hevc_cuvid、hevc_mediacodec、hevc_oh以及vvc编码器hevc_rkmpp、hevc_amf、hevc_mediacodec、hevc_mf、hevc_nvenc、hevc_oh、hevc_qsv、hevc_v4l2m2m、hevc_vaapi、hevc_videotoolbox、hevc_vulkan硬件加速hevc_d3d11va、hevc_d3d11va2、hevc_d3d12va、hevc_dxva2、hevc_nvdec、hevc_vaapi、hevc_vdpau、hevc_videotoolbox、hevc_vulkan、vvc_vaapibitstream filterhevc_metadata、hevc_mp4toannexb、vvc_metadata、vvc_mp4toannexb解析器/解复用器/复用器hevc、vvc的 parser、demuxer、muxer同一条sed还顺带删除了x265-dev构建依赖。值得注意的是VVCH.266的痕迹也一并被剥离——文档解释原因是该编码“胎死腹中”无法与 AV1以及即将到来的 AV2竞争。脚本里还保留了一行注释掉的greparbeidspakke.sh L27展示作者是如何从allcodecs.c、hwaccels.h等源文件中枚举出全部ff_hevc_*/ff_vvc_*符号以生成完整移除清单的。3. 只保留 AAC-LCaac-lc-only.patch文档还提到 AAC 支持“也被动过手脚”现在只能解码 AAC-LC作者认为这覆盖了约 99% 的 AAC 文件几乎没人用 HE-AAC 或 AAC-LD且 LC-AAC 在相关地区已全部实现免版税。仓库中的实现是 scripts/docker/base/patch/ffmpeg/aac-lc-only.patch其文件头注释直言“移除所有高级 AAC 特性只保留在任何相关地区都不再受专利限制的 AAC-LC反正 99% 的 AAC 文件都是 LC无所谓”。补丁的关键改动decode_ga_specific_config检测到m4ac-sbr 0SBR 是 HE-AAC 的核心直接返回AVERROR_DECODER_NOT_FOUNDdecode_eld_specific_config整个函数体被替换为return AVERROR_DECODER_NOT_FOUND“kill ELD support”AOT_ER_AAC_LD分支从音频特定配置的分发逻辑中删除decode_extension_payload遇到EXT_SBR_DATA时提前返回“kill HE/SBR support”SBR 频谱表读取路径read_sbr_grid也被植入直接终止。prepare()阶段除了打这个补丁arbeidspakke.sh L33-L48还会用一段awk把libavcodec/aac/aacdec_tab.c中所有 SBR/HE 相关查找表的内容替换为无害的{ 1, 1 }占位。配套的改动源文件保存在 scripts/docker/base/patch/ffmpeg/libavcodec/ 目录aacps.c、aacsbr.c、aacsbr_fixed.c、aacsbrdata.h。4. 瘦身与“copyparty 专用白名单”移除 HEVC 之外的两个脚本段落进一步解释了体积收益的来源shrink-rayarbeidspakke.sh L51-L59禁用libbluray/dvdnav/dvdread/placebo/rav1e/shaderc/vdpau替换--enable-libxcb为禁用并连带去掉ffplay、opus编码器与metasound/twinvq解码器删除sdl2-dev依赖。脚本内注释记录了每步的体积收益例如 “metasoundtwinvq 450 KiB apk”。golflympicsarbeidspakke.sh L61-L100标题即意图——“decode-only, super-specific for copyparty only”。它把 ffmpeg 从全功能多媒体工具收敛成 copyparty 真正需要的最小子集只保留flac、libjxl、libmp3lame、libopus、libwebp、mjpeg、png、pcm_*等编码器白名单 muxeraiff、apng、matroska、mp3、webm、webp等十余种、少量滤镜scale、crop、showspectrumpic等并成批禁用冷门视频/音频解码器与几乎所有字幕解码器。5. 构建产物的验证快照ffmpeg-features.txtscripts/docker/base/ffmpeg-features.txt 是定制构建的ffmpeg -version codec/format 全量输出的存档ffmpeg 8.1.1Alpine gcc 15.2.0可用于逐条核对“移除是否彻底”解码器列表中没有任何hevc/vvc条目视频侧可见的是h264、vp9、libdav1d等音频侧保留aac、aac_fixed、aac_latm解码器其高级特性已被补丁在运行时拒绝muxer 列表与“golflympics”白名单完全一致aiff、apng、caf、ffmetadata、fifo、flac、image2、matroska、mp3、opus、pcm_f32le、s16le、wav、webm、webp、yuv4mpegpipe等说明该快照确实来自同一套构建配置。五、附带收益镜像体积减半文档把这件事称为“乌云上的银边”剥离后官方 Docker 镜像明显变小ac镜像直接腰斩——指标之前之后压缩后gzipped67 MiB35 MiB安装后installed195 MiB99 MiB从构建脚本看体积收益来自多因素叠加libx265/x265-dev与全部硬件加速后端消失、SBR 相关码表被掏空、冷门 codec/demuxer/字幕解码器成批移除以及 bluray/vdpau/sdl 等无关依赖的清理。六、如果你需要 HEVC文档的立场与源码给出的事实文档对“如何重新启用 HEVC 支持”的回答只有六个字“祝你好运”。作者明确声明他在法律上无法提供帮助甚至认为提供“如何做到”的技术解释本身都可能构成“facilitate access”协助获取。他的原话大致是copyparty 只是调用ffmpeg生成缩略图copyparty 甚至不知道 HEVC 是什么这一切都纯属 ffmpeg 侧的事情——但即便如此他也不再展开。抛开作者的法律立场仓库源码提供了两个可核实的事实供自行评估非官方镜像的部署完全不受此约束。文档原文如果你以其他方式安装 copyparty获取和提供 ffmpeg 是你自己的责任。源码印证了这一点——缩略图管线copyparty/th_srv.py只依赖 PATH/配置中找到的ffmpeg/ffprobe二进制且版本日志中记录过“支持自定义 ffmpeg/ffprobe 二进制名称/路径”的选项。也就是说在自管部署中你使用哪个 ffmpeg 构建就拥有哪个 ffmpeg 的解码能力相应地该构建的合规性也完全由使用者自己承担。官方镜像内的定制 ffmpeg 以 Alpine APK 形式分发见 scripts/docker/base/README.md构建脚本与补丁全部开源可审计。如果你关心自己的 HEVC 需求理解 arbeidspakke.sh 中那段移除清单就是理解“官方构建到底删了什么”的最直接入口。小结docs/bad-codecs.md 记录的不是一次普通的依赖变更而是 FOSS 项目面对专利池压力时的一次“二进制层面切割”HEVC 解码器连同全部 VVC 痕迹从官方发行版中被物理移除AAC 收敛到免版税的 LC 子集同时借“copyparty 专用白名单”把官方镜像瘦身近半。对使用者而言规则简单清晰——官方 Docker/U 盘镜像不提供 HEVC 与 HEIC 解码其余部署方式则完全取决于你自己提供的 ffmpeg。仓库中的 scripts/docker/base/ 目录是这一决策全部技术细节的唯一权威来源建议与 docs/changelog.md 中no265条目对照阅读。【免费下载链接】copypartyPortable file server with accelerated resumable uploads, dedup, WebDAV, SFTP, FTP, TFTP, zeroconf, media indexer, thumbnails all in one file项目地址: https://gitcode.com/GitHub_Trending/co/copyparty创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 copyparty 官方镜像为何不再支持 HEVC/HEIC：no265 构建的法律边界与 ffmpeg 定制构建实现
copyparty 官方镜像为何不再支持 HEVC/HEICno265 构建的法律边界与 ffmpeg 定制构建实现【免费下载链接】copypartyPortable file server with accelerated resumable uploads, dedup, WebDAV, SFTP, FTP, TFTP, zeroconf, media indexer, thumbnails all in one file项目地址: https://gitcode.com/GitHub_Trending/co/copyparty本文围绕 docs/bad-codecs.md 展开它解释了 copyparty 官方 Docker 镜像与可启动 U 盘镜像为何出于法律原因无法解码 HEVC/H.265 视频和 HEIF/HEIC 图片iPhone 拍摄的照片与视频首当其冲包括缩略图。读完本篇你既能理解这一决策背后的专利池困境与作者的法律立场也能从仓库源码层面看清“HEVC 被物理剥离”的完整构建流水线——版本锚定、codec 移除清单、AAC-LC 专属补丁以及最终如何验证构建产物。一、受影响范围官方发行版丢失了哪些能力根据 docs/bad-codecs.md 的说明受法律因素限制copyparty 的Docker 镜像与可启动 U 盘bootable flashdrive镜像无法解码和显示某些特定编码的图片与视频iPhone 拍摄的照片和视频将无法工作部分三星手机可能同样受影响作者对此不完全确定上述媒体的缩略图同样无法生成——因为缩略图管线正是调用 ffmpeg 解码视频帧后生成的。这一变更在版本日志中有明确记录docs/changelog.md 中v1.20.8版本的标签即为 “no265”其中注明由于法律原因官方 docker 镜像与可启动 U 盘镜像从此无法为 HEVC/h265 视频和 HEIF/HEIC 图片创建缩略图。需要强调的是这不是运行时的“功能开关”而是二进制层面的移除——官方发行版里的 ffmpeg 里根本没有 HEVC 解码器。下文会解释为什么以及怎么做到的。二、为什么移除 HEVC专利纠缠与作者的法律立场文档明确声明以下分析是作者的个人理解“大概率是错的”IANAL我不是律师。以下是其梳理的完整逻辑链H.265/HEVC 是专利受限的编解码器分发在法律上有麻烦存在多个专利池各专利持有方的要求互相冲突且边界不清即使是 FOSS 也不被豁免——HEVC 标准虽有“免费软件条款”costless-software provision但作者认为该条款并未真正免除支付要求该条款的要求如按“销量”计费如何映射到 FOSS 项目作者毫无头绪而copyparty 没有 telemetry因此无论要求如何定义官方发行版在原则上都无法满足。主流浏览器集体回避Chrome 和 Firefox 都拒绝内置 HEVC 解码器。作者推测未咨询律师仅为推断原因在于它们做过法律评估。HEIF/HEIC 图片同样麻烦大多数 HEIF/HEIC 图片的压缩编码就是 HEVC因此问题同构。Safari 是唯一愿意解码显示 HEIF/HEIC 照片的浏览器——按作者的说法是“出于自身难辞其咎的原因”即苹果本身是专利利益相关方。替代方案已经存在作者认为根本没必要使用 HEVC——AV1 能在更小文件体积下提供更高画质、完全免费且其 HEIF 对应格式 AVIF 已在全平台浏览器中获得广泛支持。三、为什么只影响 Docker 镜像与 U 盘镜像文档给出了一个耐人寻味的比喻版税责任像拼图——谁放下最后一块拼图谁就有责任收拾那一摊子烂摊子。Docker 镜像把 copyparty 和它需要的一切软件打包成“一大坨”从源码结构看这正是法律风险的集中点。关键在于ffmpeg 是 copyparty 生态中唯一处理 HEVC 的组件。因此受影响的只有“内置 ffmpeg”的发行形态即 Docker 镜像与可启动 U 盘镜像。反过来如果你以其他方式pip、源码、包管理器、自托管等安装 copyparty你需要自行获取并提供给 copyparty 使用的 ffmpeg因此对你而言什么都没变——你提供的 ffmpeg 里有没有 HEVC 解码器由你的构建决定。仓库中多处源码印证了“copyparty 只是 ffmpeg 的调用者”这一事实scripts/docker/Dockerfile.ac 显示ac镜像copyparty Pillow FFmpeg用于图片/音视频缩略图、音频转码、媒体标签基于alpine:latest仅添加mimalloc2、bubblewrap、py3-pillow、py3-paramiko等少量包然后通过innvikler.sh ac安装 copyparty 及其配套的定制 ffmpeg 构建缩略图生成实现在 copyparty/th_srv.py 的conv_ffmpeg方法中先ffprobe探测流信息识别“视频套壳的纯音频”或attached_pic内嵌封面随后由_ffmpeg_im同文件 L951-L961拼装一条ffmpeg -i in -map 0:v:0 -vf scale... -frames:v 1命令解码一帧并写出 JPEG。整个管线完全委托给外部的 ffmpeg/ffprobe 二进制——copyparty 代码本身确实“不知道也不关心 HEVC 是什么”正如文档所抱怨的这一切都发生在 ffmpeg 那一侧。有趣的是conv_ffmpeg 中甚至对h265扩展名做了专门的 seek 策略分支但能否真正解码仍完全取决于所用的 ffmpeg 构建里有没有对应解码器。四、移除是如何做到的定制 ffmpeg 构建的源码剖析官方做法是用一套定制 ffmpeg 构建替换 Alpine Linux 仓库里的常规 ffmpeg 包HEVC 解码器被“物理剥离”——不是“禁用”disabled from use而是从构建配置中彻底排除使 HEVC 代码路径不存在于任何官方 copyparty 发行版中。构建脚本全部位于 scripts/docker/base/。1. 版本锚定verchk.sh 与 Makefile定制构建并非另起炉灶而是追踪 Alpine 官方源的 ffmpeg。scripts/docker/base/verchk.sh 的工作机制固定AVER3.24即 alpine 3.24-stable从 alpinelinux/aports 拉取该分支下musl、python3和community/ffmpeg三个APKBUILD与本地缓存副本逐一cmp一旦 ffmpeg 的APKBUILD发生变化即上游更新了构建配置就触发make -C.. ff重新构建定制包。scripts/docker/base/Makefile 中的ff目标注释为 “legally comfy”法律上心安理得它驱动构建脚本完成从源码拉取到打包成 Alpine APK 的全过程。构建脚本 arbeidspakke.sh“arbeidspakke” 即“工作包/任务包”之意生成的构建物以时间戳脚本 MD5 作为 configuration 字符串烧进二进制这一签名在 scripts/docker/base/ffmpeg-features.txt 中可见configuration: arbeidspakke-2026-06-26-...可用于核对线上镜像与仓库脚本是否同源。2. HEVC/VVC 移除清单“yeet h265”arbeidspakke.sh 首先拉取 aports 中 alpine 3.24-stable 分支的 ffmpegAPKBUILD及其全部源码包然后用一条sed把构建参数--enable-libx265原地替换为一长串--disable-*开关覆盖每一个HEVC/VVC 相关入口类别被移除的对象举例解码器hevc、hevc_qsv、hevc_rkmpp、hevc_v4l2m2m、hevc_amf、hevc_cuvid、hevc_mediacodec、hevc_oh以及vvc编码器hevc_rkmpp、hevc_amf、hevc_mediacodec、hevc_mf、hevc_nvenc、hevc_oh、hevc_qsv、hevc_v4l2m2m、hevc_vaapi、hevc_videotoolbox、hevc_vulkan硬件加速hevc_d3d11va、hevc_d3d11va2、hevc_d3d12va、hevc_dxva2、hevc_nvdec、hevc_vaapi、hevc_vdpau、hevc_videotoolbox、hevc_vulkan、vvc_vaapibitstream filterhevc_metadata、hevc_mp4toannexb、vvc_metadata、vvc_mp4toannexb解析器/解复用器/复用器hevc、vvc的 parser、demuxer、muxer同一条sed还顺带删除了x265-dev构建依赖。值得注意的是VVCH.266的痕迹也一并被剥离——文档解释原因是该编码“胎死腹中”无法与 AV1以及即将到来的 AV2竞争。脚本里还保留了一行注释掉的greparbeidspakke.sh L27展示作者是如何从allcodecs.c、hwaccels.h等源文件中枚举出全部ff_hevc_*/ff_vvc_*符号以生成完整移除清单的。3. 只保留 AAC-LCaac-lc-only.patch文档还提到 AAC 支持“也被动过手脚”现在只能解码 AAC-LC作者认为这覆盖了约 99% 的 AAC 文件几乎没人用 HE-AAC 或 AAC-LD且 LC-AAC 在相关地区已全部实现免版税。仓库中的实现是 scripts/docker/base/patch/ffmpeg/aac-lc-only.patch其文件头注释直言“移除所有高级 AAC 特性只保留在任何相关地区都不再受专利限制的 AAC-LC反正 99% 的 AAC 文件都是 LC无所谓”。补丁的关键改动decode_ga_specific_config检测到m4ac-sbr 0SBR 是 HE-AAC 的核心直接返回AVERROR_DECODER_NOT_FOUNDdecode_eld_specific_config整个函数体被替换为return AVERROR_DECODER_NOT_FOUND“kill ELD support”AOT_ER_AAC_LD分支从音频特定配置的分发逻辑中删除decode_extension_payload遇到EXT_SBR_DATA时提前返回“kill HE/SBR support”SBR 频谱表读取路径read_sbr_grid也被植入直接终止。prepare()阶段除了打这个补丁arbeidspakke.sh L33-L48还会用一段awk把libavcodec/aac/aacdec_tab.c中所有 SBR/HE 相关查找表的内容替换为无害的{ 1, 1 }占位。配套的改动源文件保存在 scripts/docker/base/patch/ffmpeg/libavcodec/ 目录aacps.c、aacsbr.c、aacsbr_fixed.c、aacsbrdata.h。4. 瘦身与“copyparty 专用白名单”移除 HEVC 之外的两个脚本段落进一步解释了体积收益的来源shrink-rayarbeidspakke.sh L51-L59禁用libbluray/dvdnav/dvdread/placebo/rav1e/shaderc/vdpau替换--enable-libxcb为禁用并连带去掉ffplay、opus编码器与metasound/twinvq解码器删除sdl2-dev依赖。脚本内注释记录了每步的体积收益例如 “metasoundtwinvq 450 KiB apk”。golflympicsarbeidspakke.sh L61-L100标题即意图——“decode-only, super-specific for copyparty only”。它把 ffmpeg 从全功能多媒体工具收敛成 copyparty 真正需要的最小子集只保留flac、libjxl、libmp3lame、libopus、libwebp、mjpeg、png、pcm_*等编码器白名单 muxeraiff、apng、matroska、mp3、webm、webp等十余种、少量滤镜scale、crop、showspectrumpic等并成批禁用冷门视频/音频解码器与几乎所有字幕解码器。5. 构建产物的验证快照ffmpeg-features.txtscripts/docker/base/ffmpeg-features.txt 是定制构建的ffmpeg -version codec/format 全量输出的存档ffmpeg 8.1.1Alpine gcc 15.2.0可用于逐条核对“移除是否彻底”解码器列表中没有任何hevc/vvc条目视频侧可见的是h264、vp9、libdav1d等音频侧保留aac、aac_fixed、aac_latm解码器其高级特性已被补丁在运行时拒绝muxer 列表与“golflympics”白名单完全一致aiff、apng、caf、ffmetadata、fifo、flac、image2、matroska、mp3、opus、pcm_f32le、s16le、wav、webm、webp、yuv4mpegpipe等说明该快照确实来自同一套构建配置。五、附带收益镜像体积减半文档把这件事称为“乌云上的银边”剥离后官方 Docker 镜像明显变小ac镜像直接腰斩——指标之前之后压缩后gzipped67 MiB35 MiB安装后installed195 MiB99 MiB从构建脚本看体积收益来自多因素叠加libx265/x265-dev与全部硬件加速后端消失、SBR 相关码表被掏空、冷门 codec/demuxer/字幕解码器成批移除以及 bluray/vdpau/sdl 等无关依赖的清理。六、如果你需要 HEVC文档的立场与源码给出的事实文档对“如何重新启用 HEVC 支持”的回答只有六个字“祝你好运”。作者明确声明他在法律上无法提供帮助甚至认为提供“如何做到”的技术解释本身都可能构成“facilitate access”协助获取。他的原话大致是copyparty 只是调用ffmpeg生成缩略图copyparty 甚至不知道 HEVC 是什么这一切都纯属 ffmpeg 侧的事情——但即便如此他也不再展开。抛开作者的法律立场仓库源码提供了两个可核实的事实供自行评估非官方镜像的部署完全不受此约束。文档原文如果你以其他方式安装 copyparty获取和提供 ffmpeg 是你自己的责任。源码印证了这一点——缩略图管线copyparty/th_srv.py只依赖 PATH/配置中找到的ffmpeg/ffprobe二进制且版本日志中记录过“支持自定义 ffmpeg/ffprobe 二进制名称/路径”的选项。也就是说在自管部署中你使用哪个 ffmpeg 构建就拥有哪个 ffmpeg 的解码能力相应地该构建的合规性也完全由使用者自己承担。官方镜像内的定制 ffmpeg 以 Alpine APK 形式分发见 scripts/docker/base/README.md构建脚本与补丁全部开源可审计。如果你关心自己的 HEVC 需求理解 arbeidspakke.sh 中那段移除清单就是理解“官方构建到底删了什么”的最直接入口。小结docs/bad-codecs.md 记录的不是一次普通的依赖变更而是 FOSS 项目面对专利池压力时的一次“二进制层面切割”HEVC 解码器连同全部 VVC 痕迹从官方发行版中被物理移除AAC 收敛到免版税的 LC 子集同时借“copyparty 专用白名单”把官方镜像瘦身近半。对使用者而言规则简单清晰——官方 Docker/U 盘镜像不提供 HEVC 与 HEIC 解码其余部署方式则完全取决于你自己提供的 ffmpeg。仓库中的 scripts/docker/base/ 目录是这一决策全部技术细节的唯一权威来源建议与 docs/changelog.md 中no265条目对照阅读。【免费下载链接】copypartyPortable file server with accelerated resumable uploads, dedup, WebDAV, SFTP, FTP, TFTP, zeroconf, media indexer, thumbnails all in one file项目地址: https://gitcode.com/GitHub_Trending/co/copyparty创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考