我发现了一种更好的分割视频的方式，用tsmuxer对视频进行分割，它可以指定文件大小而非时间，当然由于mpeg视频压缩的特性copy方式分割视频只能分割到指定大小或者时间后的第一个关键帧，但实测它分割后分片大小更加均匀，而且超出8MB的比例更少🤔

现在问题是它只能分割视频，却没法生成m3u8文件，我得想个办法生成m3u8🤔其实m3u8里面最需要填进去的参数是每个片段的时间，这个好办，ffprobe每个文件遍历一遍🤔另外尽管ffmpeg只能生成定长片段，但当你打开一个ffmpeg生成的m3u8时会发现它的时间仍然是不定长的（原因很明显，它只能分割到下一个关键帧）🤔所以，我无端猜测hls肯定允许视频不定长🤔

终于，我们可以对ffmpeg的那种瞎激霸猜测分片时间的antics说再见了，并开始迎接更科学（大嘘）的分片法🤔有一段时间我觉得我可以去研究dash了，但发现还是hls安逸🤔

我现在还在研究如何生成m3u8，并将tsmuxer部署到linux服务器上🤔

hitler plans

https://cdn.discordapp.com/attachments/687774017008041994/835598215213482004/hitlerplans.m3u8

完全可用，奇怪的是浏览器仍然没法正常加载，但用mpv就一点问题都没有🤔手机那边也能正常加载，毕竟hls是苹果力推的协议，google也表示了支持🤔这样的话，我干脆把原版m2ts用txmuxer分成比如5MB分片得了，省去转换音频的步骤🤔

这大概是unterganger社区（迫真）里程碑的进步，在我加进去若干年之后我们终于可以在discord tube上观看bdmv画质的der untergang了🤔很不幸的是我早就被raymond chan等垃圾赶出去了🤔

现在我需要搞定命令行tsmuxer的事🤔

f u t a b r u h

我发现tsmuxer的命令行版压根就没有实现分片功能，所以我没法将其集成进脚本里🤔

看来，这玩意只能half arse了，也就是本地搞分片，然后上传到discord drive，然后在服务器端解压，然后执行discordtube脚本的后半部分🤔当然这部分我已经实现了，为了上传那个元首片段我已经魔改了discordtube脚本，现在我只需要往里面填个说明就好了🤔

der untergang（确信

https://cdn.discordapp.com/attachments/687774017008041994/835623135294390293/obs.m3u8

https://cdn.discordapp.com/attachments/687774017008041994/835631298843508766/goebbels.m3u8

die deutsche rikka

https://cdn.discordapp.com/attachments/687774017008041994/835649628585328690/diedeutscherikka.m3u8

不清楚为啥这个冻鳗bdmv码率比der untergang还要高，设置成5MB之后文件几乎全部超出了8MB，设置成4MB之后尽管没有一个超出的（大概在3.81MB到7.8MB之间），但出于某种原因分片时间短到完全没法缓冲🤔看来想愉快地在discord tube上面看冻鳗bdmv，还是需要将分片全部延长到50MB或者以上🤔所以最后还是ended up使用discord小号🤔

但我搞这玩意至少对付个10Mbps的毛片啥的是可以随便对付了（确信🤔

deepthonk

我又试了下p3m的bdrip，发现它处理bdrip无论是固定时间还是固定大小，分片大小都极其不固定，能从比如3MB一直到20MB，而我分的片只有5MB🤔这可真tm见了鬼了🤔

看来，bdrip还是用回ffmpeg比较好🤔

当然我还试了一些低码率视频，比如brcc的只有4Mbps的片子🤔这些片子表现得不错，分7MB片子最大没有超过8MB，比ffmpeg那边说实话好多了，ffmpeg的话恐怕得降两三次时间（指在分片大小/平均码率这个基础上）才能全部低于8MB🤔

bruhside

下了一个fripside的专辑，那个bdmv貌似里面是演唱会啥的🤔但有一个真的歌曲mv，所以我顺便用tsmuxer处理下🤔发现它只要分片大小足够大，结果还是比较稳定的，比如我填的是45MB（中间没有i，说明是1000进制），它最大也只有47MB，我觉得可以拿nitro慢慢传🤔但设置成6MB的话，超出8MB的分片就突然占了40%这么多🤔这些分片都得用nitro，传起来肯定比50MB分片还要慢🤔

我看了下fripside的wiki，发现这个乐队以前做过很多galgame的配乐，草🤔

https://cdn.discordapp.com/attachments/687774017008041994/835674905327697962/crossroads.m3u8

firefox基本上直接gg，mpv倒是可以流畅看，由于我使用了大分片，它下载速度直接上了12MB/s，换算下来这能支持100Mbps码率的视频（确信🤔我猜测hls这种东西它缓冲的时候会下载后面好几个分片的内容，所以当然是分片大小越大越好了，但除非webhook可以传大于8MB的附件，我可不太确定有什么办法能够快速上传大分片🤔

我以前在vps上测过，webhook多线程能够达到50MB/s，nitro单线程只有不到⑨MB/s，这慢了基本上80%🤔当然从本机上传的话反而不用担心这个，因为多线程我发现也只有6MB/s（那个测试配置文件只有⑨个线程，如果我用32个线程的正式配置文件的话估计能满带宽），这样算下来nitro单线程上传50MB文件也没慢多少🤔

50MB分片就这么爽的话，100MB分片那就爽的批爆了，甚至可以支持130Mbps的4k游戏录屏流畅观看，如果它能跑满我的200Mbps梯子限速的话🤔所以在discord tube上享受（大嘘）bdmv最好的办法是想办法搞个便宜的nitro小号，然后在上面建个聊天室，或者直接使用dm，因为聊天室可以删，但dm不行🤔当然另外一方面小号也可以被橄榄但聊天室不会（大嘘🤔

new crap

另外一方面，既然我现在可以上传bdmv了（尽管目前我上传的只是些部分分片，比如元首大喊大叫片段啥的，还有戈培尔著名的大屁股裂了nms），我也需要改善下我的脚本的并行性了，花十几分钟替换两三千个分片是我不能容忍的🤔至少有两点，一点是并行启动多个ffprobe进行视频分片的时长分析，通常来说生成m3u8是本地的事，因为本地的cpu资源比vps那边多多了🤔另外一点是并行替换m3u8里的视频文件成discord链接，这部分其实和我写的频道备份脚本比较像了，先将m3u8里面一个分片占的两行合并成一行，然后直接按行分割就可以了，再以每个线程为单位筛选掉需要nitro的文件，这部分文件到时候合并到下一个多线程任务（也就是正式上传）的线程0去🤔这样理论上来说，上传完成后除了线程0之外的任何线程生成的discord链接文件只用来替换它对应的那部分m3u8，这样时间复杂度马上降了n的平方（确信🤔最后再用进程0生成的discord链接进行全文替换，再重建m3u8即可🤔那么问题来了，和discord备份频道那边不同，现在可能有10%到20%的文件是用nitro线程上传的，我需要在nitro这边也要只替换一部分文件🤔一个可能的途径是在nitro线程生成的链接文件里做特殊的记录，标明它是哪个普通线程分过来的，到时候它只替换某个线程的文件🤔不对，我记得这玩意的替换脚本先遍历原文件（对应线程的片段），再遍历（对应线程的）链接文件，这样的话无论nitro线程的链接文件来自哪个普通线程，都可以在比如每个线程在自己的链接文件里找不到后被遍历到🤔这样，至少我不用改绝大多数代码了（确信🤔

jajaja

在我折腾了1145.14秒后终于搞完了，测试发现nitro线程的视频没有替换，甚至便乘了完全的空值，检查代码发现该打两个竖线的地方打了一个，所以它以为是管道符号🤔那两个竖线其实是bash版本的三目运算符，用[ statement ] && ja ||nein替换if/else/then一长串🤔

改正之后它可以正常运行了，生成m3u8和替换所用时间基本可以忽略不计🤔现在我也许可以拿它处理bdmv这么大的视频了🤔我还发现目前的分割模式下，最差的情况是最后一个线程分配的分片只有一两个，换句话说绝大多数时间少了一个线程🤔但这可比频道备份脚本好多了，那个脚本里鬼知道一段消息里面有几个需要替换的附件🤔而且这玩意据我备份114514次（大嘘）discord频道的经验，它不会因为消息数量非常大而平均分布的🤔

另外这种分割模式还有一个彩蛋，哪怕我决定将每个分片都搞到50MB左右，全部用nitro线程上传了，它在替换阶段仍然可以并行🤔