我一直在绞尽脑汁尝试让 NGINX 缓存 HTTPS 反向代理服务器正确缓存实时 DASH 和 HLS 视频流。
我目前的想法是，我的主要问题可能是 NGINXproxy_cache_valid指令似乎与文件进入缓存的时间有关。我认为我需要的是缓存保留与标头字段相关。NGINX 通过和Last-Modified提供对此的访问，但我尚未找到如何将“Last-Modified + 10 秒”设置为缓存过期时间。sub_filter_last_modified on$upstream_http_last_modified
- 有没有办法设置
proxy_cache_valid为“Last-Modified + 10秒”？
我发现的另一种可能的方法是让后端X-Accel-Expires为标题字段提供@（参考：http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_valid）。
X-Accel-ExpiresNGINX 缓存实时媒体内容的“最正确”方式是怎样的？我还应该调查其他更好的方法吗？
提前致谢。 （这是我第三次尝试这个问题，之前的问题太模糊，无法得到有用的答案。）
对于那些不熟悉 HTTP 实时视频流的人来说，以下是一些背景/概述/上下文：
视频流从数字电视调谐器 (ATSC @ 1080i) 提供的 MPEG 传输流 (TS) 开始，然后将其馈送到 MPEG 转码器 (带硬件辅助的 ffmpeg)，该转码器实时生成 CBR (恒定比特率) 中的 3 种分辨率 (720p、480p、360p)，然后将其馈送到打包器 (例如，GPAC 或 Shaka)，打包器生成动态媒体文件 (清单/播放列表 + 音频 + 视频) 以进行带宽自适应流式传输（例如，WiFi 衰落会导致分辨率降低，当带宽提高时会自动提高）。
每 2-10 秒（“分段时间”）会创建新文件集，具体取决于打包程序的配置方式；我们目前使用 10 秒分段来尽量减少传输次数，但我们希望最终能将分段时间缩短到 2 秒以尽量减少延迟。所有这些文件都由 NGINX 通过列出可用直播流的简单页面提供。
为了让您了解其规模，单个 1080i 输入会生成 3 个 CBR 流，每个流都会打包为 DASH 和 HLS，每个输入流会创建 6 个输出流。总的来说，打包器每 10 秒为每个 1080i 输入输出 10 个文件。对于 24 个 1080i 输入（在许多城市并不罕见），每 10 秒就会生成 240 个新文件，或者每小时生成 86,400 个新文件。缓存的大小为 1 分钟的历史记录，或者 1,440 个媒体文件（<1 GB）。
视频和音频片段文件（包含 MPEG 数据）使用唯一名称创建，因此在缓存已满的情况下让它们按 LRU 排序是没有问题的。但 DASH 清单和 HLS 播放列表是格式化的文本文件，每个片段都会重写（以列出新的音频和视频片段文件），因此更新时必须替换清单/播放列表。
调谐器-转码器-打包器在其工作中表现出色，但它并不是一个出色的 Web 服务器，因为超过十几个客户端，这主要是由于 HTTPS 的开销。需要外部缓存 HTTPS 反向代理来最大限度地减少这种负载，其工作是无论实际有多少视频用户，都看起来像一个客户端。但是，视频用户不应该知道缓存反向代理的存在，因此始终拥有正确的缓存至关重要。
我现在看到缓存中的视频偶尔会冻结，尽管它可以直接从视频服务器播放。HLS 比 DASH 更快，但两者都会在 1-8 小时内冻结。
视频服务器和缓存反向代理都运行 NGINX 来利用（调整/优化）组合功能集。
答案1
我发现用于流媒体服务器的 NGINX 缓存 HTTPS 反向代理的最佳工作示例来自这里：https://docs.peer5.com/guides/use-nginx-as-wowza-cache/
它仅需要针对我的特定环境进行微小的修改。