fmp4支持捕获265区域真原画链接

[RageMeoww]

确认到265推流会出现在hevc区域，并且b站的判定准确率越来越高了
当真原画出现在hevc区域时，仅凭现在只过滤avc的逻辑是无法录制的
所以我制作了这个pr
分为两个版本，这个是v1.0版本，可以在fmp4录制模式时捕获hevc推流
默认依旧以avc推流优先，仅当没有avc原画但却有hevc原画时才会捕获hevc链接

v2.0版本增加了一个功能，在flv录制时，如果没有avc_flv真原画，却存在hevc_flv_原画时才转向fmp4推流
但我实际调试时对这个功能并不满意，不仅因为转向时显示画质是4K这种错误，因为265_fmp4还不够稳定
还是hevc_flv更稳定一些，而且，转向fmp4后却依旧沿用flv的分段逻辑让我很火大
fmp4的分段由于缺失关键帧会导致头部没有画面，1.5的标准模式就没有这个问题，但偏偏不能用

主要的原因是有时候我想录flv二压而不是fmp4
但是，当我调试v2.4版本限制没有avc_flv真原画，却存在hevc_fmp4原画时才转向却失败了
(这里的失败不是指运行会失败，而是指开播时转向更容易失败，但v2.3同样可能失败，因为265推流也会出现在avc区域
除非制作一个v3.0版本，检测到codec12时终止报错，之后根据设置来决定要不要转向fmp4还是等待二压流，但是那太麻烦所以我放弃了）
因为等待fmp4流产生时需要一段时间，根据日志，这个时间大概是10秒钟，
虽然blrec的flv是不会捕获hevc区域的链接的,但是hevc的链接却依然有概率出现在avc区域
而只要一次flv的format开始分析到hevc_flv就会开始报错，就无法转向了(虽然也不符合转向条件)
flv检测到codec12就会开始超长时间的报错，可能长达1个小时，然后才能继续录制
所以虽然我不满意但依然推荐v2.3的自动转向版本
(1.23确认v2.4版本已经失败了，无法转向，v2.3和v2.4同时实验时v2.3成功转向，v2.4无法转向。并且，至今为止v2.4的每一次转向都失败了)

【如果要合并v2.0，希望增加一个选项来开启/关闭】
v2.0new.zip

[RageMeoww]

如果不需要hevc优先的选项的话，就可以去掉获取hevcqn的部分，然后判定改成

if 10000 not in avc_current_qn:
    codecs = hevc_codecs

嗯……不行，那样原画以外的画质就优先hevc了

[RageMeoww]

话说blrec什么时候也支持提供一个js区域供diy，改代码改好几天给我改吐了

v2.0版本在压缩包里，还有Debug版本，仅当转向时会打印请求信息在日志里
如果平时直播间都是二压流不符合转向条件，还可以手动修改判定条件使其直接转向来调试打印效果
if 10000 in hevc_current_qn:条件我已经用＃标记了，调试时去掉然后标记上面一条即可

除非是只有fmp4流的直播间，否则一定是先出现flv流真原画，然后才出现fmp4流真原画，但之后谁先出现二压就不确定了
想要打印265推流时最初只有hevc_flv和hevc_ts的推流状态就用旧版的Debug吧，在压缩包里面
旧版本开始录制时间更早，筛选条件更宽松，只要没有avc_flv原画却有hevc_flv原画就转向并打印请求信息

我之前还想制作v3.0版本，就是flv检测到codec12时制止报错，然后进行转向，这需要flv里的format.py与core里的stream_recorder.py
进行联动
但怎么制止这个鬼报错我也没有头绪，更不要说联动了，所以交给其他人吧，反正我也没什么知识

想要知道报错什么样的就随便找个有二压流的直播间，修改live.py把stream_codec: StreamCodec = 'avc',
改成stream_codec: StreamCodec = 'hevc',就能观察到这惊人的报错了

[RageMeoww]

v2.4失败原因大概清楚了，只有开始录制时才会判定一次，之后不会判定了，而fmp4开播时是没有的，所以判定会无效，总之用v2.3的转向逻辑就行了