HLS.js / Wowza / Cloudfront Browser在编码器重新启动后不下载媒体

Question

我的工作流程是：

• [使用ffmpeg，我将RTMP流发送到WOWZA App1。
• App1将流发送到内部第二个应用（App2）。
• App2将代码转码并打包为hls，这是Cloudfront分发的起源。
• Cloudfront将流提供给用户。
• 用户的播放器基于HLS.js。

为了准备不同的场景，我迫使App2在测试传输期间重新启动，在这种情况下，App1仍从ffmpeg接收流，并尝试将其发送到App2，在app2准备就绪后，此链接再次建立，App1继续发送流到App2，但客户端没有视频。

• 在重新启动之前，chunklist.m3u8列出许多块，直到第17个：media-u3510ez40_17.ts
• 然后，当App2重新启动chunklist.m3u8时不存在，cloudfront发送404错误。
• 然后，当App2返回时，chunklist.m3u8列出了一个从1开始的，具有新ID的块的新列表：media-u1ofkjj9w_1.ts

问题是没有视频，网络流量表明浏览器没有下载列出的新块。

[chunklist.m3u8继续添加新的块，但是浏览器不会下载其中的任何块...直到出现第18个块...并且视频重新启动。

我尝试了很多次，问题是一样的，在重新启动之前，最后一个块的编号为N，并且在重新启动之后，直到到达deN+1Chunk之前，没有视频，但是ID不同。

我不知道此问题是否在Wowza，Cloudfront或HLS.js播放器上：/

chunklist.m3u8重新启动之前：

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:9
#EXT-X-MEDIA-SEQUENCE:1
#EXT-X-DISCONTINUITY-SEQUENCE:0
#EXTINF:8.333,
media-u3510ez40_1.ts
#EXTINF:8.333,
media-u3510ez40_2.ts
#EXTINF:8.334,
.
.
. 
media-u3510ez40_16.ts
#EXTINF:8.333,
media-u3510ez40_17.ts

chunklist.m3u8重新启动后：

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:17
#EXT-X-MEDIA-SEQUENCE:1
#EXT-X-DISCONTINUITY-SEQUENCE:0
#EXTINF:16.396,
media-u1ofkjj9w_1.ts
#EXTINF:8.333,
media-u1ofkjj9w_2.ts
.
.
.
media-u1ofkjj9w_16.ts
#EXTINF:8.333,
media-u1ofkjj9w_17.ts
#EXTINF:8.333,
media-u1ofkjj9w_18.ts

Answer 1

在Wowza Streaming Engine应用程序的“添加自定义属性”部分中，

您需要将cupertinoCalculateChunkIDBasedOnTimecode属性设置为true。引用此：https://www.wowza.com/docs/how-to-configure-apple-hls-packetization-cupertinostreaming

另外，请注意，这对于将同步时间码发送到Wowza的编码器会有所帮助。对于不发送同步时间码的编码器，无论是否发送编码器，我都建议实施绝对时间码。这将帮助应用程序在重启后从N + 1个块号中恢复。

以下页面将帮助您正确配置它。http://thewowza.guru/how-to-set-stream-timecodes-to-absolute-time/

关于会话ID更改部分，当使用Wowza作为Cloudfront分发的来源时，您需要启用httpOriginMode并禁用httpRandomizeMediaName以使其正常运行。下面的Wowza文档将帮助您正确设置它，https://www.wowza.com/docs/how-to-configure-a-wowza-server-as-an-http-caching-origin