关于b站的广告

一开始我还不知道逼开始贴片了

看番一向都是bdown下载后bililocal+svp看,没有受到任何影响

就算是网页,也是替换修改播放器,基本没用过原版

晚上的时候看到有C的微博才知道今天的re0上了贴片,这才去看了看情况

http://api.bilibili.com/x/ad/video?aid=4738388

{"code":0,"data":[{"name":"沪江4738388","aid":4738388,"cid":4709603,"url":"http://class.hujiang.com/?ch_campaign=cls10988\u0026ch_source=opp_bz_0_spag","skipable":0,"strategy":0}]}

奇怪的加载逻辑,嵌套miniplaylite.swf,用一种类似站外播放的方式播放广告

据说可以用flashvar设置不显示广告

pre_ad=0

出于部分考虑吧,bp原始播放器还是不整这个参数了

svp压制尝试+升级x64 ffmpeg

昨天群里秋日问svp插帧压制的问题,然后看到song神说的方法超简单——【找一份svp生成的avs,改掉source就好】

真简单_(:3」∠)_

 

先去重编译ff,带上

--enable-avisynth

尝试svp压制,结果出来的视频画面严重减慢,原因不明

一度以为电脑太烂了而已

 

后来发现……关闭svp即可解决

然后推测,关键点在于【DirectShowSource】

svp的正常播放插帧就是通过DirectShow接口的,所以估计是avs调用dll的同时,svp管理器又加了一次帧,于是输出视频就错乱了

 

成品:【IA】TSUBASA New Days【60FPS】 @MU秋日

 

后来发现,插帧的时候ffmpeg频频崩溃,估计是x86内存占用过大溢出了吧

找了份msys2+mingw64准备重新编译ff

 

msys2啥都好,就是一个,config.guess guess不到系统

网上找到一个超好用的config.guess

#! /bin/sh
UNAME_MACHINE=$(uname -m 2>/dev/null) || UNAME_MACHINE=unknown
echo ${UNAME_MACHINE}-pc-mingw32

直接放在某个地方,覆盖所有要configure的地方覆盖掉文件,跳过一串串的【fancy detection(高逼格的检测)】直接输出为x86_64架构的mingw32系统

(Source:MSys2 and ./configure: Troubleshooting Shared Libs – { Here Be Braces }

不过ff的configure不是正常的autoconf出来的脚本,我手动把里面的检测系统的 mingw32*) 改成 mingw64*) 了

(编译最后strip的时候莫名报错,手动strip -s ffmpeg.exe ffprobe.exe也没有问题,不知道什么鬼)

最终确认是不是x64居然还是靠的7zip,7z大法好!

QQ图片20160519124925

 

aid搜索告一段落

一直把ac双库放在别人那里

一夜消失

用一些特殊方法搞到的比较高级的服务器,被管理员发现了,就没了

加上扫描的时间,差不多用了两个月

当初放的时候就知道会有这一天,只不过一直无事感觉像是永远没有问题一样

考虑看看腾讯,看起来还算比较便宜

毕竟a+c总共3G+大小的数据库,可不是普通的地方能撑得住的

 

5/13 下午

试用腾讯“按量收费”,抛弃

辣鸡玩意儿,实际上是按照开通时长计费的,即“开通时间=使用时间”,还以为会是按照CPU时间计费

 

5/14凌晨

暂时利用阿里云9.9学生机挂上,腾讯学生认证略慢,之后准备换到那边的1元机上。极限压缩成本中