一开始我还不知道逼开始贴片了
看番一向都是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插帧压制的问题，然后看到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大法好！
一直把ac双库放在别人那里
一夜消失
用一些特殊方法搞到的比较高级的服务器，被管理员发现了，就没了
加上扫描的时间，差不多用了两个月
当初放的时候就知道会有这一天，只不过一直无事感觉像是永远没有问题一样
考虑看看腾讯，看起来还算比较便宜
毕竟a+c总共3G+大小的数据库，可不是普通的地方能撑得住的
5/13 下午
试用腾讯“按量收费”，抛弃
辣鸡玩意儿，实际上是按照开通时长计费的，即“开通时间=使用时间”，还以为会是按照CPU时间计费
5/14凌晨
暂时利用阿里云9.9学生机挂上，腾讯学生认证略慢，之后准备换到那边的1元机上。极限压缩成本中