恢复Bilibili旧版页面,为了那些念旧的人。
不是浏览器问题,是B站部分视频服务器(CDN)抽风,而且偏偏是提供的首选CDN抽风,播放器会尝试备用CDN,但脚本默认只提供首选CDN,所以提供了不能用的下载地址。浏览器尝试去访问该地址,服务器返回了个403重定向,表现出来后缀就是网页。
一般人说提供给客户端的CDN是B站认为这是对用户网络体验最流畅的CDN,比如用户是移动宽带就提供移动节点的CDN,但抽风这种事怎么说呢……只能说官方早有备案,所以提供了备选CDN地址。
只能说等抽风完了就恢复正常?或者脚本把备选地址也列出来?那样的话下载面板会不会太长了(翻倍)?
如果是CDN的问题,为什么同一个视频,用火狐和Chrome的右键菜单链接另存为
下载都没有问题呢
抽风就是这样,时灵时不灵。
我用的就是chrome,IDM也试了,偶尔都报错,刷新一下可能又正常了。
也切换到win10用新版edge试了下,也是时灵时不灵,难道你那边是刷新都没用吗?
刚刚试了还不行,现在又可以下载了,看来确实是CDN抽风,和浏览器无关
附上最新版edge截图 30125对应最高画质HDR的h.265格式视频音轨
其实下载的话选mp4最好,如果不是追求更高画质的话,试了多次都没出现抽风的情况。
而且不同于dash、flv,mp4格式是没有CROS和referer限制的,这意味者你甚至可以选择复制链接到任意下载工具或者能播放在线视频的播放器(虽然脚本里没有明确写出来)
而且不同于dash、flv,mp4格式是没有CROS和referer限制的,这意味者你甚至可以选择复制链接到任意下载工具或者能播放在线视频的播放器(虽然脚本里没有明确写出来)
看到这我有个问题,其他的下载器或脚本都是分开下载音视频流然后在本地用ffmpeg合并的,不知道这个脚本是怎么获取到合并流的,是b站提供的音视频合并流吗?而且下载合并流分析发现里面的avc流不是dash里的任何一支(某些视频)
不知道这个脚本是怎么获取到合并流的,是b站提供的音视频合并流吗?
跟其他脚本一样,不过DASH可能是直接捕获播放器正在播放的没有去另外获取。
而且下载合并流分析发现里面的avc流不是dash里的任何一支(某些视频)
不会吧,avc其实浏览器默认播放的DASH的视频流部分,因为浏览器不支持hev,包括新版的edge。下载而言avc和hev是等价的,只是编码格式不同,B站同时提供二者,下载任选其一即可。avc或者hev搭配aac音频轨道才是完整视频。所以也要像其他软件那样合并。
是b站提供的音视频合并流吗
而mp4以及不分段的flv约等于avc/hev+aac,这两者是B站提供的音视频合流(也就是正常视频),flv是flash时代的遗产,mp4则是支持某些特殊设备的要求。
不知道这个脚本是怎么获取到合并流的,是b站提供的音视频合并流吗?
跟其他脚本一样,不过DASH可能是直接捕获播放器正在播放的没有去另外获取。
没明白,我看https://github.com/SocialSisterYi/bilibili-API-collect/blob/master/video/videostream_url.md里面说的,没有办法获取1080p的合并流(也解释了为什么其他b站视频下载器或脚本不支持直接下载合并的mp4),是这个脚本自己进行合并吗?看了url确实是b站返回的视频...
而且下载合并流分析发现里面的avc流不是dash里的任何一支(某些视频)
不会吧,avc其实浏览器默认播放的DASH的视频流部分,因为浏览器不支持hev,包括新版的edge。下载而言avc和hev是等价的,只是编码格式不同,B站同时提供二者,下载任选其一即可。avc或者hev搭配aac音频轨道才是完整视频。所以也要像其他软件那样合并。
比如https://www.bilibili.com/video/av246046917的mp4下载
得到的avc不是来自dash的某一支。
比如https://www.bilibili.com/video/av246046917的mp4下载得到的avc不是来自dash的某一支
那说明B站提供的mp4不是临时由DASH合并而来的,B站本身就提供mp4格式的源,只不过开放给某些特殊设备,那些设备肯定不支持DASH这种新格式,也未必兼容flv,只能提供mp4这种普适型的视频源。
没有办法获取1080p的合并流
是有办法获取的,不是脚本合并的,JavaScript作为前端直接合并视频流是性能开销太大,应该没有人会想去那么做。
使用新版edge的下载问题
如图,右键使用IDM下载正常,但如果点击
将链接另存为
则会失败,原因在于edge尝试保存链接的html网页而不是视频。火狐不会遇到这个问题,因为火狐的右键选项是
从链接另存文件为
。(大概这是edge的问题,不是脚本能解决的?)