AlphonseTai's Blog

从小到大，我都比较排斥文字类工作（写文档、写文章）。最直接的原因就是觉得麻烦，自己写的东西别人看不懂，还要反反复复的修改；有时自己回头去看看也不一定能看懂。

凡事必有因，又因必有果。显然直接的原因也只是其他一些原因综合以后产生的另一个结果罢了，所以就要回过头去看看小时候，来寻找一下原因。目前找到的原因大约有几个：

 

1，启蒙教育没做好

2，读书时候没有认真学，导致不会写文章

3，性格

4，后续也没有对这类事情很在意

5，成长或工作的环境也没有这方面的机会，得不到相应的锻炼

 

接下来我就细细数落一下我自己！

— 启蒙教育没做好 —

在我读小学那个年代，我们还流行要读学前班。记得学前班主要是学讲话、识数、识符号。

由于出生日期和相应规定的计算方法的问题，所以我没有上学前班的机会，且家里也没有重视这个问题，所以我也就没有读学前班。

直到7岁的时候，才能送去读一年级。并且当时读书都是很难的一件事情（6年义务教育，教育经费也很紧张），七说八说终于学校放我进去读书了。

一年时，我的班主任是语文老师，而这位语文老师中专刚毕业（当时的中专含金量和现在的本科差不多）。计算一下么，大家就都很清楚了，这位班主任也和我一样其实都是小孩。

小孩教小孩，在我们那个年代是很常见，也是正常的事情。但问题不在这，问题的原因在于小孩的心智不成熟，而且当时教育体系里面没有对老师做足应该的心理教育和培训。

所以么，我就被歧视了！由于不会写汉语拼音，学习的时候又有点心不在焉。老师不耐烦了，就直接喷我：“这么笨，要么退学算了！”而且还留我下来叫家长，还是义正言辞的和我老妈说：“你家的小孩太笨了，而且还心不在焉，我教不来了，要么退学好了！”

然后就这么一次，我心里就烙下了阴影；虽然人在课堂上，但内心非常抵制语文课。好在我老妈放学接我回家的路上，会用它蹩脚的普通话教我。这么些年就勉勉强强熬过来了（小学期间），同时我也对这位语文老师以及她这次的行为形成了很深的记忆和影响（其实都是负面的）。

 

— 读书时候没有认真学，导致不会写文章 —

小学么，就不多说了；肯定不会好好学，况且小学我还住过2年的院。

到了初中和高中，我也没打算好好学。初中高中期间，我连最简单的记叙文都不会写，但由于两位负责人的语文老师，所以我的作文水平勉强回到了及格线。

不过我也是让老师头疼的那类人，因为怎么教我都不想认真去学，只打算勉勉强强就行，更何况勉勉强强是个什么样子的水平，我自己都不知道。

 

— 性格 —

性格上的惰性，以及对困难的回避特征。导致我每次满怀期望的写完作文以后，被老师以给个友情分的方式打回来时，心中受到了一万点暴击伤害。渐渐的也就形成了回避和懒惰的心理特征。

因此在中学时代，我基本是排斥各种语文类读物的。换句话说，当年风靡一时的两个同龄阶段的作家的书，我基本没看过。。。。。。

直到后来快要高考的时候，我觉得要靠自己的双手改变自己时，我才去看了一个印着清华的某本语文类读物（好像是高个子那个人写的）

 

— 后续也没有对这类事情很在意 —

在我的脑海里：“按理说，到了大学应该没有语文课了吧”。结果进入大学。。。。。。。还是有语文课。

不过大学里的语文课不同于以往，一般是名著赏析和读后感，也没有太多要求。

当时心里的想法也很简单：“哥是工科类，不会写文章也没事！”

然后关于语文类方面的能力和锻炼四年就这样过来了。。。。。

 

— 成长或工作的环境也没有这方面的机会，得不到相应的锻炼 —

这个就不需要解释了，没啥好解释的。

 

 

不过值得庆幸的是，通过一些技术类文档，和一些论坛的瞎转悠，以及受到一些大文豪的熏陶。虽然不会写文章，但至少学会了讲人话了。。。。。

好像从vs2010开始，vs自带的max宏就不再被推荐为C++中使用的首选，而是尽可能的改为std::max这个模板函数。

在effective c++中也讲到了max宏和std::max之间的差别（但有时使用起来，还是不如max宏来的方便，尤其是当max的入参不是同一个类型时。）

 

好了，说正事。

在vs2010中，std::max被定义为一个模板函数，其中函数的参数类型推导主要依赖于第一个参数；且std::max被inline修饰。在vs中，inline的强度并没有forceinline那么强，因此编译时，编译器即可能会让模板函数展开，也有可能不会让模板函数展开。

有时候有些开源项目中，大量的使用了std::max，这也会进一步的导致编译速度减慢，编译出来的文件变大；这里面除了inline还有一定的原因和模板的特性有关。

为了解决这类问题，有事不得不做出一些折中或妥协。即，当杜写一个公共函数，在该函数中将std::max进行特例化，以此来达到优化编译的目的。假设在不调整诸如fpo之类的优化参数时，编译器都会一定只会将std::max进行仅有的有限次实例化，且也可以控制函数是否进行inline。编译时不仅加快了编译速度，同时也减小了编译输出文件的大小。

所以在一些实际项目中，如果对编译产出的要求比较高，有时不得不牺牲代码设计和可阅读性来达到目的。

最近由于项目需要，需要做一个能够自动化阅客观题的东西，则答题方式为纸质答题卡。通过扫描仪或者其他方式，将图像拾取并转换成数字图像。

当然，我本身是拒绝的。实际上，在这一过程中，比较难几点有：

1，拾取后的图像如何做预处理、降噪、灰度化、二值化等问题

2，如何对图像进行抽象（识别）

 

好在目前关于纯粹识别的技术还是有的，所以就假定一个前提；即用户采集转变成的数字图像是噪点较少，且容易做灰度化和二值化的。

于是，在网上找到的一张某地区高考使用的答题卡（下图）。并对该答题卡做一个简单的分析。

 

 

对该答题卡观察以后，发现答题卡顶部的黑块很可能被用作类似位置同步和校准用。于是得到了下列可能的结论：

1，有1和2字体的两个黑柱子，可能是用于某种标记（或者答题卡传输轨道同步）。

2，其他的小柱子之间的间距是分组，且不等距的。

3，通过结论1和2可得知，有可能能通过这些黑块生成答题卡坐标系，以此来进行图像变换或区域间的距离计算等。

 

通过以上的几个结论可以的出，实际上高考中使用的答题卡在进行识别（或批改）时，除了要找到学生涂黑的选项意外，还需要进一步的判断选项的有效、无效、未作答情况。看来判断答案的有效情况也将会是一个重点和难点。

最近在看webrtc的最新分支代码，和手里正在跑的代码做了简单的比较以后，顿时发现我已掉入深坑。。。。。

 

我们手里目前正在跑的webrtc代码是2014年最后一个稳定版本。且我们在这个代码上做了一定的修改和二次开发，同时移入了openh264（当时不知道谁决定的）。

现阶段，发现新版本的webrtc已经和手头的webrtc有着天然之别了，大致内容如下：

1，代码框架有所改变。尤其是设备管理，编解码器相关的代码布局

2，和h264编解码器相关的代码，有一个简单实现。即，直接调用ffmpeg中的编码器来实现。但同样支持openh264，只不过工作量会大一些。

3，使用了大量的c++11特性

4，对windows sdk的要求不同。

5，编译难度的增加。虽然gclient能够完成工程配置，但这也严重导致了工程要移动到另外一台电脑上将会是很难的一件事情（工程配置。。。。）。就算运行gclient runhooks，可能也会存在一些乱七八糟的问题。

 

接下来可能需要一点一点去看看openh264和x264到底有多大区别，并有区分的使用。