增加禁用m3u8缓存选项

[Mishasama]

现在貌似是一个固定的缓存存活时间，对于特定的抓包任务来说不太合适……（比如抓直播）
这种时候m3u8在服务器上的更新间隔基本上跟1~2个TS的时长相等。比如Twitch直播目前的TS最大生存时间大约在60s~90s之间，缓存刷新间隔太长会导致漏抓。（B站现在人员流动太大，经常改朝换代说不清楚）

希望能加个选项手动刷新或者直接不要缓存m3u8，在每次点击下载的时候都重新获取m3u8。

如果能针对这个用途在完成第3阶段的下载任务后，自动循环开始1~3阶段，直至用户手动停止（或者达到特定的时长都没有获取到新TS文件就自动停止）就更好了！

---

另外问一下，在同时启用上图中的两个功能后，依然会出现第4阶段分析TS文件，是不是BUG？
貌似没有意义，且会造成时间和计算资源的浪费。

最后祝大佬新春大吉🧨

[orestonce]

在同时启用上图中的两个功能后，依然会出现第4阶段分析TS文件，是不是BUG？
回复问题：不是bug。

• 我看了代码，原因是要生成ffmpeg合并ts文件的命令，所以需要分析每个ts文件的分辨率。把相同分辨率的ts文件找出来，才能最终输出ffmpeg合并命令。

[orestonce]

• 目前的缓存逻辑建立在 m3u8本身的内容是固定不变的，然后将m3u8内取的第一个文件保存为0001.ts，第二个保存为0002,ts，以此类推。
• 直播的ts状态我看了，m3u8的文件内容会变化，例如一开始是 a.ts、b.ts、c.ts，过几秒钟自动变为b.ts、c.ts、d.ts以此类推。
• 所以目前的缓存ts文件内容的逻辑并不能正确的直播m3u8。如果要实现下载直播内容，需要新出一种“下载直播模式”，单独一个线程跟进m3u8的内容变化，将解析出来的源源不断的ts文件url投递给ts下载线程，并且保存的文件名也不能使0001.ts,0002.ts这样的了，只能和ts在服务器上的文件名相同才能便于缓存（较为复杂）。

[orestonce]

而且下载下来的m4s内容我也不会合并，所以目前搁置了：

#EXTM3U
#EXT-X-VERSION:7
#EXT-X-START:TIME-OFFSET=0
#EXT-X-MEDIA-SEQUENCE:99966723
#EXT-X-TARGETDURATION:1
#EXT-X-MAP:URI="h1740916596.m4s"
#EXT-BILI-AUX:faea3e|K|9150c|b4c4e027
#EXTINF:1.00,9150c|b4c4e027
99966723.m4s
#EXT-BILI-AUX:faedf3|N|75a81|4803ebd7
#EXTINF:1.00,75a81|4803ebd7
99966724.m4s
#EXT-BILI-AUX:faf20e|K|86976|af32ebfc
#EXTINF:1.00,86976|af32ebfc
99966725.m4s
#EXT-BILI-AUX:faf5e5|N|68476|39fb4f7e
#EXTINF:1.00,68476|39fb4f7e
99966726.m4s
#EXT-BILI-AUX:faf9de|K|9256c|a29683f3
#EXTINF:1.00,9256c|a29683f3
99966727.m4s

[Mishasama]

• 直播的ts状态我看了，m3u8的文件内容会变化，例如一开始是 a.ts、b.ts、c.ts，过几秒钟自动变为b.ts、c.ts、d.ts以此类推。
• 所以目前的缓存ts文件内容的逻辑并不能正确的直播m3u8。如果要实现下载直播内容，需要新出一种“下载直播模式”，单独一个线程跟进m3u8的内容变化，将解析出来的源源不断的ts文件url投递给ts下载线程，并且保存的文件名也不能使0001.ts,0002.ts这样的了，只能和ts在服务器上的文件名相同才能便于缓存（较为复杂）。

1. Twitch 没有这样恶心人，是简单的从0开始不断追加，希望能对应一下这样相对“老实”的做法。
2. 另外针对这种情况，我觉得你可以看看TS文件有没有服务器时间戳，也许可以利用目前的时间戳功能来给TS重命名。

• 我看了代码，原因是要生成ffmpeg合并ts文件的命令，所以需要分析每个ts文件的分辨率。把相同分辨率的ts文件找出来，才能最终输出ffmpeg合并命令。

既然用户选择不合并，那生成它干啥？
如果要在后期再合并，那后期合并的时候再分析不行吗？

---

目前最急需的就是缓存刷新的问题，先来个去缓存，其它的都可以慢慢来。

[orestonce]

Twitch 没有这样恶心人，是简单的从0开始不断追加，希望能对应一下这样相对“老实”的做法。
另外针对这种情况，我觉得你可以看看TS文件有没有服务器时间戳，也许可以利用目前的时间戳功能来给TS重命名。

• 这两种情况不具备通用性，太特殊了，我不赞同如此做。

---

• 界面上"不合并” 的意思的是在我的软件上不合并，可能要用ffmpeg合并，所以会生成ffmpeg的合并命令；另外我之前想过增设一个"生存ffmpeg合并"命令的做法，但感觉界面太繁杂了，功能又不常用，所以没做。
• 目前会做 “后期合并的时候再分析” 的动作。

---

• 目前就算做了一直刷新m3u8内容，也不能合并和播放，只能下载出一堆的.m4s文件，没用。看文章好像和”#EXT-X-MAP:URI="h1740916596.m4s"“ 标签有关，但是我没分析明白。

[Mishasama]

• 这两种情况不具备通用性，太特殊了，我不赞同如此做。

不会吧？使用TS文件时间的话应该是通用的，没有网站会特意地去清洗文件时间吧？
而且我看你的M3U8中的m4s也是正常的升序序列啊。并不是乱序编码的。

• 目前就算做了一直刷新m3u8内容，也不能合并和播放，只能下载出一堆的.m4s文件，没用。看文章好像和”#EXT-X-MAP:URI="h1740916596.m4s"“ 标签有关，但是我没分析明白。

首先搞清楚单个文件能解码不？是不是你播放器的问题？
https://www.bilibili.com/opus/614656987392205263

[orestonce]

他这个和我遇到的情况不同，他用客户端缓存数据，下载下来后是 video.m4s 和 audio.m4s 两个大文件。
我遇到的是m3u8内容只有多个极小的 xxx.m4s，用ffmpeg合并都识别不了。

[Mishasama]

他这个和我遇到的情况不同，他用客户端缓存数据，下载下来后是 video.m4s 和 audio.m4s 两个大文件。 我遇到的是m3u8内容只有多个极小的 xxx.m4s，用ffmpeg合并都识别不了。

这是要token的加密流吧？小文件证明获取到的是空容器，里面只有文件头，没有实际流数据。你要先用Mediainfo这个软件来检查单个m4s到底有什么在里面，能不能播。别一开始就先合并，这样无法查因。
B站直播我记得有部分是加密的，不一定什么房间都能直接抓取。

另外B站现在严格限制登入和IP之类的校验（比如海外的用户就不能看），可能进一步加大抓取难度。（说实话这种情况还不如直接放弃破站，也许已经超出能力范围了）