首页 / 资讯中心 / 文章详情

BiliTools 下载资源选择指南:参数界面、取样回退机制与分辨率/编码/比特率全参数解析

BiliTools 下载资源选择指南:参数界面、取样回退机制与分辨率/编码/比特率全参数解析 ★ FEATURED ARTICLE
桌面应用音视频【免费下载链接】BiliTools本项目已停止维护。项目地址https://gitcode.com/GitHub_Trending/bilit/BiliTools点击查看免费下载本文以 BiliTools 的「选择资源」功能为线索完整讲解使用「常规下载」模式时如何挑选资源与参数深入剖析其基于“取样”的解析设计、多视频参数不一致时的回退逻辑并逐一解读分辨率、编码格式、比特率、流媒体格式、字幕、AI 总结、NFO 与弹幕等全部选项的含义、取值表与底层源码实现。读完本文你将能熟练配置 BiliTools 的下载参数理解其为何采用“按首个选中视频取样”的降风控策略并能结合源码 src/services/media 中的真实处理逻辑预判各种边界情况下的下载行为。参数界面从哪里进入、如何完成一次选择使用“常规下载”模式时应用会弹出参数选择界面供用户选择需要的资源及其参数。操作流程如下点击所需资源的按钮如“音视频”“视频”“音频”“字幕”“AI总结”“图文/专栏/动态”“NFO 元数据”“弹幕”“图像”等。选择对应的参数如分辨率、编码格式、比特率、语言、日期等。滚动到界面底部点击下一步按钮将任务加入等待队列。注意需至少选择一项资源否则会在下一步时提示错误。关于下载页等待队列、任务处理的完整说明请参见 下载与处理关于下载完成后的存储路径与命名规则可参见 设置页。为什么只“取样”而非逐个请求API 限制与风控考量由于哔哩哔哩 API 的限制请求视频列表时只会返回AID、CID等基本信息不会包含分辨率等参数。因此与其他“逐个视频发起参数请求”的下载工具不同BiliTools 在选择了多个项目时只会按选中的第一个项目进行“取样”请求其参数并展示给用户。这样设计的目的很明确避免在短时间内对所有视频发起大量请求从而提升速度并降低风控风险。从源码结构看这一“取样”链路对应 src/services/media/data.ts 中的getMediaInfo先通过/x/web-interface/view等接口取列表信息仅拿到 aid/bvid/cid/duration 等基础字段以及getPlayUrl携带qn、fnval、fourk等参数向/x/player/wbi/playurl请求真实的分辨率/编码/比特率信息——后者正是“取样”时才会被触发的请求。常见情况多个视频参数不一致时如何处理当多个视频的参数不一致时例如合集内前几集有 1080P、后面的集数只有 720P应用的处理逻辑分为两类分辨率 / 音质 / 编码格式等差异若样本视频有 1080P而后续视频没有该分辨率应用会进行比对如果实际返回数据中不含该分辨率则自动使用该视频的最高分辨率例如 720P。若样本视频有 1080P而后续视频有更高分辨率例如 4K默认情况下依然会按照选中的分辨率1080P下载不会“向上”升级。提示如果希望逐集调整可在任务等待界面手动点击该视频的分辨率此时应用会请求该视频的真实参数从而可以选择该视频实际可用的参数。从源码看这一回退逻辑由 src/services/utils.ts 中的getDefaultQuality实现当配置的分辨率res不在目标视频实际返回的可用列表中时会取ids.sort((a, b) b - a)[0]即可用列表中的最大值作为回退结果abr比特率与enc编码同样遵循该函数。其他资源差异字幕、弹幕、AI 总结等同理若样本视频有字幕而接下来的视频没有字幕应用会在请求时检查可用性对于缺失的资源会自动跳过该任务并跳出提示而不是强行下载失败。以字幕为例源码 src/services/media/extras.ts 中的getSubtitle会先通过getPlayerInfo获取subtitle.subtitles列表再按options.name用户选择的语言查找对应的subtitle_url若找不到!_url直接返回-1作为“缺失”信号由上层跳过该任务并提示。音视频 / 视频 / 音频三者的区别与合并逻辑此处展示的选项仅适用于有视频流 / 音频流的资源。一般情况下音视频同时具有音频流与视频流的视频下载后是一个完整的音视频文件视频无声视频仅有视频流音频无画音频仅有音频流。少数情况下例如MP4流媒体格式视频本身也带有内嵌的音频流。下载视频/音频时参数将遵循下文提到的分辨率、编码格式、比特率与流媒体格式。对于“音视频”类型的任务应用会在处理时自动调用ffmpeg合并/混流视频流与音频流为一个独立的视频文件详见 下载与处理 及设置页中的转换策略见 docs/guide/settings.md。杂项字幕、AI 总结与图文/专栏/动态此部分包括字幕、AI 总结与图文/专栏/动态的相关选项。字幕右侧会提供下拉栏选择对应的语言。并非所有视频都有选中语言的字幕缺失时会自动跳过对应上文getSubtitle返回-1的逻辑。处理字幕时会遵循name.lang.srt的命名格式以便在同时下载视频时播放器能够自动识别并挂载字幕例如字幕 - 标题.zh-CN.srt见 docs/guide/settings.md 中的命名示例。AI 总结AI 总结的实际数据来自哔哩哔哩 AI 小助手实际为Shanghai-Bilibili index-20231207模型以 Markdown 格式保存模板如下# 标题 - BV号 总结文本 ## 分段标题 - [00:00](https://www.bilibili.com/video/${BV号}?t${分段时间}) - 分段标题 - [00:00](https://www.bilibili.com/video/${BV号}?t${分段时间})实际处理逻辑见 src/services/media/extras.ts 中的getAISummary函数它请求/x/web-interface/view/conclusion/get接口读取data.model_result当result_type 2时遍历outline中的每个分段及其part_outline将分段标题转换为带时间戳跳转链接https://www.bilibili.com/video/${bvid}?t${timestamp}的 Markdown时间戳由 src/services/utils.ts 中的duration函数格式化为HH:MM:SS。相关数据结构可参见 src/types/media/extras.d.ts 中的AISummaryInfo。图文 / 专栏 / 动态图文/专栏/动态的内容同样以 Markdown 格式保存模板如下# 标题 作者名称 喜欢: xxx | 投币: xxx | ⭐ 收藏: xxx | 转发: xxx | 评论: xxx 若干可能的头图 正文转换时遵循以下规则对于包含不可见字符诸如\u00A0的文本自动转换为兼容的 HTML 转义字符例如nbsp;。一般情况下使用 Markdown 原生语法诸如**、##但在包含 HTML 转义字符的情况下会改用 HTML 标签诸如strong/strong。对font-size: 24的文本使用##二级标题对font-size: 17的文本使用默认正文。实际处理逻辑见 src/services/media/opus.ts 中的getOpusMarkdown与 src/services/media/opus.ts 中的handleOpusNode/handleOpusParas应用先抓取页面window.__INITIAL_STATE__中的模块化数据标题、作者、统计、正文段落再按段落类型文本、图片、引用、列表、链接卡片等逐段转换为 Markdown正文段落在源码中由para_type16 区分图片段落会输出p aligncenterimg ... //p文本节点则依据font_size 24决定是否提升为##标题.replaceAll(\u00A0, nbsp;)则对应不可见字符的转义规则。数据结构可参见 src/types/media/opus.d.ts。NFO 元数据合集刮削与单集刮削NFO 支持合集/剧集刮削与单集刮削两种模式合集/剧集刮削刮削整个番剧/合集/视频的信息单集刮削刮削番剧单集/合集单集/视频分 P 的信息视频标题与分 P 标题会按照选项单独处理。NFO 数据结构遵循KODI 规范Emby 可正常识别。对于合集/剧集刮削应用会一并下载合集/番剧/视频封面命名为poster.jpg放置在 NFO 同级目录。实际实现见 src/services/media/extras.ts 中的getNfo函数它根据资源类型视频 →movie、番剧/课程 →episodedetails、合集 →album构造对应的 XML 根节点写入标题、简介plot、封面thumb合集模式下值为poster.jpg、时长、首播日期premiered按Asia/Shanghai时区格式化、导演director、标签genre/tag、演员actor与职员等字段并将aid/bvid/cid/epid/ssid等 ID 写入bili:前缀的自定义标签最终以?xml version1.0 encodingUTF-8 standaloneyes?头输出。封面数据在 src/services/media/data.ts 的getMediaInfo中通过getPublicImages见 src/services/utils.ts从 API 回复中收集。弹幕实时弹幕与历史弹幕弹幕支持实时弹幕与历史弹幕实时弹幕拉取视频全量分段弹幕历史弹幕右侧提供控件以选择对应日期若日期有误或当前无弹幕哔哩哔哩 API 返回的数据会自动回退至当天的弹幕。自v1.4.0起弹幕请求全面迁移至 ProtoBuf 协议接口应用会自动处理为 XML 格式以供存档或其他弹幕转换工具使用。实际实现见 src/services/media/dm.ts 中的DanmakuEventToXML函数它先用内置的 protobuf 解码器源码 src/services/media/dm.ts 中基于bufbuild/protobuf/wire生成的DanmukuEvent/DanmakuElem结构解码弹幕流再将每条弹幕的progress毫秒转秒、mode、fontsize、color、ctime、pool、midHash、idStr拼入 XMLd p...标签。分段拉取逻辑见 src/services/media/extras.ts 中的getDanmaku实时弹幕按每 6 分钟duration / 360一段请求/x/v2/dm/wbi/web/seg.so历史弹幕请求/x/v2/dm/web/history/seg.so分段间会插入 100500ms 随机延迟以降低风控概率。应用目前内置 DanmakuFactory Sidecar可将 XML 弹幕转换为 ASS 字幕相关配置如分辨率、字体、滚动速度、屏蔽规则与自定义方式详见 设置页 - 策略 - 转换策略。图像封面与海报的刮削映射此部分包括封面、海报等图像。在请求资源时应用会尽力刮削 API 回复中的一切图像资源并映射为以下文本thumb: { name: 图像, pic: 封面, cover: 封面, square_cover: 方形封面, ugc_season_cover: 合集封面, season_cover: 本季封面, season_horizontal_cover_1610: 本季海报 (16:10), season_horizontal_cover_169: 本季海报 (16:9), brief: 预览-{num} }其他图像也支持刮削不过就没有对应的描述文本了。从源码看这一行为由 src/services/utils.ts 中的getPublicImages实现它遍历 API 返回对象的每个字段凡是以.jpg/.png/.gif结尾的字符串 URL 都会被收集为图像资源可选的prefix参数如ugc_season、season用于为 ID 添加前缀以区分来源参见 src/services/media/data.ts 中对视频、番剧、课程、音频等类型的调用。分辨率支持的取值与回退规则此处展示的选项仅适用于有视频流的资源。提示当选择的分辨率不可用时应用会自动回退至该视频可用的最高分辨率即上文getDefaultQuality的ids.sort((a, b) b - a)[0]逻辑。目前支持的分辨率如下数值为哔哩哔哩 API 的qn取值res: { 6: 240P 极速, 16: 360P 流畅, 32: 480P 标清, 64: 720P 准高清, 80: 1080P 高清, 112: 1080P 高码率, 116: 1080P 60帧, 120: 4K 超高清, 125: HDR 真彩, 126: 杜比视界, 127: 8K 超高清 }注意部分高分辨率如 8K、HDR、杜比视界通常需要登录账号且依赖播放权限实际可用性由 API 返回为准getPlayUrl在未登录时默认qn: 64720P登录后请求qn: 1278K以获取全部可用选项见 src/services/media/data.ts。编码格式AVC / HEVC / AV1此处展示的选项仅适用于有视频流的资源。提示当某一视频无对应编码格式时例如 8K 视频不提供 H.264 格式应用会自动遍历可用编码格式并选择最兼容的格式。目前支持的编码格式如下enc: { 7: AVC (H.264), 12: HEVC (H.265), 13: AV1 }同一分辨率下不同编码的码率、体积与播放器兼容性不同AVC 兼容性最好HEVC 在同等画质下体积更小AV1 压缩率更高但对解码器要求也更高。实际可选编码取决于视频源的 API 返回dash.video数组中各流自带codecid。比特率无损、杜比与容器选择此处展示的选项仅适用于有音频流的资源。目前支持的比特率如下数值为音频abr标识abr: { 30216: 64K, 30228: 128K, 30232: 132K, 30250: 杜比全景声, 30251: Hi-Res 无损, 30252: 无损 FLAC, 30280: 192K, 30380: 320K }针对特殊音频格式处理时有如下容器规则Hi-Res 无损 与 无损 FLAC若只下载音频处理时自动调用ffmpeg进行FLAC 标准化处理若同时下载音视频处理时自动调用ffmpeg封装为 Matroska Video 容器.mkv因为 MPEG-4 容器不支持储存 FLAC 音频流。杜比全景声若只下载音频处理时自动调用ffmpeg进行EAC3 标准化处理若同时下载音视频处理时**保留并使用 MPEG-4 容器.mp4**存储。同时可配置 设置 - 策略 - 转换策略 - 将音频转换为 MP3 格式 来强制转换音频为 MP3 格式该选项只影响音频任务音视频不受影响文档亦提醒高音质/高比特率音频不建议启用有损音质。流媒体格式DASH / MP4 / FLV此处展示的选项仅适用于有视频流/音频流的资源。目前支持的格式如下fmt: { dash: DASH 格式, mp4: MP4 格式, flv: FLV 格式 }警告请勿随意修改流媒体格式一般情况下保持 DASH 即可。除非你清楚自己正在做什么否则请勿修改至 MP4。三种格式的背景差异可参见 关于 DASH / FLV / MP4要点如下DASH哔哩哔哩自 2018 年起采用的方案音视频被切片并单独下发只能拿到“无声视频”与“无画音频”需调用 FFmpeg 混流成“音视频”任务分发质量最好、下载速度最快。MP4直接下发自带音频的 MP4 媒体但下载速度较慢、质量不如 DASH目前基本仅用于试看资源付费番剧/影视/课程画质与音质大多欠佳。FLV早年分段格式基本已完全退役保留选项仅用于存档部分资源可能仍可下载。对应到源码 src/services/media/data.ts 的getPlayUrl选择 FLV 时设置fnval 0MP4 时设置fnval 1DASH 时登录态设置fnval 4048未登录为16fnver: 0、fourk: 1为固定参数。返回值中dash分支会把视频、音频、杜比dolby与 FLAC 音频流一并纳入候选供下载队列按所选参数筛选。小结一次下载参数选择的完整决策链综合全文BiliTools 的“选择资源”环节遵循一条清晰的决策链取样以选中列表的第一个视频为样本请求其真实可用参数分辨率/编码/比特率/格式供用户在参数界面选择src/services/media/data.ts 的getPlayUrl选择用户至少勾选一项资源并为各资源指定参数含语言、日期等附加选项回退排队下载时对每个视频按其实际返回的可用列表进行比对——主参数分辨率/编码/比特率缺失时取可用最大值src/services/utils.ts 的getDefaultQuality附属资源字幕/AI 总结/弹幕等缺失时自动跳过并提示src/services/media/extras.ts后处理弹幕经 ProtoBuf → XMLsrc/services/media/dm.ts 的DanmakuEventToXML音视频经 FFmpeg 混流NFO 按 KODI 规范生成图文内容按模板转 Markdownsrc/services/media/opus.ts 的getOpusMarkdown最后按命名格式落盘至输出目录。理解这套“取样 回退”机制是正确使用 BiliTools 批量下载合集、番剧与多分 P 视频的关键也是避免触发哔哩哔哩风控的实践前提。赞分享桌面应用音视频【免费下载链接】BiliTools本项目已停止维护。项目地址https://gitcode.com/GitHub_Trending/bilit/BiliTools点击查看免费下载相关推荐Apollo流媒体质量调优终极指南编码参数、比特率和分辨率的科学配置Apollo流媒体质量调优终极指南编码参数、比特率和分辨率的科学配置 想要获得完美的Apollo流媒体体验本完整指南将教你如何科学配置编码参数、比特率和分辨音视频游戏开发RecordRTC录制质量终极指南如何设置最佳比特率与采样率参数RecordRTC录制质量终极指南如何设置最佳比特率与采样率参数 RecordRTC是一款强大的WebRTC JavaScript库专门用于音频、视频以及屏音视频WebRTCH2O 3 的 col_sample_rate 列采样率参数完全指南GBM 与 XGBoost 的列采样机制、调参策略与源码剖析H2O 3 的 col_sample_rate 列采样率参数完全指南GBM 与 XGBoost 的列采样机制、调参策略与源码剖析 col_sample_rat机器学习深度学习AutoML大数据后端创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
阅读完成 · 觉得有帮助?
咨询建站