最近时间线上又起了一场不大不小的论战，做互联网的人觉得游戏服务端发展很慢，同时互联网技术日新月异，似乎觉得互联网技术领先了游戏后端技术十年，这个结论显然是武断的，几位朋友也已经驳斥的很充分了，游戏服务端的同学实属没必要和这个互联网的人一般见识，本来就此打住也还挺好。
但最近两天事情似乎正在悄悄起变化，时间线上一直看到不停的有人跳出来，清一色的全在说互联网简单，什么做个电商不过就是 CRUD 的话也出来了，看的我也大跌眼镜，过犹不及吧。
今天更是又刷到有几位不管不顾就说什么游戏服务端领先互联网十年什么的，似乎这又要成为了另外一个极端了，那么有几点情况是不是也请正视一下：
1）游戏服务端足够复杂，但是发展太慢，祖传代码修修补补跑个十多年的不要太多。能用固然是好事，但没有新观念的引入，导致可用性和开发效率一直没有太多提升。
2）各自闭门造车，没有形成行业标准与合力，这个项目的代码，很难在另一个项目共享，相互之间缺少支持和协同。
3）互联网后端随便拎出一个服务来（包括各种 C/C++ 基建）大概率都没有游戏服务端复杂，但最近十年日新月异，形成了很强的互相组合互相增强的态势。
我上面指的是互联网基建项目，不是互联网 CRUD，互联网近十年的发展，让其整体可用性，效能，开发效率，都上了很多个台阶，不应一味忽视。
如果继续觉得游戏服务端领先互联网十年可以直接右转了，开放心态的话我也可以多聊一些（点击下方 more 阅读更多）：
Read more…
如果要随便学学，便于日后使用那花两个星期买本书，配合网上文章就行了。
如果你想自己动手改 x264，为其添加一些你想要的东西，那么下面步骤你得耐心走完：
1: JPEG编码不但要学，还要自己实现，这是图像编码的基础，理解下yuv, dct, 量化，熵编码（不用参考 libjpeg，太庞大，建议参考 tinyjpeg.c，单文件）
2: MPEG2编码要学，现代编码器都是 block based 的，而 block based编码器的祖先就在MPEG2，理解下帧内编码，帧间预测，运动矢量，残差图等基础概念。具体代码可以看早期版本的 ffmpeg 的 avcodec，比如 mpeg12enc.c 代码也就1000多行，容易看，不过其中牵扯很多ffmpeg的内部数据结构，比如 picture, DCTELEM，各种 table，bitstream，vlc, swscale 等公共模块，缺点是文档少，优点是读了这些对你读其他 ffmpeg代码有帮助。
3: 自己实现一个类 MPEG2 编码器，最好自己从头实现个编码器，具体实现方式可以参考我的上面提到的 “视频编码技术简介”。
4: 参照 MPEG2的原理阅读 h.264的相关文章和书籍，了解和MPEG2的异同，比如先从intra入手，并且阅读 x264的早期版本代码，比如 2005年的版本，重点阅读 common 目录，基本的数据结构都在那里了，基本的图像，宏块，预测等都在那里了，阅读完以后阅读 encoder目录，了解程序的结构，2005版本的 x264是今天 x264的基础。
5: 阅读最新的 x264代码，并整理代码脉络，了解近年来引入的各种优化方法，然后 google, google, google …….
6: 愉快的修改 x264吧，比如增加搜索强度，修改预测范围，增加抗丢包特性，或者增加带内编码冗余，修改内部缓存策略，寻找降低编码延迟的方法，根据你的需求，修改，测试，修改，测试。。。。。。
7: 至于 MPEG4文件格式，可看可不看，一下午的事情。
参考阅读：
视频编码器原理简介
先前写过《视频编码原理简介》，有朋友问光代码和文字不太真切，能否补充几张图片，今天我们演示一下：
这是第一帧画面：P1（我们的参考帧）
这是第二帧画面：P2（需要编码的帧）
从视频中截取的两张间隔1-2秒的画面，和实际情况类似，下面我们参考P1进行几次运动搜索：
搜索演示1：搜索P2中车辆的车牌在P1中最接近的位置（上图P1，下图P2）
这是一个演示程序，鼠标选中P2上任意16×16的Block，即可搜索出P1上的 BestMatch 宏块。虽然车辆在运动，从远到近，但是依然找到了最接近的宏块坐标。
（点击 more 阅读剩下内容）
Read more…
要彻底理解视频编码原理，看书都是虚的，需要实际动手，实现一个简单的视频编码器：
知识准备：基本图像处理知识，信号的时域和频域问题，熟练掌握傅立叶正反变换，一维、二维傅立叶变换，以及其变种，dct变换，快速dct变换。
来自知乎问题：http://www.zhihu.com/question/22567173/answer/73610451
第一步：实现有损图像压缩和解压
参考 JPEG原理，将 RGB->YUV，然后 Y/U/V 看成三张不同的图片，将其中一张图片分为 8×8的 block进行 dct变换（可以直接进行二维 dct变换，或者按一定顺序将 8×8的二维数组整理成一个64字节的一维数组），还是得到一个 8×8的整数频率数据。于是表示图像大轮廓的低频信号（人眼敏感的信号）集中在 8×8的左上角；表示图像细节的高频信号集中在右下角。
接着将其量化，所谓量化，就是信号采样的步长，8×8的整数频率数据块，每个数据都要除以对应位置的步长，左上角相对重要的低频信号步长是 1，也就是说 0-255，是多少就是多少。而右下角是不太重要的高频信号，比如步长取 10，那么这些位置的数据都要 /10，实际解码的时候再将他们 x10恢复出来，这样经过编码的时候 /10 和解码的时候 x10，那么步长为 10的信号1, 13, 25, 37就会变成规矩的：0, 10, 20, 30, 对小于步长 10的部分我们直接丢弃了，因为高频不太重要。
经过量化以后，8×8 的数据块左上角的数据由于步长小，都是比较离散的，而靠近右下角的高频数据，都比较统一，或者是一串0，因此图像大量的细节被我们丢弃了，这时候，我们用无损压缩方式，比如 lzma2算法（jpeg是 rle + huffman）将这 64个 byte压缩起来，由于后面高频数据步长大，做了除法以后，这些值都比较小，而且比较靠近，甚至右下部分都是一串0，十分便于压缩。
JPEG 图像有个问题就是低码率时 block边界比较严重，现代图片压缩技术往往要配合一些 de-block算法，比如最简单的就是边界部分几个像素点和周围插值模糊一下。
做到这里我们实现了一个同 jpeg类似的静态图片有损压缩算法。在视频里面用来保存I帧数据。
第二步：实现宏块误差计算
视频由连续的若干图像帧组成，分为 I帧，P帧，所谓I帧，就是不依赖就可以独立解码的视频图像帧，而 P帧则需要依赖前面已解码的视频帧，配合一定数据才能生成出来。所以视频中 I帧往往都比较大，而P帧比较小，如果播放器一开始收到了 P帧那么是无法播放的，只有收到下一个I帧才能开始播放。I帧多了视频就变大，I帧少了，数据量是小了，但视频受到丢包或者数据错误的影响却又会更严重。
Read more…
Recent Comments