中秋快乐!

今天是中秋节,照惯例先上月亮。同时祝愿大家中秋快乐,阖家团圆。
Image
虽然我人缘也就那么回事,不过平时每逢节假日,依然总少不了朋友发来的祝福短信。中秋节也没有例外,也收到了一些短信,在这里先谢谢大家了。
今年收到的短信中,有一条挺令我感动。
“祝晓夏节日快乐阖家幸福。”
在群发短信占多数的现在,能收到一条专门给我一个人写的短信,不由得令我感觉心里一暖。所以,今年我发出去的祝福短信,没有用网上流传的那些制式版本,而是分别为每个人写了不同的短信。
“超啊…啥都不说了,节日快乐。就祝你…球技进步吧。”
“谢谢了,晓夏。训练你的任务还没有完成,嘿嘿…我们有机会继续”
“啊哈哈…你就别对我报太大希望了,本来就是运动白痴,能把我训练成现在的水平就已经是你的一大功劳了。”
“看来我必须整出一系列的魔鬼训练了,嘿嘿…你就祈祷好了^o^”

此外,感谢飞哥飞嫂送给我的老鼎丰月饼:D

去帽儿山了

Image
上周六周日两天,跟周飞一起去了哈尔滨市郊的帽儿山。
周六中午1点到哈站,上了一辆见站停见车让的绿皮硬座车,车程很短,票也很便宜,才8块钱。好久没坐这么慢、这么破、这么便宜的车了-v-只是暑假坐了几次津京高速铁路再坐这个心里落差稍微大了点。不过反正是玩去,慢点也无所谓了。
因为事先预定了“山庄”,所以下车之后有车来接。一辆昌河拉着我们到了离帽儿山镇不是很远的“太和村”,山庄的名字也应着村名叫“太和山庄”。
晚上围着篝火跳舞、烤肉、看星星。
农村的星空真的很震撼,城市长大的我第一次看到了银河,也在那一刻,我才真正明白了“璀璨”这个词的意思。那个星空仿佛真要把人包进去、吸上天般地广大。

在“山庄”(实际上基本上等同于农家院)让周飞帮我照了几张,我拿过相机一看就无语了…我肚子什么时候这么大了 囧……在家懒惰了一个暑假就变成这样了,太可怕了………从今天开始跑步-v-不然真的变成中年大肚腩可就太不值了。我把那张照片做成了头像,放在校内和自己的blog,不断鞭策自己……

第二天一早我们起床爬山。太和村同上山的那条路其实不叫“路”,只是被踩出来的土路而已,山坡非场陡,基本上都大于45度,需要手脚并用才能网上爬。
照片请见:http://picasaweb.google.com/dgwxxcn/fHKOjB
(因为picasa上传的时候会对图片进行压缩,效果实在是变差了好多。下次不用picasa了= =||)

校内弱智的日志功能…

上上周发现校内的日志功能悄悄增加了一个“分类”功能。对于这个最基础不过的功能,在我等了两年之后他终于添加进来了。
此外,我感觉社交SNS类网站的日志应该更强调“标签”的概念而不是“分类”的概念,因为我们可以通过标签很轻易地找到他人同样话题的日志,进而找到有着同样兴趣或者想法的人,这才是社交网站该做的。以校内的技术不是做不到这个,而是他没想做这个。
话说,抄袭可以把表面的东西抄过来,但是永远超不来核心的精髓部分。你把page style抄得そっくり又有什么意义呢,FB一改版,你们迫不及待也来一个そっくり的改版,抄来抄去改来该去,界面操作感还是一如既往的糟糕。用户永远不能在第一时间找到他们想要的功能、注意不到他们最应该注意到的东西。设计糟糕,广告倒是一点没少加,页面被分割得乱七八糟,花花绿绿的东西在不停稀里哗啦乱闪。国内的互联网公司还是一如既往的急功近利与肤浅,那用户当弱智耍,不肯静下心来搞自己的东西。这就是为什么你永远达不到人家价值的原因。

此外,我希望那个谁你停掉你那些无谓的口水日志吧,你那些所谓的技术文在真正懂技术的人眼里不过是胡扯八道。你越扯淡,越是哗众取宠,就越是赢得不了别人的尊重。你从初中到现在不都是这样过来的么,难道你还想再在别人鄙视的目光下终老不成。想搞技术可以,低调起来真正搞出成果了再出来叫好了。

Google Chrome即将发布

好久没写Blog了……-v-
最近突然听闻Google要出浏览器了,美国东部时间周二上午十一点开发布会,首先推出的应该是Windows版,Linux和Mac OS版则会随后跟进。看了看泄漏出来的“预”照,有点像Opera 9.5,UI设计并不是我习惯的那种风格,难道是用firefox时间长了难以习惯别的风格了?
Google Chrome似乎是基于WebKit核心的,跟Safari差不多。不知道兼容性会不会有什么不一样的地方。估计本已被浏览器兼容性搞得焦头烂额的可怜的前端们又要受难了。

读书

学日语三年了,前前后后也看了好多书了,今天整理了一下。下面是我手里的书。

  • 书名后标记“(译)”的使我正在翻译或已经翻译完成的作品,在这里可以找到阅读地址。书后标记“(评)”的书是我写过书评的书,您可以在上面的链接中找到我写的书评。
  • 书名以斜体表示的书目是正在计划购买的书。
  • 书名后标记“(Photocopy)”的是复印本或扫描本。因为手头的扫描本和电子版比较多,所以这个列表以实体书为主。
  • 您也可以到豆瓣去看看我的资料。

文学
幸田 露伴
『五重塔』
志賀直哉
『和解』
『城の崎にて・清兵衛の瓢簞・小僧の神様』
杨逸
『時が滲む朝』(Photocopy)
京極夏彦
『魍魎の匣』(Photocopy)
早見和真
『ひゃくはち』

語学
山口 仲美
『中国の蝉は何と鳴く?』
『暮らしのことば擬音・擬態語辞典』
『犬は「びよ」と鳴いていた』

歴史
池波 正太郎
『幕末新選組』(译)
河合 敦
『早分かり日本史』

ラノベ&ファンタジー
冴木 忍
『天高く、雲は流れ』シリーズ 1〜15(译)
井内 秀治
『魔神英雄伝ワタル・虎王伝説(1)狐虎吼ゆる』(译)(评)
『魔神英雄伝ワタル・虎王伝説(2)鬼夜叉の野望』
『魔神英雄伝ワタル・虎王伝説(3)虎王対虎王』
氷上 慧一
『モンスターハンター 魂を継ぐ者』シリーズ 1〜3(评)
大場 惑
『イース1 天界へそびえし魔塔』
『イース2 天空にひそみし魔帝』
有川 浩
『図書館戦争』

児童書
あさのあつこ
『バッテリー』1~6(译)(评)
『THE MANZAI』
森絵都
『DIVE!!』
上橋 菜穂子
『精霊の守り人』
『闇の守り人』
『夢の守り人』
『虚空の旅人』
『神の守り人 来訪編』
『神の守り人 帰還編』
『蒼路の旅人』
『天と地の守り人 ロタ王国編』
『天と地の守り人 カンバル王国編』
『天と地の守り人 新ヨゴ皇国編』
『流れ行く者 守り人短篇集』

漫画
土塚 理弘
『清村くんと杉小路くんと 1〜4』
『清村くんと杉小路くんよ 1〜2』
28ROUND
『激流血~OVER BLEED~ 1〜2』
皆川亮二
『スプリガン』

冰翼6是个好东西啊

Image
前一阵子天气炎热,机器总是莫名关机、重启,于是为了给CPU凉快凉快,就买了个这个。结果换的时候没换好,直接造成了那块为我服务了正好三年的ASUS报废。只好软磨硬泡从老妈那磨来了¥2500的预算,买了MSI + E8400 + Corsair。买的时候,怕再把主板或者CPU装坏了,前思后想,还买了一个Tt火星9,准备搁置冰翼6。
回家把东西换好之后,加电测试,一次性点亮、装系统、顺利运行。之后马上开x264测试,新U就是不一样,比原来的P4 3.2块了将近四倍。
但是满负荷运行的情况下,CPU温度有60度左右(风扇2000转,在空调底下对着吹有55度),噪声有点大,温度也有点高。最后在VempX的唆使下,还是决定上冰翼6。
冰翼6的扣具比较特殊,四个螺丝钉分开的,没有力度限制,只要你愿意,可以一直往里拧,很容易把主板拧变形(那块ASUS恐怕就是我拧的力度太大压变形了),而且很难保证四颗螺丝加力准确平衡。要知道,一个606克的散热器挂在主板上,就算当时没问题,系统长期运行在扣具压力不平均的情况下,也很容易造成主板慢性变形的。
于是,我很无良地在那块ASUS的尸体上反复练习了一个下午 囧 练到可以保证主板不变形的情况下,把冰翼6装在了MSI上。
之后,一切安静了……冰翼6在风扇出力半开(1000转)的情况下,把全速运行的E8400压制在了51度(不开空调)!MSI最低支持风扇转速半开,如果可以,我还想把转速调到800转,那样估计可以更加安静。

摄像机和照相机是有区别滴…

本文并非为BOB或者CCTV而写,而是为摄像机和照相机而写。
这几天网上流传着不少开幕式照片,于是就有人以照片为依据来炮轰转播版本如何如何辜负演出了,如何如何对不起人民了,等等。一开始,我也被那些照片忽悠了,但是仔细一看,图片的比例根本不对嘛,既非4:3也非16:9,一想才明白,那些图片根本不是电视转播的截图,而是照片。
从我个人来说,我也对BOB的版本有所不满,看过其他电视台版本的录像我意识到这场开幕式原来可以被转播得更好。但那些照片并不应该成为我们指责转播质量的依据。
单反相机可以通过装备鱼眼镜头,以超大的广角制造夸张的图像畸变来达到增加画面气势的目的。而这对摄像机镜头来说是不可能达到的。而且看看那些颜色绚丽的照片吧……一定是PS精心调出来的效果。夜里舞台的照度本来就不算强,再加上现场的表演和光照时刻在变化,因此直播情况下是难以调出和照片一样的色彩的。这次造成照片和录像差异的,只有人类的技术水平。或许20年之后,就能看到画面像照片一样精美的的电视了。应该看看真正的区别在哪里。我个人认为差距在导播和摄像的能力(表现在画面切换的精妙程度上、镜头的构思上等等)和机位的安排,而非画质或是气势。
所以,尽管BOB的转播并不是那么尽如人意,我们还是要冷静地对待中外差距,如果只是看到两张照片就谩骂指责,未免网络暴民了一些。建议大家看过国外的录像之后再发言,BOB版拍不出来的画面,国外电视台同样拍不出来。

诡异的CCTV奥运开幕式SD信号

本来兴冲冲地买了一个爱狗USB电视棒想录CCTV-HD的,结果买到之后才了解到必须到能看得到天塔且没有建筑物阻挡的地方才能收到数字信号,遂乖乖断念在家录SD。本地电视台转播质量本来就差,再加上是老楼房,线路质量那是相当的不好,画面经常出现雪花,音质也不理想。但没想到SD一看,才看出来很多好玩的东西。开幕式本身的精彩程度是毋庸置疑的。恐怕以后也难有超越本届奥运会的开幕式了吧。
7:48分直播正式开始,屏幕上出现了鸟巢的画面。结果几秒钟之后字幕一出来我就囧了。
Image
这是搞什么飞机……电视有overscan,没听说过字幕自己overscan的……八成是CCTV偷懒,把HD的信号变形切边之后直接嫁接到SD这边来了。
Image

Image
这两个画面更加证实了我的想法,的确是HD信号变形切边之后嫁接过来的。字幕被切过了……

演出继续,画面切入了会场大屏幕的影像。
Image
竟然是25P的……看来是CCTV事先拿到了带子,直接播的录像。不过这没什么,雅典奥运会转播的时候,公共信号似乎也是这么做的。

之后更囧的事情发生了!看来这时CCTV自己也意识到了信号的问题。时间走到27分钟,也就是人体作画的环节。20473帧开始到20500(27:00.000秒,看来他们是掐着整点算的)帧结束,一个“温柔”的渐变,画面竟然从4:3画面渐变到了Letterbox形式的16:9……OMG……
Image
这时候画面上的“直播”logo也从新闻台的“直播”换成了CCTV-HD台的“直播”。下面是对比:
Image

Image
看来这回变成了把HD信号变形之后加黑边嫁接过来了。这时,字幕也恢复了正常。
Image
但随之而来的问题更囧了,以HD画面的尺寸为准加上去的滚动字幕缩小之后,就算在电脑显示器上也难以辨别,更别说在可怜的破电视上了。
(这张图没有经过缩放,720*576的)
Image

看来CCTV在HD信号和SD信号同时播放方面还没有足够的经验啊,开幕式就直播得这么囧……不过,我估计上述问题应该仅限国内提供SD信号的那几个频道,发送海外的公共信号应该没问题才是。
抛开画面上的囧处和偶热切错的几个镜头和点火前那台信号出问题的摄像机之外,总体来说,还算是完美。

TIVTC的自动交错帧记录与手动OVR脚本

上次在这篇帖子里提到了ovr的利用,今天来详细写写。

好长时间没码字了,那么今天就来写一个可能很多高手都会解决的问题,那就是利用TIVTC的自动记录交错与手动OVR脚本来手动指定Post-processing的动作。
在IVTC过程中,一部分帧会走PP,也就是被送去Deinterlace。但是这部分帧当中,有一部分是因为匹配失败而被PP(确实找不到合适的场匹配结果),有一部分是匹配成功但被误判为交错送去PP,而通常情况下只有较少的一部分帧是真正因为无法找到合适的匹配而出现交错的(也就是第一种情况)。

TIVTC的匹配精度很高,绝大多数情况下不会出现错匹配的情况(但是我也遇到过极少数例外的情况发生,需要通过ovr手动指定匹配pattern,这个下次有时间再写)。
TIVTC的问题在于,他的默认参数比较灵敏,在后处理检测时微小的交错也能察觉出来,因此容易造成误判,特别是动画OP/ED中的字幕,经过PP之后,文字不断抖动,非常难看。而那些参数又非常难以调整,常常是这边调好了,那边又坏掉了。虽然通过OVR也可以单独分段指定参数,但我还是建议使用默认参数,最后通过OVR来针对出错的帧进行修正。
因此,我们就需要结合TIVTC的记录输出功能和OVR手写脚本功能来“强制”TIVTC对我们指定的帧进行PP或者不进行PP。

我们首先要找出哪些帧出了问题。之前我注意到,不少同学还在使用我好多年前用ConditionalFilter + decomb写的那个交错侦测脚本,其实现在TIVTC里面已经内置了相当丰富的交错侦测功能,独立函数ShowCombedTIVTC和IsCombedTIVTC在调试TFM的cthresh、 MI、 chroma、 blockx、 blocky、 metric等参数方面很好用,也可以结合ConditionalFilter写出来交错侦测的脚本,但我们今天要用的是TFM内置的output参数来输出log文件。
首先,我们需要构建出来一个avs脚本,让tfm输出log文件。这个过程相当于IVTC过程的1pass,我们不需要通过这个脚本输出成品,因此要让这个脚本高速地执行,快速得到我们要得log文件。
1pass.avs:
d2v = "op.d2v"
MPEG2Source(d2v)
tfm(d2v=d2v, mode=3, pp=1, slow=2, chroma=true, output="log.txt")
PointResize(96, 96)
各个参数的目的是在保证检测精度的情况下尽量提高速度。
log.txt就是我们要输出的log文件。现在我们要执行这个脚本,你可以通过播放器去播放它,但是这样还不够快,我们可以让x264以一组简单的参数去压制这个脚本,这样通常能够得到数倍于播放的速度(它在我的E8400 CPU上跑出了150fps)。
x264 --crf 51.0 --level 1 --no-fast-pskip --nf --no-cabac --subme 1 --partitions none --me dia --threads 2 --thread-input --aq-mode 0 --progress --no-dct-decimate --no-psnr --no-ssim --output "F:druagaopop.mp4" "F:druagaopop.avs"
(注意,请不要用MeGUI去压这个脚本,用MeGUI压制的话tfm之会输出一个空文件,而得不到我们要的log。更不要试图修改log文件,因为之后载入log文件的时候,tfm会检测log文件是否发生过改变。)
压制结束之后,我们会得到一个不小的文件,他包含了tfm对每一帧的处理方式、判断结果。但我们真正需要的是这个文件尾部以#号开头的那一段。
一段典型的该部分log会像下面一样(中文部分是我的注释):
#
#
# OVR HELP INFORMATION:
#
# [COMBED FRAMES]
#以下是被判断为交错、需要走PP的帧。前面是帧号,后面是该帧的交错度。
#
# [Individual Frames]
# FORMAT: frame_number (mic_value)
#
# 1544 (256)
# 1545 (256)
# 1546 (256)
# 1547 (87)
# 1548 (108)
# 1563 (82)
# 1566 (92)
# 1569 (99)
# 1570 (99)
# 1571 (95)
# 1572 (110)
# 1578 (256)
# 1579 (256)
# 1613 (256)
# 1614 (256)
# 2184 (170)
#
# [Grouped Ranges Allowing Small Breaks]
# FORMAT: frame_start, frame_end (percentage combed)
#
# 1544,1548 (100.0%)
# 1563,1579 (47.1%)
# 1613,1614 (100.0%)
#
#
# [POSSIBLE MISSED COMBED FRAMES]
#下面是tfm觉得交错程度较大,被判断为可能交错的帧,但因为不够阈值设定的值,因此不会走PP,仅提供用户肉眼确认、参考。
#
# FORMAT: frame_number (mic_value)
#
# 455 (17)
# 470 (16)
# 950 (40)
# 1559 (76)
# 1560 (76)
# 1564 (75)
# 1565 (75)
# 1567 (74)
# 1568 (74)
# 1576 (69)
# 1577 (65)
# 1620 (72)
# 1621 (72)
# 1623 (73)
# 1624 (73)
# 1625 (78)
# 1626 (70)
# 1627 (71)
# 1631 (69)
# 2177 (20)
# 2182 (19)
# 2187 (42)
# 2192 (58)
#
#
# [u, b, AND AGAINST ORDER (n) MATCHES]
#使用了u、b、n这三种匹配方式,得到了“无交错匹配”的帧。为什么说“无交错匹配”而非“正确匹配”呢,因为DVD在制作中可能存在一些bad cut或者Telecine制作错误,u、b、n这三种匹配方式通常可以有更大的几率获得无交错的帧,但是也有可能造成画面一顿一顿的(恰好匹配到了和上一帧或下一帧相同的画面),因此tfm也认为这些帧需要肉眼确认。如果确认发生了jerkness,用户可以通过ovr来选择是输出无交错的帧好,还是通过pp输出一个模糊一些但保持动态的帧好。但这并非本文讨论话题,所以只略微提及一下,详细的……等有时间再写吧。
#
# FORMAT: frame_number match or range_start,range_end match
#
# 319 u
# 347 u
# 387 u
# 428 u
# 730 u
# 826 u
# 920 u
# 948 u
# 1511 u
# 1580 u
# 1615 u
我又写了一个脚本来逐帧确认交错情况。
check.avs:
d2v = "op.d2v"
MPEG2Source(d2v)
tfm(d2v=d2v, mode=3, pp=1, slow=2, chroma=true)
用vdm或者au打开它,跳到[COMBED FRAMES]这段log中提到的帧,逐帧检查,并最终确认1544、1545、1546、1578、1579、1613、1614真正存在交错,其余全部是误判。现在,只需要用记事本写一个文件,告诉tfm其余帧是清白的即可(将误判为交错的帧用-号标记,强制tfm将这些帧直接输出)。
当然,如果你愿意,也可以检查[POSSIBLE MISSED COMBED FRAMES]里面记录的帧的情况,这部分帧被认为是可能存在交错的帧,输出时,这些帧会被当作好帧直接输出。如果这部分帧中真的存在交错,应该在ovr文件中用+号标记。
ovr.txt:
1547 -
1548 -
1563 -
1566 -
1569 -
1570 -
1571 -
1572 -
2184 -
之后我们通过tfm载入之前的log和ovr文件,并引入PP、decimate。
MPEG2Source(d2v)
tfm(d2v=d2v, mode=3, pp=4, slow=2, chroma=true, input="log.txt", ovr="ovr.txt")
tdecimate(mode=1)
这里说明一下,通过input载入之前的log文件可以提高tfm的速度,因为tfm直接从log文件中读取之前做过的计算结果,可以不用再次进行匹配了。而input(也就是tfm自己的计算结果)和ovr文件中指定的策略、参数冲突的时候,ovr的优先权高。

虽然这种工作对于OP/ED来说比较繁重,但是这样通常能够得到更完美的效果。

后记:
TFM的ovr功能超级丰富,几乎可以匹敌手动IVTC的效果。而配合output参数,我们可以用更高的效率来得到更好的结果。
关于p、c、n、b、u等匹配方式,以及通过ovr来指定pattern其实也不是很困难,tfm的readme里面都有很详细的说明。有时间的同学不妨阅读一下。