@googlefans

开源也得有人做一下。对外行来说一点也不懂，关注点也不在这上面。

@NonClockworkChen
@LeegoYih
@rekulas

谢谢

@Tumblr

邮件也算书面 offer 对吧？
我理解 offer 需要求职者确认的对吧？就是可以给我 offer 但是我不接受，不需要原因。
问题是接受 offer 之后，再反悔。就像你说的，这个岗位都关闭了，但是这个人却最终没到岗，白白浪费时间和精力。

@haah 这本书确实非常好，压缩领域的入门书籍。
各种算法的思路、基本原理、发展历史都很清晰，相当于这个领域的“地图”

@ipwx 有损发生在 DCT 变换之后数量化和去掉高频分量这一步。

即使不做数量化，不去掉高频分量，运动补偿和运动预测还是有用的，因为会让 P 帧表示的残差非常小。
压缩这一帧，相当于压缩一张几乎“全黑”的图片。还是会比压缩一张一般图片小一些的。

@systemcall

我知道效果会很差的。
不过还是值得试一下，我好奇。

@mxT52CRuqR6o5

> 就比如我需要拖拽进度条到中间位置，播放器需要快速获取到视频中间位置的帧数据
说的对，有道理。

@oldshensheep

> 楼主大概的意思是把 一捆图片 打个压缩包（固实压缩），然后就变成了视频吧。（大概）
逻辑上来讲，视频的确可以看成时间上离散的一系列图片。虽然在文件格式当中并不是这样的。

> 然后楼主认为，压缩程序应该能够提取出这些图片间的相似处，达到更高的压缩率。所以我们为什么不用压缩软件来压缩视频？
我这个问题的确是想问，是否存在某种通用压缩算法，绕过“帧”这种概念，直接去掉重复的部分。

@ipwx 这个回答非常有用，待我理解一下

@yangzzzzzzzt1 看错了，14 楼

@misdake

你说的对。问题就在于，那些压缩算法对文本都挺好的，对图片和视频就不行？道理是什么？

> 想要提高压缩比，允许有损压缩，就会有那些频率域上的操作和前后运动估算之类的方法。
我的理解是，引入运动预测等机制，即使无损也能一定程度上提高压缩比。所以并不仅仅是有损无损的问题。

@yangzzzzzzzt1

基本上每个人都会误解我的问题，请先看一下 18 楼。
若还是觉得槽点太多，欢迎一一吐之。

@xtreme1 感谢这个建议，这个路子非常中肯

@iamzuoxinyu 帧内压缩相当于单张图片压缩，单张图片压缩也比单纯的熵编码压缩复杂很多。

@nothingistrue
@litec

还有一个利用人类视觉效果的例子，就是颜色用 YUV 来表示，而不用 RGB 。对人眼差别不大，但大小或许会骤减。

@ipwx 图片视频指的就是图片和视频

@learningman
@lingxi27
@nothingistrue

h264 以及其它的视频编码的确用了熵编码，但那只是其中的一个步骤。

可能我没有说清楚，我想说的是，为什么不能只用熵编码这一个步骤。
比如我想压缩文本，一个简单的方法是，先统计字出现的频率，用 huffman 生成编码表，然后到原文中代换，出来的结果大小接近理论压缩极限。gzip 这种工具用的方法更 smart ，但是肯定不像视频那样，需要 motion estimation 等步骤。

@Maxzzz 你觉得 Y combinator 有没有必要搞懂。

原始论文里用 function 表达正整数，表达加减乘除。
很简单的概念，全都用函数构造，看起来都差不多，只有烧脑。
我相信 string (list of chars)、hash map 这种结构用函数也都能表示。
但是写程序的时候用不到这种“技能”。

领导不支持，但是你还得做
是什么逻辑
见识了

@lilihangzhou

@7gugu @keepeye @JDog @zxjunz

各位说的都是不做大改，尽量保证不影响之前的，在巧妙地加新代码。说说我的分析。
这样做，肯定会导致越来越改不动，越是后人日子就越难过；不做大改，终将拖死大家。
如果在拖死大家之前，项目就因为别的原因黄了，那不用做大改，都一样。
如果是因为改不动，迭代太慢或者 bug 百出而导致项目黄，那就要考虑做大改了。
如果是因为开始大改，然后把自己改死，项目黄了，那只能说大改做得太晚了。
都劝我不大改，因为各方面都过硬，能坚持到最后的项目太少了。久经考验的项目没几个。