摘要
Bilibili parser 在处理部分 hvc1 编码的视频流时，可能因 bilibili-api-python 17.4.1 无法识别该编码标识，导致 VideoDownloadURLDataDetecter.detect_best_streams 中访问 video_codecs.value 时抛出 AttributeError: 'NoneType' object has no attribute 'value'，解析流程中断。
本 issue 用于跟踪根因确认、候选方案评估和最优修复选择。目标不是直接合入某个上游 PR，而是在本 fork 中先分析并确定最稳妥、可维护、可回归验证的修复方案。
背景
QQ 群中分享的 Bilibili 小程序 / JSON 卡片经由 parser 提取 URL 后，会进入 Bilibili parser 处理流程。在视频下载解析阶段，调用链大致为：
download_video
-> extract_download_urls
-> VideoDownloadURLDataDetecter.detect_best_streams
-> video_stream_cmp
当 B 站返回的视频流使用 hvc1.* HEVC 编码标识时，bilibili-api-python 17.4.1 仅识别 hev、avc、av01 等编码标签，可能导致对应流的 video_codecs 字段被设为 None，最终触发属性访问异常。
现象
- Bilibili 小程序 / JSON 卡片可被识别，URL 可被提取。
- Bilibili parser 可进入视频解析流程。
- 在下载视频流选择阶段抛出异常：
AttributeError: 'NoneType' object has no attribute 'value'
- 异常发生在
video_stream_cmp 比较视频流时访问 video_codecs.value。
- 当前异常不是插件定义的
DownloadException，因此可能穿透发送流程，导致解析结果无法降级发送。
已知事实
- 异常与
bilibili-api-python 17.4.1 的视频流编码识别有关。
hvc1 是 HEVC / H.265 的 MP4 容器编码标识，与 hev 同属 HEVC 编码族但字符串不同。bilibili-api-python 当前识别逻辑无法将 hvc1.* 匹配到 VideoCodecs.HEV。- 上游
astrbot_plugin_parser 已有相关 issue / PR，但本 issue 不预设采纳任一方案。
待分析方案
方案 A：标准化 hvc1.* 编码标识
在 download_url_data 传入 VideoDownloadURLDataDetecter 前，将 B 站返回的 hvc1.* 标识标准化为当前 bilibili-api-python 可识别的 HEVC 标识。
示例方向：
if isinstance(codecs, str) and codecs.startswith("hvc1"):
video_data["codecs"] = f"hev,{codecs}"优点：
- 改动小，贴近当前已知根因。
- 保留
detect_best_streams 的原有选择逻辑。
风险：
- 只覆盖已知的
hvc1 情况。
- 仍需考虑未来出现其他未知编码时的防御性处理。
方案 B：插件侧 fallback 选流
在检测到候选流存在 video_codecs=None 时，跳过 detect_best_streams，由插件自定义选择视频 / 音频流。
优点：
- 覆盖面可能更广。
- 不依赖
bilibili-api-python 的内部排序实现。
风险：
- 改动较重，需要维护自定义排序和选择逻辑。
- 容易偏离上游库行为，增加长期维护成本。
方案 C：异常降级与错误类型收敛
将 extract_download_urls / detect_best_streams 中来自上游库的非预期异常转换为插件侧 DownloadException，确保发送流程可以降级，例如发送文本摘要、链接或下载失败提示，而不是中断整个 handler。
优点：
- 提升稳定性。
- 即使未来出现新的上游库异常，也不至于导致整个解析流程崩溃。
风险：
- 只能改善失败表现，不能单独修复
hvc1 的视频下载。
方案 D：配置兼容修复
确认并修复 video_codecs 与 video_codec_list 的配置字段兼容问题。
优点：
- 降低已有配置失效风险。
- 与本问题相关但可独立验证。
风险：
- 不是
video_codecs=None 崩溃的直接根因。
方案 E：升级或推动修复 bilibili-api-python
向 bilibili-api-python 上游提交 hvc1 支持，或等待其发布新版本后升级依赖。
优点：
风险：
非目标
- 不直接合入任一上游 PR，除非经过本 issue 分析并确认是最优方案或部分可复用。
- 不处理其他视频平台的解析问题。
- 不处理 Bilibili 登录态、Cookie、权限或风控问题，除非验证中证明与本问题直接相关。
- 不把 Linux / Docker 下的 file URI 发送问题混入同一个修复，除非后续验证表明它阻塞本 issue 的验收。
- 不在 issue 中记录私有部署路径、真实群号、用户 ID、token、cookie 或完整私有日志。
验收标准
参考资料
工作分支
fix/bilibili-hvc1-codec-analysis
摘要
Bilibili parser 在处理部分
hvc1编码的视频流时，可能因bilibili-api-python17.4.1 无法识别该编码标识，导致VideoDownloadURLDataDetecter.detect_best_streams中访问video_codecs.value时抛出AttributeError: 'NoneType' object has no attribute 'value'，解析流程中断。本 issue 用于跟踪根因确认、候选方案评估和最优修复选择。目标不是直接合入某个上游 PR，而是在本 fork 中先分析并确定最稳妥、可维护、可回归验证的修复方案。
背景
QQ 群中分享的 Bilibili 小程序 / JSON 卡片经由 parser 提取 URL 后，会进入 Bilibili parser 处理流程。在视频下载解析阶段，调用链大致为：
当 B 站返回的视频流使用
hvc1.*HEVC 编码标识时，bilibili-api-python17.4.1 仅识别hev、avc、av01等编码标签，可能导致对应流的video_codecs字段被设为None，最终触发属性访问异常。现象
video_stream_cmp比较视频流时访问video_codecs.value。DownloadException，因此可能穿透发送流程，导致解析结果无法降级发送。已知事实
bilibili-api-python17.4.1 的视频流编码识别有关。hvc1是 HEVC / H.265 的 MP4 容器编码标识，与hev同属 HEVC 编码族但字符串不同。bilibili-api-python当前识别逻辑无法将hvc1.*匹配到VideoCodecs.HEV。astrbot_plugin_parser已有相关 issue / PR，但本 issue 不预设采纳任一方案。待分析方案
方案 A：标准化
hvc1.*编码标识在
download_url_data传入VideoDownloadURLDataDetecter前，将 B 站返回的hvc1.*标识标准化为当前bilibili-api-python可识别的 HEVC 标识。示例方向：
优点：
detect_best_streams的原有选择逻辑。风险：
hvc1情况。方案 B：插件侧 fallback 选流
在检测到候选流存在
video_codecs=None时，跳过detect_best_streams，由插件自定义选择视频 / 音频流。优点：
bilibili-api-python的内部排序实现。风险：
方案 C：异常降级与错误类型收敛
将
extract_download_urls/detect_best_streams中来自上游库的非预期异常转换为插件侧DownloadException，确保发送流程可以降级，例如发送文本摘要、链接或下载失败提示，而不是中断整个 handler。优点：
风险：
hvc1的视频下载。方案 D：配置兼容修复
确认并修复
video_codecs与video_codec_list的配置字段兼容问题。优点：
风险：
video_codecs=None崩溃的直接根因。方案 E：升级或推动修复
bilibili-api-python向
bilibili-api-python上游提交hvc1支持，或等待其发布新版本后升级依赖。优点：
风险：
非目标
验收标准
fix/bilibili-hvc1-codec-analysis上完成根因复核与方案评估。hvc1.*编码视频，避免video_codecs=None导致AttributeError。avc、hev、av01等已有编码路径无回归。DownloadException或等价的可控失败路径。video_codecs与video_codec_list配置。参考资料
工作分支