Office 2016 KMS激活参考

与Windows最大的区别是,MSDN上下载的零售版镜像不能通过安装密钥的方式切换到VL版,而是需要导入.xrm-ms文件。

参考激活命令:

cd “C:\Program Files (x86)\Microsoft Office\Office16″
cscript ospp.vbs /unpkey:BTDRB
cscript ospp.vbs /inslic:”..\root\Licenses16\ProPlusVL_KMS_Client-ppd.xrm-ms”
cscript ospp.vbs /inslic:”..\root\Licenses16\ProPlusVL_KMS_Client-ul.xrm-ms”
cscript ospp.vbs /inslic:”..\root\Licenses16\ProPlusVL_KMS_Client-ul-oob.xrm-ms”
cscript ospp.vbs /inpkey:XQNVK-8JYDB-WJ9W3-YJ8YR-WFG99
cscript ospp.vbs /sethst:<<YOUR KMS SERVER HOST>>
cscript ospp.vbs /act

硬链接问题:不应使用Xcopy移动C:\Program Files目录到数据盘

有一些文章提到了可以使用xcopy将C:\Program Files、C:\Program Files (x86)、C:\ProgramData、C:\Users移动到D盘,然后在C盘建立NTFS符号链接以减少空间占用。例如:

xcopy /e /h /k /x /y /b /c “C:\Program Files” “D:\Program Files”
rd /s “C:\Program Files”
mklink /j “C:\Program Files” “D:\Program Files”

笔者有一段时间也这样做过,但最近经过深入研究,发现这样做忽视了一个很大的问题——NTFS硬链接。

windows vista以上,所有系统文件的实际上均存放在winsxs目录中,然后在system32或syswow64目录下建立硬链接,这样实际上只占用一份空间。安装更新时也是这样做,新文件与旧文件并存,然后将硬链接改到新的文件上。删除文件时,必须将一个文件所有的“指针”都删除文件才会真正删除。

wim镜像支持NTFS硬链接的保存,通过imagex /info可以看到,安装盘中有4G的文件是存在硬链接的。

这样一来移动Program Files到D盘对于windows自带软件,如ie、wmp等完全无法起到省空间的作用,因为它们在winsxs中还有一份指针。并且就算是以后再移动回来,硬链接也无法恢复,还是会多占用一份空间。

另外,由于该问题,使用目录符号链接将C:\Program Files指向D:\Program Files会造成windows update对ie等软件更新失败,因为自动更新无法在已经符号链接到D盘的Program Files目录中创建指向winsxs的硬链接。网上也有人遇到过,说将注册表Program Files目录改为D盘即可,然而没人搞清楚为什么。

硬链接只有在安装系统、安装更新时能够自动地建立。一旦破坏,除了微软没人知道应该怎么科学地重建。如果是换硬盘而不想重装系统,千万不能使用xcopy,而要使用基于文件系统的拷贝,如imagex捕获镜像再应用到新盘上,或ghost partition to partition。否则在win7下最少会造成5G空间浪费,在win8和win10上由于自带显卡驱动包这个数字可能高达几十G。

Users目录倒是可以移动到D盘然后建立符号链接,不过个人建议只动自己的用户目录。

适用于开启与WinXP/2003兼容的标准用户的Win7/2008R2 UAC设置

题目有点绕。需求是这样的:在WinXP/2003下,标准用户组Users具有一般的使用权,但不能对系统进行更改,在那个没有UAC的时代,合理配合使用Users组和手动提权到Administrator,其实也是可以做到和现在有UAC时同等安全地裸奔的(但很可惜那个时代我修电脑的认知还停留在Win98的水平,对NT系统的强大了解甚少,一度认为XP系统很不安全,连自己都装过卡巴死机和360,黑历史不堪回首)。

在标准用户组下,所有程序本身都能运行的,但进行需要权限的操作会直接Access Denied失败。使用标准用户的case还是有使用的地方的,适合于非IT工作单位或家庭、有网管的情况。例如豆子每次回家都会表示自己家中的电脑被装了各种全家桶,考虑到豆子并不能随时向豆爸普及正确使用电脑的知识(这点和我家情况不一样,我爸本来电脑水平并不弱,我是真IT所以多年来一直在黑国产软件而且我爸还是注重隐私的。但最近也有点hold不住,因为我妈,最近回家电脑上都会多了TB浏览器啊,文件默认关联变成QQ音乐啊,至于为什么不是全家桶估计因为阿里没做杀软吧),我建议他直接给受限帐户,常用软件弄好,不允许新软件的安装。

然而豆子配置后表示,不给力啊。在Win7/2008R2下,标准用户遇到需要提权的情况时还是会蹦安全桌面,要求输入管理员的密码,这不是等于明摆着告诉豆爸我把你电脑锁了请打电话找我要密码。好的我们有组策略,组策略里可以设置标准用户的提权操作为拒绝提权。结果这样一来任何要求提权的软件均不能启动,包括计算机管理、配置了manifest的exe以及文件名中带有setup字样的exe,提示组策略禁止了该软件启动请与管理员联系。好吧软件都没法启动了还用个毛啊。

我们需要的是像WinXP/2003那样,软件还能用但是干不了啥流氓事。这个问题我当时实验了不少设置没有成功,后来一度搁置了,主要是网上没有搜索到类似的案例,也许是这个问题描述不好总结出关键词搜索。UAC是在程序运行前的,显然我们没法去把所有程序的manifest去掉。三个月前因为这个问题把家里的电脑换回了xp。

今天帮忙优化工作室的电脑,那种ghost win7的版本,默认administrator帐户,试着开一个普通的受限用户,结果需要提权的时候uac并没有蹦出来弄的反而提不了,所有程序右下角也没有小盾牌,需要权限的程序也能以受限权限运行,点任务管理器里的显示所有用户进程怎么点都会重启任务管理器,但是还是受限权限,计算机管理也能以受限权限打开(但打不开磁盘管理)。这很奇怪,和我当时做实验时不一致。

一度以为是ghost win7直接把uac阉割了,但没查到具体怎么做的,但无论如何,这说明我想要的这个功能在win7中还是能实现的。自己再做实验时无意中按照一篇文章中说的把HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System中EnableLUA设为0,然后重启,居然成功了。后来再进一步看,发现这货就是组策略中的“管理员审批模式”设为禁用或者控制面板中UAC设置中最低一级的完全关闭嘛。当时做实验时应该也有试过这样的操作,但为什么没成功现在不得而知。

总之,结论是如果需要在Win7/2008R2中使用WinXP/2003中的受限用户,则应将UAC彻底关闭,否则所有带有manifest的程序均无法直接运行而是会弹UAC密码框。关闭UAC后,右键的管理员权限运行还在,但是不起作用,若想避免切换用户提权,需要按住shift右键选择以指定用户运行,然后输入管理员的用户名和密码,但这时程序实际运行的帐户也将是另外的帐户,环境变量也是另外的帐户的,例如AppData不再指向当前帐户的目录。

在普通文件中隐藏TrueCrypt加密卷

TrueCrypt是很好的硬盘加密工具之一,虽然说因一些不能细说的原因目前停止了开发。官方给出替代产品是BitLocker,但众所周知BitLocker是Win7旗舰版里才有的功能,广大人民群众是用不起的,且向下的兼容性并不好。FreeOTFE是个人作品,在x64系统上有驱动签名的问题,虽说可以找作废的证书签名绕过,但肯定过不了杀软且再发布版本将流淌着浓浓的山寨气味。

288号文章中笔者已经详细比较了以上几种加密方式,其中对TrueCrypt和FreeOTFE的隐藏卷做了一些比较。TrueCrypt隐藏卷的缺点主要是往外层卷写数据时有破坏隐藏卷的风险,所以公安部门也会用这种办法,在无法确认隐藏卷存在的时候会破坏掉数据让嫌疑人在被调查结束后也无法取回自己的文件(得不到的就毁掉,这是真爱。。)

FreeOTFE的优点是可以在现有文件中(如电影)隐藏加密卷。近日研究发现,TrueCrypt也可以通过一些小trick实现这样的效果。

原理

TrueCrypt卷的设计结构如下:

偏移	长度	内容
0	512	卷头
65536	512	隐藏卷头
131072		加密数据
-131072	512	备份卷头
-65536	512	备份隐藏卷头

因为需要支持隐藏卷,卷头中存放有卷的开始偏移以及长度。所以只要卷头相应的位置上填上正确的数值,即可指定从任意文件中加载卷。

而挂载时TC提供使用备份卷头尝试加载的功能,这使得我们可以只更改文件尾部-128K或-64K位置的512字节数据,而保持文件头不变,这样原有文件几乎不会被破坏。

实验

TrueCrypt当然没有提供这样的功能。通过阅读TrueCrypt的代码,决定目前暂时使用OD调试的方法来完成这个任务,因为想自己重新写一个TC格式化程序会死人。

通过代码审查,发现格式化卷生成卷头的调用位于Common\Format.c:140行,在TrueCrypt Format.exe中该调用位于0x449251地址处。在这个调用时修改dataOffset和dataAreaSize参数即可指定加密卷在文件中的位置与大小。

调用结束后,header指向的内存,本例中为0x3A096DC内存中的512字节即为得到的卷头。选择512字节,在内存窗口右键点击二进制复制。

用WinHex打开需要当作容器的文件,定位到-0x20000的位置,Ctrl+B粘贴。

使用

TrueCrypt加载时选项中选中“使用备份头”即可。

然后在Windows中格式化即可正常使用。

问题与安全

在实验中表明,卷起始位置必须对齐,不对齐的话可以加载,但无法格式化与写入。具体多么整我没有再去测试,推测是扇区对齐,因为MSDN中ReadFile与WriteFile要求块设备必须是扇区对齐。

另外使用备份头加载的卷无法直接通过自带的修改密码功能修改密码,不过可以绕过,即先备份文件头512字节,将备份头复制到文件头512字节,然后修改密码,再把这512字节恢复回去。

关于取证安全,比起按照TrueCrypt手册使用隐藏卷,安全系数肯定有所下降,因为很容易通过分析文件损坏的位置来确定加密卷的位置,对于“被逼迫说出密码”的情形无法应对。为此应尽量使用电影与视频这样的无规律数据作为容器。此外,文件的修改日期会暴露存有加密数据。对于下载的电影,如果某个文件修改日期比较不合群,则会受到怀疑。

手动编辑$BadClus标记坏扇区

高能警告:本文系给文件系统动手术,意在折腾与学习,实际操作中请务必小心谨慎,最好备份重要文件以及要编辑的扇区,进行每一次编辑操作前请务必确保自己已经了解这一步的原理,否则请在分分钟把整个分区弄丢后执行chkdsk修复的过程中默念100遍“不作死就不会死”。

友情提醒:本文仅记录笔者个人案例,仅说明$BadClus文件相关,不介绍基础知识,请先了解硬盘分区、NTFS文件系统、MFT表等相关知识。

修复文件与定位坏扇区位置

这几天打算调整分区对齐,因为没对齐的分区若要对齐必须全部数据平移而不能借助无损分区工具(所有的簇全部是没对齐的必须全部平移,分区工具只能按簇的单位滑动才能尽量少地移动数据),所以只能考虑在对齐的位置新建分区,将全部数据拷进来。

往移动硬盘拷数据时有一集动画片复制失败,使用WinHex拷贝选区到新文件写入到80%的时候报告错误,新文件不完整。查看新文件的大小在源文件中找到出错位置附近,跳过报告错误的位置将剩余部分手动复制到新文件中,出错的位置粘贴0字节补齐,这样即可得到基本修复的文件(当然没办法完整播放了,但是可以跳过那几秒)。之前用HDDREG修复过硬盘上的一些坏扇区,这次打算尝试通过NTFS的坏簇列表屏蔽。

用WinHex打开分区,找到出错的文件右键-位置-列出的簇,在簇窗口中右键-缩短连续的簇列表,手动计算之前编辑文件时出错的大概位置对应到哪个簇,并定位到这块位置,此时WinHex访问出错,并且应当能报告无法访问扇区的准确扇区编号,将扇区号记录下来,加上分区的起始扇区,即得到硬盘坏扇区的LBA。因为我是要重新分区,所以待重新分区后再用这个LBA计算出新分区的簇号,如果不是重新分区,直接记录簇号即可。

MarkBadClusTool是一个很好的作品,可根据LBA将坏簇填写到$BadClus里,但笔者使用时出现了一些问题,比如填写扇区扩展的数值填0的话程序报告无效数值,填小数目比如1的话程序最后执行完后压根没往$BadClus里写东西,估计是算法有缺陷。笔者硬盘的坏扇区不是机械故障,很小规模的,并且不会自己扩散,所以没必要把周边的好扇区一并屏蔽了。另外就是这个工具每次都要走两遍MFT,作用在于如果坏簇上已经存在文件,将尝试将该文件移走,而笔者已经手动把那个文件弄走并且修复了,默认坏簇现在处于free空间,仅需要把它添加到$BadClus这个文件里即可。因为MarkBadClusTool有提供源代码,遂决定自己折腾一下。

data runs、稀疏文件与NTFS压缩、$BadClus:$Bad研究笔记

对于硬盘上的数据,MFT中以data runs的结构存储文件的簇指针。简单地讲,就是一堆起始簇号-大小pairs的有序集合,这样就能表示一个文件了。pair使用可变长度整数记录,每个pair首字节高4位表示“起始簇号相对于上一块的delta”这个整数的长度,低4位表示“块大小”这个整数的长度。语言说起来比较绕,建议查阅已有文章,有图解的一目了然。

$BadClus的$Bad属性记录坏簇这个知识很容易就在网上找到,但是如果直接按上面的data runs填入坏簇的位置信息,写入后会发现分区丢了,说明“打开的姿势不对”。查阅MarkBadClusTool的代码,发现程序使用DataRunsToSpaceDataRuns“将常规Dataruns数据转换为用来描述空间信息的dataruns”。这句注释写的很不明所以,走读代码后发现这段代码是将坏簇的data runs两端与之间填入正常区域的长度。

原理上讲同为data runs是不应该有多种写法的,查阅了很多资料才得知真正含义:$BadClus:$Bad文件并不是一个将坏簇连接起来的文件,而是一个大小为整个分区的NTFS稀疏文件,其中正常的位置是稀疏文件的0,坏簇的地方指向磁盘上的坏簇。而稀疏簇的表示是将“起始簇号”设为-1,“起始簇号delta”设为0,表现在data runs里就是一个字节的整数长度接上正常块的长度数据。这一点MarkBadClusTool虽然执行的结果对,但写法与注释其实并不正确(那么真正的0簇开始的数据因该怎么写,答案是1x xx 00,见$Boot中的记录)。

顺便聊一下压缩。NTFS压缩是完全基于稀疏文件机制的。data runs只有真正簇(delta_lcn不为0)与稀疏簇(delta_lcn为0)之分,并不在乎存放的数据是压缩的还是未压缩的。数据是否压缩通过64K块是否在末尾有稀疏簇来判断。如果一个64K块尝试压缩后体积并没有减少4K以上,那么该数据依然会以未压缩形式存放,如果减小4K以上,那么就在末尾插入几个稀疏簇补齐到64K。

NTFS的文件属性查看压缩文件对于压缩后没有减小体积的其“占用空间”显示为文件大小,但是从上面的算法来看,有一定的几率是压缩后比未压缩大一个簇的。可实验建立一个刚好为4K的随机数据文件(无法被压缩),NTFS会将其补齐到64K然后尝试压缩,结果自然要比4K多几字节,这样就占用了2个簇的实际数据。

基于稀疏文件的NTFS压缩在对付迅雷下载刚开始创建文件时的卡死有奇效(迅雷脑残不在程序里指定创建稀疏文件。。。)

案例

下面以笔者的案例介绍一下手动修改的过程。

本次要处理的坏扇区为754546051到754546055连续的5个扇区,位于当前D盘,D盘起始扇区为83886080(40G整),持续400G。簇总数为104857599(最后一个簇为保留扇区,最后一个扇区为PBR的备份)。

754546051-754546055对应到D盘逻辑扇区为670659971-670659975,除以8得到簇号为83832496,刚好被包含在一个簇里。

构造整个分区大小的稀疏文件:第0到83832495共83832496个簇的0、第83832496簇开始长度为1的坏簇、第83832497到104857598共21025102个簇的0。写出来为:

04  B0 2E FF 04    41  01  B0 2E FF 04    04  4E D1 40 01    00

定位到$BadClus:$Bad的data runs位置($BadClus+0x168),填写上面的内容,然后将0x124位置的属性长度改为修改后长度,8字节对齐(本例改为0x60),在0x180位置填入MFT记录结尾的FF FF FF FF,在0x18位置填入修改后的MFT记录长度,8字节对齐(本例改为0x188)。然后找到$Bitmap文件,计算第83832496/8=10479062余0字节对应的扇区位置,将该字节第0位置1表示空间已分配。

然后即可写入磁盘。WinHex旧版本不支持DeviceIoControl卸载分区,换用新版本即可。

参考文献

1、MarkBadClusTool及其源代码:http://bbs.pediy.com/showthread.php?t=162539
2、上述源码中layout_ntfs.h中Attribute compression一节的注释
3、$BadClus:$Bad是稀疏文件:http://0cch.net/ntfsdoc/files/badclus.html
4、data run:http://blog.csdn.net/begges/article/details/6699236
5、《数据恢复技术深度揭秘》相关章节

一种强行将Android机身存储迁移到SD卡上的方法

问题

某一天突然发现手机相册打不开了,说是内存已满,仔细调查发现,/sdcard/tencent/MicroMsg占用600M空间。

找遍微信的设置,没有找到将存储位置改到SD卡上的选项。找遍三星手机的设置,没有找到“优先使用存储卡”,也就是将/mnt/sdcard与/mnt/extSdCard调换的选项。

难道只能清空微信数据?笔者表示至少应该努力一把再说。

研究

首先,你得是个技术宅。其次,你的手机应该root过。然后,你至少得会用adb打shell,并且懂一点linux。

早期的Android大都没有机身内存的,/sdcard用来挂载扩展存储。后来闪存白菜价,以及向苹果看齐的缘故,渐渐地sd卡就淘汰了,但是为了保持向前兼容,依旧用/sdcard目录作为文件存储,但是指向的是机身ROM。

对于我自己三星S7562的情况,外置存储卡被mount到/mnt/extSdCard,而/sdcard直接链接到/mnt/sdcard,查看mount信息可以看到/mnt/sdcard是一个FUSE文件系统,查看进程发现有个/system/bin/sdcard进程提供这个FUSE。进一步研究发现,这个FUSE虚拟文件系统实际上是指向/data/media,即受制于/data分区的总大小。

能否利用linux的符号链接将机身内存某个目录(例如微信)链接到sd卡上?尝试在/mnt/sdcard下直接ln -s,报告不支持此操作。尝试在/data/media中ln -s,当然能成功,但是回到/mnt/sdcard中发现cd不进去。表示Android的虚拟sd卡服务没有实现符号链接。

能否不使用Android的sdcard FUSE服务,直接将/mnt/sdcard指向/data/media,然后再使用符号链接将部分目录指向外置sd卡?测试表示似乎可行,微信能够正常读取文件。

方案

1、安装busybox。诸如mount –bind这样的命令Android默认的shell不支持。可直接到http://www.busybox.net/downloads/binaries/latest/下载二进制复制到/system/bin,然后可以busybox –install -s /system/bin安装。

2、将/system/bin/sdcard备份,然后建立同名文件,编写如下的脚本:

#!/system/bin/sh
/system/bin/busybox mount --bind /data/media /mnt/sdcard
while true; do sleep 1; done

之所以不用符号链接是因为/mnt/sdcard本身已经存在,建符号链接需要rmdir,并且用mount目录的方法可以和以前mount fuse兼容。
之所以直接改这个文件是因为如果要直接编辑启动脚本(本例是/init.qcom.rc),需要了解到Android的根目录并不像桌面linux最后会chroot进磁盘分区,而一直是boot时的ramdisk,如果要改这个将面临重新打包boot.img并刷机。

3、将需要迁移的东西从/data/media迁移到/mnt/extSdCard。例如本例将/data/media/tencent/MicroMsg移动到/mnt/extSdCard/tencent,然后ln -s /mnt/extSdCard/tencent/MicroMsg /data/media/tencent/MicroMsg。吐槽一下这个目录里大多是零碎的朋友圈缓存图片,我用RootExplorer移动整个目录花费了3个小时。TX你稍微用一下sqlite保存图片会死么。

已知问题

1、大小写问题。/data/media是区分大小写的,对于同类软件建立同名但不同的大小写(如微信是tencent,但QQ是Tencent)只能符号链接到一起。这个没更好的法子解决。

2、权限问题。即便将/data/media设为777也不够,存在创建文件的mask问题。linux权限机制我还不是特别了解,暂时放这里有空再去填坑。

渣压制参数调整与上传计划

20151218 EDIT:压制总结

级别、帧率、DPB详解:

http://www.cnblogs.com/zyl910/archive/2011/12/08/h264_level.html

关于三星S7562:

三星S7562最新实验结果与之前有异,并非直接照搬PSP的要求。具体为分辨率不超过屏幕分辨率800×480,在此情况下参考帧最大可设为8,超过则系统直接报错拒绝硬解。也就是DPB为(800*480)/(16*16)*8=12000,介于标准3.0的8100到3.1的18000之间。

但是硬解驱动有个bug,若分辨率小于800×480,系统层会以实际的分辨率计算DPB数,检测不超过12000就会进行硬解,而硬解驱动的实现似乎是不管输入分辨率多少,送给芯片的都是800×480,可能是写驱动的人偷懒,直接给分辨率不到800×480的补上黑边扔给芯片了。这造成ref大于8的系统层检测是同意硬解的,但是一旦引用到超过8的ref势必就会花屏。在之前的压制参数里,没有限制ref,但是因为有b-pyramid=0使b帧不能引用,因此实际ref在大部分情况下不会超过8,所以花屏很少出现。

关于b-pyramid=0,即ref不能是b帧,否则播放时会跳帧闪屏。有意思的是MX Player的“硬解码+”功能可以修复这个问题,不知道是如何做到的。同样的其它参数下不能引用b帧会带来不少的压缩率浪费,以前测试基本上在2%的样子,即50M的视频会增加1M大小。而这个参数实在很小众,除了古代的PSP,只有我这个三星会这样,我这几年都没见过专门去设这个参数的片源,实测b站也没设这个参数,因为用这个手机看会出现跳帧的情况。既然MX Player可以修复之,我大概可以放心地在以后压片的时候去掉对这种手机的兼容以节省2%的空间了。

其他的坑:

苹果iPhone4S和iPad2也有个bug,就是不管分辨率多小的视频,ref最大只能是15,和DPB无关。在新的苹果上设16就没问题。

iPhone4目前不在手头,到底支不支持high 4.1稍后再测试(可用参数1280×720 high 4.1 ref 8测试,因为1280×720下level 3.1的ref最大只能是5)。可以知道的是MeGUI的target device设置的参数并不是完全准确的。

今天还遇到了一个非常神奇的坑,对VCD做RIP时,若视频部分x264输出的是raw 264(raw264好处是可以在编码过程中打开预览,而mp4必须有索引所以只能等编码结束),则在iPhone4S/iPad2上播放时,音频没有正常delay导致不同步,在电脑上播放就能正常同步。而编码时x264若输出mp4文件则mux出来在iPhone4S和iPad2上就没有问题。

===========================================================

起因是最近又补了几部漫,收藏后却发现以前的参数压出的片没法在S7562上播,包括以前压好的EVA、School Days等。

用其他参数试验了几次,结合一些网络上的经验参数,结论是该手机硬解只能支持Main 3.0 480P的影片,并且16:9的848×480也超出了分辨率要求,估计是不能超过手机分辨率的800×480。另外,B帧不能作为参考帧使用,即需要设置b-pyramid为0,否则播放时会错误地引用I帧导致画面闪屏。

一种处理方案是将分辨率调整到704×396,但这样又未免太小,在电脑上全屏时很不舒服。所以笔者采用另一种方案,即PSP的480P压制方法,也就是DVD标准的720×480,并指定SAR为32:27以在播放时拉伸到16:9。Main 3.0 720×480下参考帧最大是6。

720×480的缺陷是部分播放器没有正确处理SAR而使用原始比例播放造成画面变形,经测试,电脑上WMP、PotPlayer、Chrome等均能正确还原比例,iPad内置播放器、百度云PC端浏览器Flash播放器也可还原,但S7562、Windows Phone、百度云iOS客户端无法正确还原。不过S7562上可以通过全屏拉伸到800×480来得到近似的还原。

对于720P,Main 3.0肯定无法支持。目前的iOS通吃High 4.1的720P,不过对于iPad 1是只能支持到Main 3.1。1280×720下Main 3.1的参考帧最大是5,这个级别的720P已经非常够用了。综上,综合画质、大小、速度、兼容性四个方面的考虑,Po主的渣压片经验参数调整为如下的傻瓜参数:

480P:
–preset veryslow –profile main –level 3.0 –b-pyramid none

480P 16:9:
–preset veryslow –profile main –level 3.0 –b-pyramid none –vf resize:720,480,32:27

720P:
–preset veryslow –profile main –level 3.1

其中preset=veryslow相当于设置了以下参数:

b-adapt=2, bframes=8, direct=auto, me=umh, merange=24, rc-lookahead=60, ref=16, subme=10, trellis=2

ref在设置profile与level时会被重写为最大支持的数值,subme=10分析比subme=9可以提高7%左右的压缩率,且多消耗的时间并不多。me没有必要设置更高的数值,esa仅能比umh提高1%左右压缩率,但时间会增加一倍,不划算。在High 4.1下进一步提高ref得到的好处也并不多,且会大大增加消耗的时间。crf依旧是默认的23,准高清的画质是完全够看的。

渣成果有空会上传到百度云盘上。话说百度云盘真的是个很YD的地方,可以直接在线或使用pad看别人分享的视频,绝对秒杀youtudou以及当年的115、jshare,许多被萌化大神和谐的片子也能找到(如《Death Note》),妈妈再也不担心我没有动画片看了。

Blog添加扫一扫功能

右侧添加了一个当前页面链接的QR码,调用Google Chart API生成,代码相当弱智:

<img id="qrcode" src="#" border="0" />
<script>
document.getElementById('qrcode').src = 'http://chart.apis.google.com/chart?cht=qr&chs=80x80&chld=|0&chl=' + encodeURI(location);
</script>

20141119:因为谷歌被墙,后来换了另一家的QR API:

document.getElementById(‘qrcode’).src = ‘https://api.qrserver.com/v1/create-qr-code/?size=80×80&data=’ + encodeURI(location);

添加这个主要是考虑到微信似乎找不到地方输入链接,必须用扫一扫才能打开浏览器,以后就可以很方便在朋友圈分享这里的链接了。

让Android浏览器夜间关灯

既然说这两周要专心背谱不能写程序或是看动画片什么的,当然要说到做到。但是无奈离开电脑了又过于无聊了,遂半夜用爪机看同人。。。

同人自然是要在线看的,不像金庸的长篇可以下下来慢慢看,自然也就不用阅读软件,而是直接用浏览器看。

然后就看到眼花。。。不禁吐槽DZ论坛为毛没有夜间模式。。。

(好吧,我承认我觉得UC做烂了现在很讨厌它外加爪机内存小不想装别的了所以这一年一直用内置浏览器)

没有么。。。作为一名优秀的钢(ji4)琴(shu4)家(zhai2),这种小事当然犯不着纠结。。。

javascript:s=document.body.style;s.color="#808080";s.backgroundColor="#000000";

改进版:

javascript:n=document.getElementsByTagName("*");for(i=0;i<n.length;++i){n[i].style.fontSize="10pt";n[i].style.color="#808080";n[i].style.backgroundColor="#000000";}

 
点击此处看效果

加书签,运行,夜瞬间宁静了。。。

今天我是不是有点罗嗦。。。*/

Wine运行QQIntl 1.5

如果在google搜索Wine QQIntl关键词,大概会看到有人发帖庆祝成功,还贴到了Wine官方的“可执行列表”里,然而做起来才发现,这个方案大概只适用于QQIntl 1.1版本,1.1版本大概是QQ2010的内核。对于更高的版本,我用官方的wine是没成功过,比方说,鼠标碰到密码框会崩溃。好吧,让我们用软键盘输入密码,但是为嘛一点登陆就要崩溃啊!虽然本人是个geek,但是对于linux还是小白水平,我可不想为了跑一个qq来现场学习怎么在linux下调试windows程序。。。

经过了一周用pidgin登陆qq的无法收发图片、无法收发自定义表情、无法直接进qzone的生不如死的日子,最终把一直在用的QQ Intl 1.5即“干净版QQ2012”跑了起来。

嘛,这其实不是我的功劳,感谢龙井内核组,他们针对Wine QQ时出现的issue特意编译了一份wine来避免了这些crash,并将wine和qq一起打包发布了传说中的wineqq2012。发布及下载地址请点击www.longene.org/forum/viewtopic.php?t=4700

如果你只是想运行一个中文版带广告版的qq2012就不用往下看了,直接下载安装他们提供的安装包即可,如果你像我一样想用比较干净的QQ Intl,或者想手动配置安装,则继续。我的需求是主要运行qq,但既然他们的wine已经配置好了,我还想拿来主义一下跑迅雷7什么的。即我需要把他们安装包里的wine程序和windows环境单独拿出来。

首先下载deb包,用压缩包工具打开查看里面的文件结构。可以看到作者将这个qq视为第三方软件,将安装到/opt/longene/qq2012中。/opt/longene/qq2012/wine是他们编译的wine。我将这个目录解压到/opt/wine中(没敢直接解压到根里,不然就不知道该怎么删了)。

然后将/opt/longene/qq2012/qq2012.tar.gz拿出来。这个文件打包了已经安装了qq2012的wine的windows环境,即wine prefix。在正常安装下,这里的/qq2012会被解压到~/.longene/qq2012,我按照wine的默认prefix将其直接解压到~/.wine。

接下来,把预装的qq2012删了去。~/.wine/drive_c/Program Files/Tencent/QQ。也可以继续查看这个环境里的东西,觉得什么不需要都可以删。和Tencent有关的只有一个不能删,即C:\Program Files\Common Files\Tencent\TXSSO,这个东西似乎是qq2009之后惟一不绿色的东西。然后,可以把windows分区的qqintl拷过来,也可以直接运行。我是直接在windows分区里运行的。命令为:

env LANG=zh_CN.utf8 /opt/wine/bin/wine /media/DATA/Program\ Files/Tencent/QQIntl/Bin/QQ.exe

至此应该可以基本完美运行。注意需要调整QQ的几个设置:1,关掉General / Main Panel / Always on Top。否则所有主面板打开的菜单都也会被盖住。2,关掉General / Main Panel / Open the animation effect,不然鼠标悬停在用户资料上会出现0.5秒的animation导致的花屏。
3,有需要的话将File and History中的目录设为以前的目录使聊天记录能够接上。