对于IPTV-API的一些优化行建议

[HiColinMe]

🎯 IPTV-API 项目优化建议

🙏 致谢

首先衷心感谢作者维护这个优秀的项目！🎉 为广大IPTV爱好者提供了极其实用的源筛选工具。感谢开源力量，感谢作者的持续付出和贡献！❤️

💡 优化建议

以下建议基于个人使用体验，按实用性从高到低排序，主要围绕项目优化展开。

📋 背景说明

IPTV-API 的设计定位是一个长期运行、定时检测、筛选个性化IPTV源列表的工具。基于这一功能特性，部署在家庭网络环境（如家庭NAS）中筛选出的结果必然是最适合当前网络环境的。

随着飞牛OS等国产NAS系统的普及，未来运行IPTV-API的主要环境将是Docker容器。因此，以下建议均基于Docker部署场景提出。

---

🚀 核心优化建议

1. 🎯 测速标准分离

现状问题：
目前测速逻辑采用统一的速率标准（如 0.8 M/s），但不同分辨率的源对带宽需求差异很大。

具体场景：

• 对于免费源，720P分辨率通常已足够观看
• 设置 min_speed = 0.6 M/s 对720P足够，但对1080P往往不足
• 统一标准导致要么过度过滤，要么质量不足

建议方案：
将测速标准与分辨率关联，例如：

• 📺 1080P 源：最低 1.2 M/s
• 📺 720P 源：最低 0.6 M/s
• 📺 480P 源：最低 0.3 M/s

2. ⚡ 提高测速效率

现状分析：
目前似乎对所有地址采用相同的测速逻辑，如果设置超时10秒，可能会对每个连接都进行完整时长测试。

优化思路：
在正式测速前，先对待测地址进行粗筛：

• 🔍 快速检测HTTP连接状态
• 🚫 过滤完全无法访问的"死链接"
• ⏱️ 减少无效测速时间消耗

价值体现：
在6000+的地址中，有相当一部分对于用户本地网络就是不可达的，提前过滤能大幅提升整体测速效率。

3. 🌐 测速代理分离

当前问题：
用户通过环境变量设置 http_proxy 后，虽然加速了GitHub资源下载，但会导致测速结果失真。

解决方案（二选一）：

方案A（推荐）：

环境变量：PROXY_ADDR=127.0.0.1:1080

• ✅ 仅源文件下载使用代理
• ✅ 测速直连，结果准确
• ✅ 侵入性最小，符合常规工具使用习惯

方案B：
测速时临时屏蔽 http_proxy 环境变量

4. 🎨 画面内容过滤

🔄 循环画面检测

现象：
某些源显示"此源已加密..."等静态提示画面。

技术思路：
使用ffmpeg获取不同时间点的帧画面，计算相似度：

• ⏰ 第0、2、3...秒采样
• 📊 相似度>90%视为静态画面
• 🤔 但需考虑夜间节目确实使用静态画面的特殊情况

⬛ 黑画面问题

现象：
PotPlayer等播放器经常遇到：

• ❌ 不是纯音频源
• ❓ 但无法正常显示画面（黑屏）
• 🔍 分辨率检测正常但仍无法播放

现状：
普通无画面（分辨率none）的源已被过滤，但这种"黑画面"问题仍需进一步研究解决。

---

💭 结语

以上建议基于实际使用中的痛点提出，希望能为项目的进一步完善提供参考。再次感谢作者的辛勤付出！🎊

期待IPTV-API越来越好，为更多用户带来优质的观影体验！ 📺✨

[Guovin]

谢谢你的建议，内容标准美观👍，我会根据你的建议作出优化改进。

针对2,3点解释一下：
2：其实项目在下载测速前会校验状态码，如果符合有效才会进行下载测试，并不是所有接口都会执行完整的下载测试。后续会分离状态码校验超时配置和下载测速超时配置。
3：Github订阅源使用cdn_url代理加速获取内容，代理只参与文本内容获取阶段，并不会参与到测速阶段，所以你不用担心接口会被代理测速与实际使用产生误差，实际目前这并没有发生。

[HiColinMe]

🔧 关于代理设置的补充说明

感谢您的回复！

关于第2点，看来您在设计测速逻辑时已经考虑得很周到了。

重点想再详细说明第3点，可能我之前的表述不够完整，导致有些误解：

🐳 Docker 容器运行机制说明

我不清楚您对docker容器的机制了解程度,所以允许我首先补充一些关于 Docker 容器运行的小知识(班门弄斧哈哈)：

所有容器启动后，都会接收用户在启动命令中设置的环境变量，即使 Dockerfile 中没有预先定义这些变量。

HTTP_PROXY 是一个特殊的环境变量。当容器接收到这个变量后，在容器内部（至少 shell 环境没有特殊处理的情况下），所有默认命令都会自动使用这个代理设置。

📝 实际使用场景

有一次,我在部署 IPTV-API 的过程中，发现公众号提供的 CDN 静态资源加速链接都失效了。因此我在启动容器时添加了代理环境变量（在 NAS 的 10808 端口部署了加速代理）：

environment:
  - TZ=Asia/Shanghai
  - HTTP_PROXY=http://127.0.0.1:10808
  - HTTPS_PROXY=http://127.0.0.1:10808

添加这些环境变量后，容器内拉取 GitHub 静态文件确实成功了。

⚠️ 产生的问题

但这样带来了一个新问题：如前面所述，容器内所有的命令都会走代理（除非在新的 shell 环境中特别处理）。那么就有一种可能,测速命令也走了代理.(这个需要您来确认,如果您确认测速命令在执行的时候没有继承容器的环境变量,那这个问题到此就结束了.)

💡 建议的解决方案

我建议设置一个专门的变量，仅在获取 GitHub 资源时使用代理。

简单来说：HTTP_PROXY 是一个特殊变量，但是我们不希望容器内所有命令都走代理。

比如在 Dockerfile 中设置参数：

PROXY_ADDR=

然后在下载 GitHub 静态资源时，手动指定代理(curl和wget都支持这个功能),示例如下：

wget -e use_proxy=yes -e http_proxy=${PROXY_ADDR} https://raw.github...

或者类似的机制，让代理使用更加精确可控。

[Guovin]

想要解决你的问题很简单，你无需设置HTTP_PROXY环境变量，通过设置cdn_url环境变量来实现代理获取github资源，因为它不会作用于测速。
至于你说的公众号获取的cdn失效问题，目前经过检查，全部都是有效的。
cdn_url是最简单的方式，也是最容易获取的代理，因为并不是所有人都能搭建一个可靠的http_proxy代理，这是基于此情况考虑的。
后续会增加http_proxy配置项，目前也有人提交了PR（#1201），但这是同时作用于资源获取与测速阶段的代理，目前由于代码存在一些问题，并未合并。