触摸板的三指拖动功能已经被移到“辅助功能”中。

开启步骤：

系统偏好设置－辅助功能－鼠标与触摸板，点击下面的“触摸板选项…”按钮，勾选“启用拖拽”并且从下拉列表里选择“三指拖移”。

现在的感觉仿佛让我回到了6年前，8年前。

一切都是很熟悉，但是又有不同。

团队的成员不同，平均年龄不同，做的事情不同，所在的城市不同。

经历过那些最艰苦的岁月，不管面对何种挑战，窒息的压力，无形的重担，我想我都能淡然面对，从容的走过。

既然我们能在一个团队，大家和我一样想有一段与众不同的经历。

我们能在一起互相鼓励，互相支持着一起跑过终点。

我想若干年后，我们会很跟其他人说：我这在这里干了一件很nb的事情，我很骄傲。

把安装文档记录下：

terminal 默认shell换为zsh：

brew install autojump

修改terminal的配置为黑底：

修改terminal的alt按键，实现alt+f, alt+b, alt+d:

Done, enjoy it!

如截图：

找了半天没找到问题出在哪里，sshd的设置一切正常。这个做过多次居然也能错？？？？

最后发现原来是 ~/.ssh/authorized_keys 文件的内容有问题，putty生成的pub文件的格式如下：


---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key"
AAAAB3NzaC1yc2EAAAABJQAAAQEAvifBFJzxK0PGJVNV9ZdDGOYWvytwnFDKoaZv
Djdt7rEK+zeFzR6eU7ERhOjMPb7GfoFU/1JPwXqSN2p57T4xdtR/Qi9/XAhmQ9SY
XnfA1yNOhHXoQuoCEjOmIbOo+NmZCoKPeBob7fXV8Ar7MmJ0vUpZ+79Usm9lsvQF
zEfI/Q1NuaVoOb7s6CFyj9WcmX7Yzc3cXpIHeFzLfLTFFROohw==
---- END SSH2 PUBLIC KEY ----


而原来设置的都是在一行的格式，所以openssh不支持putty生成的此格式，需要把这些合并成一行即可：

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAvifBFJzxK0PGJVNV9ZdDGOYWvytwnFDKoaZvDjdt7rEK+zeFzR6eU7ERhOjMPb7GfoFU/1JPwXqSN2p57T4xdtR/Qi9/XAhmQ9SYXnfA1yNOhHXoQuoCEjOmIbOo+NmZCoKPeBob7fXV8Ar7MmJ0vUpZ+79Usm9lsvQFzEfI/1NuaVoOb7s6CFyj9WcmX7Yzc3cXpIHeFzLfLTFFROohw== rsa-key



.fseventsd
.Spotlight-V100
.TemporaryItems
.Trashes


而且看个头都挺大的（几十兆），是Mac OS X的自带的spotlight的索引文件。

就查了下怎么禁止spotlight对一个移动设备进行索引（移动硬盘、手机、kindle等）。

很简单，在移动存储设备的根目录下建立 .metadata_never_index 文件。

Mac OS X下在终端，进入到移动硬盘根目录：

touch .metadata_never_index


Windows在命令行或者运行执行（J为盘符）：

echo > J:\.metadata_never_index


一直寻找windows下的解决方案，经过一段时间终于找到了AutoHotkey这个软件。

下载AutoHotkey http://www.autohotkey.com/，然后安装。

新建文件reverse-roll.ahk，输入内容：

#MaxHotkeysPerInterval 200

如果有报错说是MaxHotkeysPerInterval不够的话，继续加大第一行的数值。

然后右键点击这个文件，选compile script，生成exe文件，拖动到 开始-> 启动 里即可。

插上USB连接kindle，进入kindle设备根目录。

创建一个空文件USE_ALT_FONTS。

$ touch USE_ALT_FONTS


创建文件夹fonts

$ mkdir fonts


拷贝字体文件到fonts目录里，字体文件名可以用UTF-8编码的中文，比如方正中雅宋：

http://fonts.mobanwang.com/fangzheng/200908/5052.html

结束！重启kindle，进入设置，打开菜单，选重启！

1，在spotlight里能使用字典

2，鼠标位于希望查词的文字上，使用control + command + d也能取词翻译

3，触摸板打开三键双击取词功能也可：

现在要解决的问题是本身自带字典不齐的问题了，其实也很简单：

1，下载词典包转换工具，打开https://code.google.com/p/mac-dictionary-kit/downloads/list 下载其中的DictUnifier-1.1.dmg

2，下载词典 http://abloz.com/huzheng/stardict-dic/zh_CN/ 

3，使用词典包转换工具DictUnifier 转换下载的词典，转换过程较长，耐心等待。

convert完成后即添加词典，最好在Dictionary里选择下你需要使用的词典，以及顺序。

Done。

本次安装在buntu 12.04 x86_64版本上进行，目前hiphop仅支持64bit版本：

1. 有Internet联网电脑一台；
2. ubuntu-12.04 x86_64 OS；
3. 编译时间较长，需要有耐心。

升级ubuntu：

sudo apt-get update
sudo apt-get dist-upgrade


安装必要依赖包:

sudo apt-get install git-core cmake g++ libboost-dev libmysqlclient-dev libxml2-dev libmcrypt-dev libicu-dev openssl build-essential binutils-dev libcap-dev libgd2-xpm-dev zlib1g-dev libtbb-dev libonig-dev libpcre3-dev autoconf libtool libcurl4-openssl-dev libboost-system-dev libboost-program-options-dev libboost-filesystem-dev wget memcached libreadline-dev libncurses-dev libmemcached-dev libbz2-dev libc-client2007e-dev php5-mcrypt php5-imagick libgoogle-perftools-dev libcloog-ppl0 libelf-dev libdwarf-dev libunwind7-dev


git检出hiphop代码：

mkdir dev
cd dev


git clone git://github.com/facebook/hiphop-php.git
cd hiphop-php
export CMAKE_PREFIX_PATH=`/bin/pwd`/..
export HPHP_HOME=`/bin/pwd`
export HPHP_LIB=`/bin/pwd`/bin
cd ..

libevent需要重新patch：

git clone git://github.com/libevent/libevent.git
cd libevent
git checkout release-1.4.14b-stable
cat ../hiphop-php/src/third_party/libevent-1.4.14.fb-changes.diff | patch -p1
./autogen.sh
./configure --prefix=$CMAKE_PREFIX_PATH
make
make install
cd ..


libcurl需要重新patch：

git clone git://github.com/libevent/libevent.git
cd libevent
git checkout release-1.4.14b-stable
cat ../hiphop-php/src/third_party/libevent-1.4.14.fb-changes.diff | patch -p1
./autogen.sh
./configure --prefix=$CMAKE_PREFIX_PATH
make
make install
cd ..


编译jemalloc:

wget http://www.canonware.com/download/jemalloc/jemalloc-3.0.0.tar.bz2
tar xjvf jemalloc-3.0.0.tar.bz2
cd jemalloc-3.0.0
./configure --prefix=$CMAKE_PREFIX_PATH
make
make install
cd ..


以上准备工作就绪，现在开始编译hihop，本次安装是使用的hhvm模式：

cd hiphop-php
git submodule init
git submodule update
export HPHP_HOME=`pwd`
export HPHP_LIB=`pwd`/bin
export USE_HHVM=1
cmake .
make


大功告成，进入src/hhvm里，hhvm文件即是。

PS，ubuntu安装极其简单，但在一台centos6.3上装了n次才搞定。

改完了一个js bug，已经到了凌晨1点，已经周5。

昨天是很欢乐的一天。

晚上如约去中关村找以前的同事吃饭，有月姐，老李，jackos。

回到中关村就有一种特别的亲切感：熟悉的马路，熟悉的中关村购物广场，熟悉的教堂，熟悉的理想国际。

嗯，这里是我来京后第一份工作的地方，起点。

晚上去吃铜火锅也很海皮，最近2年一直想吃北京的那种铜火锅，今天终于如愿。

和几个同事边吃边聊的很开心。多年的哥们总有说不完的话题，聊现在的工作，熟识同事的近况，同事的八卦。说到这儿我咋忘记问玥姐和小瘦同学的事了？

老李还是一如既往的潇洒，有他在，吃饭聊天一定会轻松快乐。

月姐还是一如既往的年轻，平和，笑口常开，好性格。

jackos还是很有范，很有想法，很深沉，并且越来越有老板范。

晚上回家也特意走到了北大西门，坐333公交，末班车还是不变的21:50。

很怀念05-08年在新浪的日子，能有机会进入这样一家优秀的互联网公司，和这样一帮精彩的兄弟共事多年，是我的幸运。

很怀念在新浪邮箱战斗过的日子。

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

有这么多开心的事，也有很让我恼火的。

昨晚上线的一个功能，到今天晚上还有重大问题。而且从上线开始就大问题、小问题不断。

而且最关键的是负责这个事情同事的态度和做法。不厌其烦的说了n次，就是无动于衷。一点都不想去实地的检查自己工作成果，bug都非常容易发现，多点点鼠标，多开几个浏览器就发现了。

我不怕犯错误，就怕犯低级错误，而且还是连着犯低级错误。最关键的是态度和责任心，你真的就这么有信心拍胸脯说ok么？

说了那么多次多测试一下，就是不做。每次改完一个问题都说没问题，然后就干别的去了。

能focus到一点不能？好不容易我们提出了一个还算创新的点子，然后推动实施至今，多少人为此付出了辛勤的工作。最后交给你的这临门一脚不是射偏，就是射高，到最后球鞋掉了。。。

本来能打120分的事，有了这些关键时刻的掉链子后，最多也就打60分了。

并且最让我恼火的是：晚上同事在QQ群里反映问题后，不是积极的去解决问题，而且在哪里amazing，然后发了一条扯淡的话。天天说一些真理性的结论，大家都明白是正确的事，有意思？如果这样打酱油，那就以后都去打酱油吧。

而且我奇怪，自己上线的功能自己就那么大的把握？为啥这几个重大的bug都是外人发现的？

回家后极其不爽，自己无法给自己一个交待，因为这个这个部门是我领导的，这个事情是我负责的。

干脆自己解决，js没弄过，从头来；ie9、ie8、ie7、ie6没有，自己装。2个小时不到，解决问题。

自我膨胀一下：哥还是很优秀的程序猿。

做最优秀的软件工程师，是我不变的梦想。

写篇blog，记录一下高兴的事，再发发牢骚喷喷人。

唉，有想法就说，其实不好。

L和W是09年认识并在一个项目组的，两年过去了，能在一起共事，成为朋友，成为兄弟，…

L是一位在程序开发第一线工作了12年的程序员。我非常的尊敬他。在我工作7年多里，L是和我合作过的最优秀的软件工程师，没有之一。极强的程序能力，尽责尽心，一切尽在掌握的那种沉稳。。。共事这么长时间，他负责的每一项任务都是让我和其他同事放心的。无论难度多高，工作量多大、时间多紧迫、需求多么不清晰，只要交到他的手上，就是一定能cover住。我们需要的就是这样能把后背托付给对方的战友。

W是2010年毕业的本科毕业生，09年11月份开始在当时的公司实习，在一个项目组。计算机专业毕业的他，能在非常短的时间内熟悉并担负起实际工作，并承担起越来越多的工作内容。积极向上的乐观和踏踏实实的勤奋。不到2年的时间，他已经成为了3D引擎开发的核心人员。他已经从一颗稚嫩的小苗茁壮的成长起来，不远的将来一定会长成参天大树。有一天可能我也需要仰望他。

能够认识就是缘分，能在一个团队共事就更是缘分中的缘分，成为可以交心、可以同甘苦的兄弟更是是万中无一。一起共事了近两年，一起从零开始，让公司认可我们的技术实力，认可我们的项目。。。

经历过那些最艰苦的岁月，不管面对何种突如其来的坎坷，窒息的压力，无形的重担，我们都能在一起互相鼓励，互相搀扶着一起跑过终点。没有可以分享的快乐，只有独自承担的磨难，现在的软弱正好证明，我们一直那么的坚强。

坚守的爷们继续坚挺，祝好运。

希望未来的一天我们还能一起共事。

中国最优秀的软件工程师，我们还盼望着未来海阔天空的人生。因为在这个世界中真正可贵的就是那些热爱生活，并勇往直前的人。最后帖一张去年一起爬山的照片做为结尾。

今天开始补作业。

先把环青海湖的游记完成，明天晚上12点前搞定第一篇，共四篇。

然后再把那些以前说要写的关于技术的一些写了。看了看草稿箱，有大概十来篇。

话这是放出去了，看执行。

ZoomQuiet一直追着我要这个文档，今儿又在buzz上说了一下，今天周末加班搞定这个欠账吧。

拆装这些东西已经有很多经验，单纯一个流水账应付周总之用。

首先准备材料，SSD和内存购自amazon.com，使用buytong.com美国代购运回国内，代购的费用是RMB 50元左右，包含包装、EMS和保价费。

SSD使用的是Corsair Force Series GT 120GB，支持SATA III接口，读写速度标称是555MB/s和515MB/s，nb的是IOPS号称85K，这是我买这款的关键，amazon链接。

内存使用的是目前笔记本里最高等级的Kingston HyperX DDR3-1600MHz内存，amazon链接。

就是他们：

同时购买了一个硬盘架和USB光驱盒，用于放第二块儿硬盘和拆下来的光驱，taobao链接。

方案是把原机配的硬盘放置于光驱位，因为我这个2011年早期的macbook pro光驱位只支持SATA II，看其中的link speed字段：

释放身上静电，整理好桌面，开始拆机之旅。

1. 底部螺丝卸掉，先以对角线方向松螺丝，揭掉底盖露出机器内部：



2. 松开电池卡扣，停止电池向主板供电，卸掉原有内存：



3. 装上新内存，到此内存升级完毕：



4. 拆原有硬盘，四角四个螺丝拧掉，很容易拆下原有硬盘：



5. 新硬盘按上很容易
6. 拆掉光驱，仔细看看周围阻挡的排线和螺丝，松之：

,


7. 把硬盘上到硬盘盒子上，同时光驱上有一个卡扣需要拆下装到硬盘盒上：



8. 同时硬盘盒外侧有两处对两个螺丝的固定有一定的阻碍，需要用一个小锉刀简单处理一下，并且金属屑绝对不能带入机器内部，然后安排好排线，上紧螺丝，这是最麻烦的一步，当时忘记进行图片记录了，细心一些很容易搞定：



9. 最后检查一下：所有的螺丝是否上齐，插上所有的排线（尤其不要忘记电池的排线），清理灰尘，清理排线走向，完工！

我在新ssd上重新安装lion，开机按option，进入原有硬盘的recovery disk，然后step by step的进行lion的安装。因为是网络下载安装，进行了两天两夜，好在这个下载支持断点续传，晚上忙完回家开始下载，早上关掉上班。第二天继续。安装完成后开机只需要5s左右，一圈半“菊花”，应用程序都是秒开。

这第二台自购笔记本用了半年很爽，做工一流，升级的高分辨率雾面屏很好，此次升级后再也没什么可折腾的，安心使用到淘汰。

先说高兴的。关系很好的一个兄弟结束了近一年的迷茫和困惑，找到了一个满意的工作，找到了一个靠谱的老大。很替他高兴。职业生涯可能可以归结为两点：跟对老大，做对项目。

一个单纯的技术环境是每个软件工程师向往的。有挑战的项目，水平高、合作良好的同事，合适的收入。是三个必要条件。同时良好的职业规划，切实可行的路线图，对于每个人、每个团队来说也是非常重要的。每个工程师的成长路线都是独特的，找到适合自己的路，找到适合自己的团队，做出好的项目。

这位兄弟已经踏上去四川山区支教的行程，祝他一帆风顺。昨天中午听到他这个想法，突然想起前一段时间一个同样的愿望：去支教一段时间，远离城市，读一些书，接触一些淳朴的人和事，净化一下心灵，认真的思考一下下一步的打算。如果还有心爱的人陪着我就更好了，呵呵。有机会实施一下？

BTW，下午某公司人力资源对他背景调查太给力了，各种问题整整问了我半个小时电话。

我们的项目。本来昨天和今天上午都认为这个大版本发布不会有误差，一切尽在掌握中。但是午饭上电梯的时候突然感到一丝不安，回到座位后又规划了一下剩下几天的任务安排。发现时间已经超出控制了，多出一天的工作量。一天的工作量在整个开发过程中看起来微不足道，但是对于所有参于协作部门和下个里程碑来说还是有很大影响的，因为一次拖延会导致次次拖延。马上进行团队内的“站立会议”，果断的进行一些产品特性的决策和确认，晚上加班赶进度。并且这一讨论还发现一个需求技术和产品人员有不同的理解…

进度控制永远是软件开发中最大的难题。对于互联网应用来说，时间、交付物、质量的重要程度依此递减。如何达到项目的既定产品目标保证一定的质量，并且一定要按时完成？

还有其他的一些 … …

… …

办公室只剩下了我自己。写完这些文字，下班。明天还要早起。

弄了点凉菜和小吃，还有一瓶HY家的白酒，五个人边喝边聊。从晚上6点聊到11点半，一个宿舍的仨人总是有说不完的话扯不完的蛋。一个人一句，把2000年一直到2011年，18岁一直到29岁，从上大学至今的11年经历完整的回忆了一遍。

大学里，HY的篮球队员转篮球裁判。ZH在学生会听到的学校内的各种八卦和传说。猴子创新的偷电方式。寝室间通宵的星级争霸对战。宿舍楼内的砍人。学校边上吃饭的大坑。罢饭。以及当我们离校时摔啤酒瓶，砸玻璃… …

传奇的人和事，构成了彪悍的大学生活。西北民风彪悍，就是这样。

在和谐和维稳前提下的党国是否缺少了阳刚之气？

接着就说到了毕业后，ZH第一个来到北京住地下室，找了第一份工作。

HY考研失利后于2005年正月十四来到北京和ZH合住一间10平米不到的没有窗户的小房间。

我出国失败后2005年四月七日来到北京，投奔ZH和HY，他俩为了我的到来，在本地大学同班同学L的帮助下新租了一个清河的两居。狗B的事总是发生在我们身上，在换房子的时还被前2房东讹了一把…

这个位于清河砂轮厂宿舍的顶楼。没有床，只能睡沙发。无空调且位于顶楼导致到夏天奇热无比，且毗邻八达岭高速而无法开窗。还有用尽办法也灭不完的小强…

吃也是永恒的话题，一开始的拮据，在楼下那个小新疆馆子里吃拉面是四元还是五元的成为了一个“哲学问题”。到后来每周一次在此的大盘鸡。再后来每周一次的二里庄小肥羊，最后闻到小肥羊的味道就想吐…

数次晚上9点钟以后三人从天安门走到西单，再从西单走到新街口二环。以及ZH著名的“720自行车”。

等等等等… …

从迷惑、踉跄到现在。十一年弹指一挥间。

到了现在我们已经不会为“四元还是五元的哲学问题”伤脑筋，都在北京定居了下来，跨过了最坚难的北漂岁月。

我相信：对任何勤奋努力的人来说没有失败，只是暂时的不可以，上帝也会打盹。

有了这样的经历，一个新的城市，我们也一样能从零开始。

多看几本书，多看几个人，多经历几件事，多挣几块钱，只求到垂垂老矣写最后一篇日记的时候，问心无愧。

到最后恭喜HY和YLQ夫妇新婚大吉。

祝愿ZH夫妇早日在北京安家。

2011年10月30日凌晨1点写下了上面的文字，晚安。

一名优秀工程师的艺术人生就此谢幕，他的产品改变了世界，他的思想影响了我们这代人。

他的产品艺术和技术的完美结合。

他向世人证明了如何用艺术和技术去创造一家公司，改变人们的生活，改变世界。

他向我们诠释了什么是执着创新、理想主义、追求完美、特立独行。

希望未来有更多的人能像乔帮主一样，这样我们会更精彩。

借用乔帮主的名言自勉：“Keep looking, and don’t settle. stay hungry, stay foolish.”

借用今天苹果的主页来悼念乔帮主：

PC硬件结构近5年的最大变化是多核CPU在PC上的普及，多核最常用的SMP微架构：

1. 多个CPU之间是平等的，无主从关系（对比IBM Cell）；
2. 多个CPU平等的访问系统内存，也就是说内存是统一结构、统一寻址的（UMA，Uniform Memory Architecture）;
3. CPU到CPU的访问必须通过系统总线。

结构如图所示：

SMP的问题主要在CPU和内存之间的通信延迟较大、通信带宽受限于系统总线带宽，同时总线带宽会成为整个系统的瓶颈。

由此应运而生了NUMA架构：

NUMA（Non-Uniform Memory Access）是起源于AMD Opteron的微架构，同时被Intel Nehalem采用（英特尔志强E5500以上的CPU和桌面的i3、i5、i7均基于此架构）。这也应该是继AMD64后AMD对CPU架构的又一项重要改进。

在这个架构中，每个处理器有其可以直接访问其自身的“本地”内存池，使CPU和这块儿内存之间拥有更小的延迟和更大的带宽。而且整个内存仍然可做为一个整体，可以接受来自任何CPU的访问。简言之就是CPU访问自己领地内的内存延迟最小独占带宽，访问其他的内存区域稍慢并且共享带宽。

GNU/Linux如何管理NUMA：

1. probe硬件，了解物理CPU数量，内存大小等；
2. 根据物理CPU的数量（不是core）分配node，一个物理CPU对应一个node；
3. 把属于一个node的内存模块和其node相联系；
4. 测试各个CPU到各个内存区域的通信延迟；

在一台16GB内存，双Xeon E5620 CPU Dell R710用numactl得到以下信息:

• 第一列node0和node1就是对应物理CPU0和CPU1；
• size就是指在此节点NUMA分配的内存总数；
• free是指此节点NUMA的内存空闲数量；
• node distances就是指node到各个内存节点之间的距离，默认情况10是指本地内存，21是指跨区域访问。

因为就近内存访问的快速性，所以默认情况下一个CPU只访问其所属区域的内存空间。此时造成的问题是在大内存占用的一些应用时会有CPU近线内存不够的情况，可以使用如下方式把CPU对内存区域的访问变为round robin方式。此时需要通过以下方式修改：

# numactl --interleave=all

memcached、redis、monodb等应该做以上的优化修改。

另外，如果有时间，下一篇会总结一下自己对于此问题的思考：如果自己实现一个内存池，并发挥NUMA架构的最大效能，如何设计？

参考自：

http://en.wikipedia.org/wiki/Non-Uniform_Memory_Access

Ulrich Drepper, Memory part 4: NUMA support http://lwn.net/Articles/254445/

http://www.kernel.org/doc/Documentation/sysctl/vm.txt

行程：10号14点到达青海西站后，立即找去西海镇的长途车赶到西海镇，并找地方住宿并装车调整车子。

有两套环湖方案：
第一套：
第一天 11号 西海——- 江西沟乡 途径 金沙湾 湖东羊场 151基地（98公里左右）
第二天 12号 江西沟乡——–鸟岛 途径 江西沟 黑马河 石乃亥 鸟岛 （100公里左右）
第三天 13号 鸟岛—-刚察 途径 鸟岛 布哈河 刚察 （63.4公里左右）
第四天 14号 刚察—-西海 途径 刚察 哈尔盖 甘子河 西海（87公里左右）

第二套：
第一天 11号 西海——-黑马河乡 151 途径 金沙湾 湖东羊场 （144公里左右）
第二天 12号 黑马河乡—-刚察 途径 鸟岛 布哈河 刚察 （116公里左右）
第三天 13号 刚察—-西海 途径 刚察 哈尔盖 甘子河 西海（87公里左右）

物品准备完毕：

车辆准备完毕：

环青海湖主要城镇景点距离：

西海镇 - 青海湖乡 16千米
青海湖乡 - 湖东种羊场 26千米
湖东种羊场 - 青海湖渔场 24千米
青海湖渔场- 151基地青海湖草原宾馆 17千米
151基地青海湖草原宾馆 - 江西沟乡 21千米
江西沟 - 黑马河乡 48千米
黑马河 - 鸟岛 53千米
鸟岛 - 泉吉乡 38千米
泉吉乡 - 刚察 26千米
刚察 - 哈尔盖 29千米
哈尔盖 - 甘子河乡 16千米
甘子河乡 - 西海镇 43千米

上一个在网上找到的环青海湖的图片路书：

试图从四个方面聊聊MMORPG的软件架构，：

• 整体构架
• 服务器端架构
• 3D引擎
• 游戏逻辑

要说的东西很多，其中也有很多不是我所擅长的，尽力而为吧。

设想一个简单的需求：

1. 把其他编码的视频转换为指定码率的H.264；
2. 在转换过程中做一些简单的处理（例如增删水印、字幕的处理、声音的处理等）；
3. 需要封装成指定的一种container格式，比如mp4或mkv。

ffmpeg完成此项工作的大概过程是：

1. 识别文件格式，打开视频文件容器，得到video_stream；
2. 使用libavcodec把video_stream解码成原始的frame数据；
3. 在frame的基础上做“需求2”的处理；
4. 编码成H.264格式；
5. 存放到指定格式的容器中（mp4或者mkv）。

“过程1”应该是一个轻量操作，且对于现有视频格式速度应该很快（播放器看片的时候不可能先等上几秒分析一把格式再开始播放吧？）。

“过程2”需要把原有的视频编码解码并转为ffmpeg内部使用的格式，速度会比上第一步慢不少，但是应该也是可以接受的。当然在码率比较高的情况下也会非常缓慢（在Pentium4时代的机器上看1080p的高清视频很卡）。

“过程3”是需要对每一帧进行处理，那么这步是可高度并行化的应该可以放到GPU进行。

“过程4”一定是最慢的一个环节：H.264需要将图像分割成很多个宏块, 然后利用视频帧图像的帧内和帧间的相关性, 采用帧内预测或帧间预测的编码模式, 对各个宏块进行压缩。然后形成帧，组成为码流。整个过程复杂，但宏块儿的处理是可以高度并行化的操作，应该可以放到GPU进行。

“过程5”和“过程1”类似。

所以如果想用GPU加速以上的过程，那么把“过程4”和“过程2”的密集计算从CPU上转到GPU上，应该是可能的发力点。

如果要设计这个系统，软件自底层到上层有几点需要考虑：

1. 如果显卡可以指定，应该是Nvidia。在Linux下有完善的开发运行环境，且同时支持CUDA和OpenCL；
2. 如果选定Nvidia显卡，那么根据前文的分析，使用CUDA是更好的GPU计算架构。并且应该使用最新的CUDA 4.0版本，因为在多GPU上能更方便的开发，并且GPU直接访问内存方面也做出了改进（CUDA 4.0的新特性详细见这里）。
3. 在决定了以上基础设施后，为了提高单机的处理能力程序应该用何种架构来编写？单进程多线程还是多进程单线程？

关键在于在程序里如何更好的调用CUDA：

1. 单进程多线程方式
   • 每个线程进行一个视频的转换，每个线程在其线程内部直接使用CUDA；
   • 有单独的CUDA线程，其他线程当需要时通知此线程进行运算；
2. 多进程单线程
   • 每个进程进行一个视频的转换，在其进程内部各自独立的使用CUDA；
   • 有单独的GPU进程，其他进程当需要进行GPU运算的时IPC通知此进程进行；

在我看来，2-1的方式是最简单直接的，可以直接基于ffmpeg来实现，只需单把可并行化的部分从CPU移到GPU。但是CUDA 4.0是否支持这样做？这样做效率是否最高？

硬件配置上也有以下的问题：

1. 是否需要在一个Server上配置多块儿GPU？虽说CUDA 4.0已经声称对此有很好的支持，但是其是否能利用好？另外受限于硬件瓶颈的一些限制（CPU计算能力、内存速度、总线速度），配置几块儿GPU比较合适？
2. 如果使用ffmpeg，那么在一台拥有16核的服务器上，理论可以同时启动16个ffmpeg进程（单线程运行）。加入GPU运算后单个视频处理速度的提高是一定的，但是否还有这么大的并行能力？以及单位时间段内的处理能力是否提升？
3. 加入GPU后硬件成本的增加是否值得？与单独使用CPU的相比单位成本是否更低？选用哪款Nvidia显卡的性价比最高？
4. 如何看GPU的load average和top？

最后这件事情最难的一点在于：需要对CUDA、ffmpeg、H.264、硬件都有相当深入的了解才能做好这样的一个系统。