温水煮青蛙 ≠ 煎熬

不知道从什么时候开始就逐渐习惯了焦虑馈使型的行为习惯。

我之所以将其称作“焦虑馈使型行为习惯”,是因为每次出现焦虑时,心态很容易出现急躁的情况,且同时会伴随着找各种方法去试图解决或缓解焦虑的持续;但焦虑逐渐减小或阶段性消失时,行为又会回到原先的行为轨迹中。

这样的行为具有很强的特点或特征,大致如下:

1,焦虑成因大部分都来自潜移默化的东西,形成过程时间较长。

2,有些焦虑实际上是患得患失引起。但又不甘心做出牺牲,认为牺牲最小的方案还可以努力努力(牺牲最小的方案有时候很难达成)。

3,焦虑再焦虑,本来是一个很细微的焦虑,但由于转牛角尖,或者在考虑问题时,对部分问题点(矛盾点)过于在意,导致新的焦虑出现,最终形成了滚雪球效应。

4,对现状不满。性格和心态不容易让人安于现状,喜欢登山式前进;但对风险又过于焦虑和回避,容易陷入自我矛盾。

反观,看各种类型不同的人。这种焦虑的习惯性形成,大致根本原因两个:性格和环境

由于性格有优柔寡断和过于激进的特点,因此在做事情的时候,容易多虑,也容易过于激进;两种相反具有冲突性的性格特征混合在一起,若是不能找到一个合理的平衡点,很容易出现眼前的情况。

环境,由于所处的环境一直都处于温水煮青蛙的情况。再和他人做比较的时候,容易出现心理落差。心理落差容易带来某种程度的心理失衡,但这种失衡又是对整个事情的认知不足带来的,即,见的世面很少,无法区分真正意义的好与坏(优与劣)。

同时对自身要求“过分的高”(对自身的要求容易超出自身能力或实际情况太多)。

有时候温水煮青蛙未必是坏事,或许给了思考和缓和的余地。利用现有的资源,好好对自身做一个较为全面或完整的反思,对以后有着很好的帮助。但如果把温水煮青蛙随意等用于煎熬,那么反而浪费自己拥有别人不未必拥有的:“平静和时间”。

切勿心浮气躁,还是要继续加强自身心理控制和调节的建设。

如果回去就要接受羊中无狼

进入社会这么几年下来,我发现越是信息沟通渠道不畅,或沟通减少的情况较为严重时,人普遍的认知问题就更严重。

体现在对自我的认知和对外界的认知上,简单的说容易形成片面理解和过度看高自己。因为有回老家的想法,所以稍微留意了老家那边的IT群,有极少几个群给我感觉非常闭塞,甚至加个群都要搞个神奇的问题验证。即便如此,似乎加群可能还有着一些条件,被拒了几次之后就此作罢,不加了。

同时我也在留意或参与到已加群的一些聊天中,普遍给人感受技术氛围相对弱很多,大家更多关注的是一些装备或设备上的事情。当然也偶尔有几个较为确实厉害的人会说几句正经事情,与此相对的也是有几个典型的会出来不懂装懂的胡乱说一通。

不记得啥时候听到过这么一个说法,羊群中放一头狼,虽然会有羊群被吃完的风险,但养出来的羊个个都比普通散养方式的能跑。

竞争机制要合理引入,但绝非是打着引入竞争而故意制造不平等。老家的IT环境,我看到了相比离家时的成长,但也看到了各种不平等依然的存在,本位主义思想的盛行。以及心胸狭隘的普遍。

先入为主的行为习惯普遍,或多或少也和一个人的见识有着很大的关联。见的多了就更为理解可能性的含义。

面临着有回老家的打算,就必须要接受老家的那种闭塞习俗,也要做好心理落差的准备。事事难料!

好久没有写反思文,即“没有时间”写,也不知道该如何写起。随着年纪增长,想法越来越复杂,而很多心中的矛盾往往也都是由眼前的一些现实问题所致。

何为家?小时候觉得有父母的地方就是家。

长大后,闹独立了;认为自己能够赚钱养活自己,随便租个地方住着就是家。

工作些许年后,觉得拥有自己的房产才是家。再隔几年,觉得步入婚姻才是家。

就眼前来说,我还没步入婚姻,但家在我心中的概念似乎又发生了变化:除了步入婚姻,还有父母才是家。

找对象过程中的各种挫败,以及在外打拼的这几年里对冷漠人性的失望,以及物质为上,功利为主的社会情况;不免让我我时常在反思:“我是不是该改变一下自己了?”久而久之慢慢的也对“外面的世界”产生的一种反感和厌恶之情。

今年是自离开老家后第13个年头的第13次回家过年,回到那个曾经令我反感又厌烦的家。回来以后看到的是长辈们矛盾的淡化,也渐渐的发现父辈们老了,偶然间发现老家生活节奏的舒适和浓郁的人情味。只要是未经世俗过分熏陶的人,你总能在他的身上感受到一种自然的纯朴。

小时候,我就不喜欢刻板和过于复杂迂回的事情;早在几年前,我其实就已经厌倦了复杂的派系人际关系。我向往自由自在,想工作就工作,想出去游玩就游玩的生活。回到老家,老家适宜的生活,让我猛然和自己的向往的人生目标联想到一起,顿时看到了希望一样,因此也就有了“回老家”的想法。

随着年假结束的来临,心态也越来越复杂。

若是回老家,我不得不在老家找个工作维持生计,但老家的就业机会失衡的令人感到可怕。若不回老家,我的心依然在飘。尽管现实如此,但事实上在“是否回老家”问题上犹豫不决的真实原因并非完全如此。

我怕我放下现在所有的积累,回到老家时,我突然“腻”了怎么办?我害怕到时候没有了“后路”,没有了第二个选择。我也不想一辈子碌碌无为或无所事事。

我怕我如果坚持将现在的路走下去看不到结果怎么办?如果在这样继续下去,接下来会发生什么?我到时候是否会后悔当初坚持走下去?

“回不去的家”,我想这句话表达的并非物理含义上的家,而是“心的归宿”。心态上的不稳定,以及面对很多现实问题时,大家处理起来越缺乏人情味的做法,物质至上目标令人极其反感,有时候做选择真的很难,任何选择都有牺牲,而且牺牲都还不小。虽然跟着心做选择是大多数文学著作或过来人的经验,但有时候人的内心又极其容易受蒙蔽。

家,很难!

【webrtc、gclient】cpid更新失败代理新的配置方案

首先按照原先的配置方案如下:

1. 设置http_proxy和https_proxy环境变量

2. 设置winhttp代理

3. 配置git代理

但在执行gclient自身更新时,总是发现cipd更新失败。简单跟踪了一下cpid,发现cpid的更新有两种,第一种是cpid自身自动更新,另一种是通过执行bootstrap来更新cpid。
cpid是使用go写的,虽然网上一堆教程说配置了http_proxy之后就可以等等,但这其中cpid存在一个问题,即在进行https请求时,会对证书做校验,若https_proxy配置的代理是一个https真实代理服务器,那么cpid做校验时会失败,具体未看代码,估计webdav执行过程中需要用到https中的证书做登录校验。

至于对cipd的更新处理方式为:

因此将https_proxy有意配置成http服务器,即可破。这会让cipd自更新时强制通过ensure方式进行更新

同时在其他一些脚本执行时,似乎用到了类似原先的csript,因此最好在ie代理时也配上相应的代理服务器地址。这样就可以正常更新gclient了。

【ios、x264】将静态库打包成动态库,链接时的text relocations错误

最近在ios上出现将多个sdk放到一个app时,有各种开源静态库冲突的问题;于是考虑将自己用到的库进行打包成动态库版本,以此解决冲突问题。

在进行打包成动态库时,发现x264问题最大。打包出来的库在链接期出现text relocations错误,网上找了以后发现基本都是进行忽略这个错误,事实上这个错误忽略了没用,app启动时还是会出现相应的crash。

换了几个版本的xcode进行测试,发现x264编译会出现不同情况的告警和错误,根据底部罗列的参考文章,估计xcode的编译器可能也有一些bug。

后来模仿android上的编译方式,在x264里加入了–enable-pic和–disable-asm顺利编译通过,但由于osx和xcode版本的因素,模拟器上的并没有编译出来,仅仅编译了armv7和arm64。

 

参考文章:

MacOSX下编译linphone(text-relocation错误说明)

libxxx.so- text relocations问题的终极解决方案(android)

Linker error when using incremental builds on iPhone

Android Gradle编译so库或运行时出现 text relocations 崩溃的正确解决方法

【设计模式】对代理模式的几点理解-

设计模式一直给我的感觉都是天书一样,一方面理解起来困难。另一方面书上的解释也较为枯燥,况且现在也还有很多号称设计模式大神的出现,也可能间接的让大家对同一个模式有了各种千奇百怪的理解。

设计模式这个东西出现初衷本来就是解决工程问题,而在解决工程问题时,每个人的角度不同,观点也就不同,并且在《head frist 设计模式》中,作者也强调过,没有任何一种模式的选择和使用是正确或者错误的,只有适合与否。同时对设计模式理解有偏差,甚至初学者也才会去讨论某某模式好,某某模式如何。对设计模式理解较为全面,工程经验较为丰富的人,只会说某种模式用起来较为自然。

代理模式可以的重点可以看作主要是屏蔽了实现细节,同时也对任务执行做了一个中转。让两个模块之间进行解耦。

例如一个消息队列的实现,对于消息队列来说,实现可复杂可简单。为了让消息队列的使用者能够更清晰的了解如何使用,首先需要对消息队列的一些内置方法进行屏蔽,在C++中,继承是无法做到这一点的,所以只能通过包装的方式来实现。

因此就产生了代理类来将消息队列的实现类进行包装,让消息队列的使用者更加关注与如何使用,让消息队列的实现者来关注如何实现,而对于代理来说,仅仅需要关注如何流转数据和流程即可。

【C++11,自动变量,迭代】c++11下不同for循环的差别

先看如下代码片段

#include <vecotr>
#include <string>

#include "boost/algorithm/string/split.hpp"
#include "boost/algorithm/string/classification.hpp"
#include "boost/algorithm/string.hpp"

std::vector vStrArray; //里面存着一堆字符串,其中有一个字符串是这样的: " a.kbasdasdsad"

for (auto a : vector)
{
  boost::trim(a);
}
#include
#include

#include "boost/algorithm/string/split.hpp"
#include "boost/algorithm/string/classification.hpp"
#include "boost/algorithm/string.hpp"

std::vector vStrArray; //里面存着一堆字符串,其中有一个字符串是这样的: " a.kbasdasdsad"

for (std::vector::iterator a = vector.begin();
     a != vector.end();
     ++a)
{
  boost::trim(*a);
}

编译环境是vs 2015 update 3
分别执行完以后会发现,A代码片段没有任何变化,B代码片段的” a.kbasdasdsad”变成了”a.kbasdasdsad”。

单步的时候发现,a变量在A代码片段中,实际上是已经对被修改了。后来网上查了几篇资料,怎么也没有找到对auto的详细说明。加上c++ 11每个编译器实现可能存在一定的差异,因此只能认为,在auto修饰的for循环里,变量使用了写时复用的方式来处理。
如果要对vector里面的值进行修改,还是只能使用最原始的迭代器方法。

【h264、baseline、flv】使用baseline做双向强交互直播不利的几点因素

再说baseline做强交互不利因素之前,先说说现在直播的场景情况。

 

场景如上图,推流段不是移动平台,就是PC机。当然最近几年也出现专门用来推流的定制盒子,本质不是一个嵌入式windows,就是一个android设备(android设备较多)。

  • 而对于PC机作为推流端来说其实问题并不大,只要在保证带宽足够理想的情况下,采用264的任何一种profile都能尽可能的做到最大延时接近编码器固有延时的效果。同样对于使用何种容器来说问题都不大。

 

  • 但对于移动设备来说,需要匹配的情景就很多了,主要是由于移动设备的电池续航能力、操作系统小类别太多、整体性能表现。在使用264编解码时,一般尽量采用硬编解码,对于实在没有办法的情况下才使用软编解码。就仅仅一个硬编解码上就存在诸多差异,例如有些profile硬件不支持,或者rom上存在一些问题导致本该支持的profile,支持的不好或者根本不支持。

 

  • 除了上述提到的问题以外,其实还有一个隐形问题,那就是用户使用习惯问题。现在的用户越来越偏向于使用web方式展现的产品,一方面对于开发者来说,界面改动较为简单灵活,另一方面对于用户来说,只需要打开浏览器即可,简化使用步骤。

然而上述提到的这些问题,就造就了可能大家会想到flash、h5和native应用,对于native应用来说还好,开发起来虽然周期长,但可塑性比较强。对于flash和h5来说可选择余地就非常小了。

暂时不说flash和h5本身在做双向强交互直播是否可行,先说一说两者采用的协议类型。对于flash来说:

  • 通讯协议为rtmp系列协议(包括rtmpt等),协议本身并不是太复杂,但涉及当初并不是用来做双向强交互的直播协议,因此协议本身就没有在双向强交互上做太多的考虑。

 

  • 由于协议本身所承载的流媒体容器格式为flv或f4v,现在大部分直播平台基本采用的是flv作为容器,同时flv也是一种较为简单易用的容器

 

  • 但由于flv容器格式的限制,在adobe官方手册中就已经说明,flv容器支持的264的profile范围中,目前仅对baseline、extended、main、high、high10、high4:2:2、high4:4:4,在经过简单测试之后,如果不考虑flash端推流的情况下,用户电脑(移动端一般用h5,不用flash)性能具备一定保证的情况下,再根据官方手册并测试(as3手册),没有实际去测试过high10,不过脑补得知high10也是可以的,但延时太大,也有可能会引起其他flash异常。因此往往最佳的选择就在baseline、main、high中选择,因为他们的颜色编码是8bit的。从解码效率和广泛性来说,这三种都可以。

 

  • 但由于是双向直播,因此,在这时就需要考虑编解码器的时延问题。这时,大家一贯的做法就是关闭B帧编码,这样即可极大的提高编解码延时。当关闭了B帧编码之后,剩下几种profile互相比拼的就是在给定的一个平均分辨率、gop的情况下,编解码固有时延和数据码率,以及支持的广泛性。实测之后发现high其实在不同浏览器的flash上表现存在一定差异,主要情形为编解码速度、性能开销等等。因此在flash上使用high这种方式时,还需要综合考虑。

 

接下来说一说h5方式的直播:

  • h5方式的直播一般是通过websocket进行通讯,协议是hls,容器格式为ts、ps。然而我对hls和ts、ps都不是很了解。

 

  • h5支持还有待进一步推广,目前在较新的chrome系浏览器和较新的firefox浏览器上均支持较好。IE系暂时较弱(我把edge理解成IE系)。

 

  • 就目前来说,从开发手机端开发难度,和各手机厂商的支持力度上,无论是webview app还是native app来说,hls+ps/ts也是较优选择。

 

  • 通过看了苹果官方的FAQ得知,hls协议似乎仅仅支持baseline、main、high三种,不清楚是由于ts、ps容器特性导致的,还是hls协议特点。因此在决定使用哪一种profile时,又回到了和flash一样的情况下。

 

通过以上可以得知,实际上在使用x264编码时,最终在profile的选择上基本就限制在了baseline、main、high三种。从算法复杂度上来上讲,baseline是最为简单,而high是较为最为复杂(主要是预测模型比前两者多不少)。

不过在实际工程应用中,我们还是做了一个比较脑残又没有办法的决定,那就是使用baseline。原因有二:

  1. 我们使用的编码库是openh264,早期版本的openh264宏块分割方式较小,也仅仅支持baseline,对main也只是仅限于试验阶段。
  2. 在同样的profile级别下,参数大致相同的情况下,openh264的编码时延比x264的utral模式下略高,但码率略低(未做定量测试,简单定性测试得到的结论)。编码完的数据解码出来的视觉感受差别不大,反正都是渣画质。

考虑到使用场景和当时网络的大环境,确实选择openh264,即是无奈的选择,也是一个极其脑残的选择。说无奈主要是现实,说脑残是因为压根就没有做过定性分析。。。。。。

然后接下来就开始“数落数落”baseline不适合做双向强交互直播的原因。在看x264的代码时,偶然对编码中的预测做了少许的了解。

—- 我是装逼的分割线 1号 —-

传统上对一副图像的处理,一般的理论是基于“分割”,由于图像一般情况下具有前景和后景之分,也就是说,前景和背景之间存在着大量的局部图像细节,对于图像压缩中的思路往往是,尽量将相似的区域用差别不大的统一一个区域去表达,对于差异较大的区域,尽量在用较多的数据量去存储以此保留图像的局部细节。

那么就会存在如何分割图像的问题。如果是一副简单单值图,例如大学时代我做的非矢量图压缩(理论基础差不多),那么只需要根据图像分辨率,做相应的最佳分割快大小计算,并做简单切割即可。将区域内的有色的点和无色的点进行记录,并按做纵向或横向切割成色带,记录色带中有色点或者无色点的坐标值即可。整个思路转换成代码思维,类似于多级联映射表。当然这个做法的关键还在于公式如何设计,即如何动态计算切割区域的大小。由于是做印章方面,所以图像不会太大,因此公式也非常简单。

最终压缩可以理解成单值图的无损压缩,实测试之后,和转换成矢量图之后的文件大小相比,应该两者都会比现在主流的大部分图像编码小非常多。

接着通过类似7z、rar工具里面的二进制压缩算法进行再次压缩,文件最大还能缩小60%左右。一个500k的位图最终生成文件在3k左右。

—- 我是装逼的分割线 2号 —-

由于有上面的实践基础,因此在理解264的压缩时,我也能够理解到“分割”时的重要性。

首先,在baseline模式下,x264的预测模型相对于其他high来说,非常简单。这样的情况就决定了,在局部的细节切块相比high来说有着很多不足,对二进制数据进行压缩前就已经输在起跑线了。即细节丢失比high多。

其次在编码算法上(或者说压缩算法上),baseline仅仅使用cavlc,而对其他两者来说他们既可以使用cavlc也可以使用cabac。没有做过定性或者定考量分析,但通过网上资料获知,cavlc的效率似乎没有cabac高,具体在哪些指标有所体现目前暂时并不清楚。

因此,可以得知。baseline除了在实时性上满足了双向强交互直播对时间的要求,对于相同质量下的压缩比并不是很好。但又由于baseline相对其他profile的简单特点,其实广泛性还是比较不错的。

手里有台android 2.3时代的三星手机,对baseline的视频进行解码,手机基本可以应付(不清楚是硬解还是软解,因为当时的arm好像还有没有对264硬解做太多优化),但相同视频长度的main和high的话,那就有点头疼了。看来baseline对老旧手机还是比较“良好”的。

【x264、宏块、邻居】x264中对宏块预测方向与邻居类型的定义

在x264中,由于单一宏块预测方向与264规范定义实际上是一直的,即预测方向只有:左(left)、上(top)、左上(left-top)、右上(right-top)。

没有其他的另外四个方向,估计可能是zig-zag的数据排列有关,或只是由于对称关系,不需要做重复预测。

有上述4中预测方向,x264中定义了几种邻居关系(下面拿I帧4×4的宏块距离说明):

  • 垂直方向,即I_PRED_4x4_V、I_PRED_4x4_DC_TOP,实际上是向上方向预测(top)
  • 水平方向,即I_PRED_4x4_H、I_PRED_4x4_HU、I_PRED_4x4_DC_LEFT,实际上是向左方向预测(left)
  • 左边和向上方向,即I_PRED_4x4_DC
  • 向上旋转到右上方向,即I_PRED_4x4_DDL、I_PRED_4x4_VL
  • 左边旋转到向上方向,即I_PRED_4x4_DDR、I_PRED_4x4_VR、I_PRED_4x4_HD
  • 左边旋转到向上方向,即I_PRED_4x4_VL
  • I_PRED_4x4_DC_128代表自身?

【x264、图像量化】像素和亚像素

在看x264代码的时候,总是会看到sad、satd、subpixel。

至于sub pixel这个单词还算比较直观,子像素。当时脑补中的理解是,相邻像素按照不同权重计算出来的一种抽象像素,类似插值像素一样。

后来简单查了一下,才知道这玩意是亚像素。

即像素是感光器件上的实际一个像素点,对于亚像素就是感光器件上像素之间的抽象点。网上说是为了提高器件分辨率的一种抽象,但具体上我也没有实际有多少理解。

【x264、视频、编码、宏块】编码成不同帧时,宏块参数的变化情况

出于好奇最近在看x264的源代码。

对于不管是263、264还265编码来说,图像的压缩大题思路实际上是没有太大变化的。

对图像的压缩和编码,分为相关和非相关部分。又由于263、264、265并没有定义一定是无损压缩,所以在压缩和编码上与音频的编码和压缩也有着相似的处理方式;即,按照人的视觉特性进行编码(人眼分辨画面细节的能力是有限的)。

相关性压缩(和编码)又分为帧内相关和帧间相关,即编码出来的I帧就是我们所说帧内相关,B、P帧则是帧间相关。

对于非相关编码部分,大部分都集中在图像的前期处理上,例如归一化、白平衡、色度调节等。步骤大致如下:

  • 在图像预处理完成后(归一化、降噪等),接下来就是x264较多需要做的事情图像编码与压缩(虽然x264自身也会做一些降噪、再降噪、色度调节等)。
  • 先说编码部分,x264里面先将一副raw数据(可能是yuv420,可能是yv12等等),进行切块(即宏块分割,图像简单预测)。
  • 将分割好的图像在做块内再分割(细节预测,找出图像细节部分,对细节部分在切割,变成小块)
  • 接着又对每一个块做相邻之间的差异化计算(其实就是求出差异),这个过程是最复杂的一个。

 

下面是对于不同类型帧切块分类的说明其他具体的解释会在后续说:

 


 

其中对于不同类型的输出帧,宏块的大小如下:

I帧:

16*16、8*8、4*4


P帧:

L0、8*8、SKIP


B帧:

DIRECT、L0L0、L0L1、L0BI、L1L0、L1L1、L1BI、BIL0、BIL1、BIBI、8*8、SKIP

 


 

 

【webrtc、ios sdk 11、 xcode9】webrtc在xcode 9下的uuid_t编译错误

最近osx环境无意间升级了所有的包,并把xcode升级到了9。按部就班的继续编译之前可以正常编译的webrtc,后来不料,除了这么一个错误:

error: nullability specifier ‘_Nullable’ cannot be applied to non-pointer type ‘uuid_t’ (aka ‘unsigned char [16]’)

 

东查西查。最后就查到了之前的猜测,这里有解释:

https://forums.xamarin.com/discussion/103773/will-there-be-support-for-ios-11-sdk

因为xcode自带的是ios sdk 11的。就目前来说,这一点比较坑人,因为ios sdk 11的库和ios sdk 10的库在部分函数上的定义上有所区别。

而webrtc和相应的depot_tools也是今年年初的,因此使用的第三方clang编译器也相对xcode 9的步调来说老了一些。

为了不想增加麻烦,也就不打算用gclient了,因为当时不是我去拿的webrtc代码,也不知道会不会有坑。就果断把xcode降级为xcode 8。

xcode 8的下载地址:

https://developer.apple.com/download/more/

降级的方法:

http://osxdaily.com/2012/02/20/uninstall-xcode/

 

看来用第三方编译器也是让人比较头疼的一件事情。有时候ios上遇到的坑不比android少。。。

 

【osx、ios、xcode】编译x264、ffmpeg时出现sysroot警告

在编译x264和ffmpeg时会出现警告,截图如下:

实际上在命令行中已经看到,已经通过sysroot设置过目标平台的sdk的位置,但还是报错。通过google发现,新版本的xcode对sysroot参数关键字做了修改,将–sysroot改为-isysroot ,其他不变,编译通过。

【编译、ffmpeg、msvc】windows下编译ffmpeg

由于最近使用的ffmpeg及其相关的库太过于老旧,所以需要进行更新。

对于视频方面的编码主要用到h264,音频则用到mp3、aac、speex。

其中最为坑的,还是mp3和aac。因为mp3中的分支太多,为了简化问题,最后还是选用lamemp3作为编码器。在ffmpeg 3.0开始,ffmpeg就停止了aacplus的使用,改为使用fdk aac。并且ffmpeg还自带了一个aac编码器。

在编译过程中由于没有注意到这个问题,因此使用了内置编码器,导致he aac编码出来的数据缺少sbr段。因此需要外部加入fdk aac来完成。

 

  • 先说一说需要提前做的一些准备:

1、lamemp3源代码

2、speex源代码

3、fdk_aac源代码

4、x264源代码

5、ffmpeg源代码

6、安装msys2极其相应的工具(如果在windows上编译)

7、vs2015(如果在windows上编译)

 

lamemp3编译步骤:

直接代开源代码下vc_solution目录,使用vs2015编译即可

 

speex编译步骤:

打开win32目录下的vs2008直接用vs2015编译即可

 

fdk_aac编译步骤:

fdk_aac编译比较坑,不能在msys2中编译,需要用nmake(vs工具链)直接编译就好……

 

x264编译步骤:

在msys2中直接编译即可

 

ffmpeg编译步骤:

1,将speex、mp3、aac中include的部分代码拷贝到ffmpeg根目录下

2,在将相应的lib文件拷贝到根目录下的某个文件,这里用3rdparty来代表目录

3,执行编译命令

./configure –prefix=/c/work/github/ffmpeg_src_3.2/out –toolchain=msvc –enable-libx264 –enable-libmp3lame –enable-libfdk-aac –enable-nonfree –enable-libspeex –enable-gpl –extra-cflags=-IC:\\work\\github\\ffmpeg_src_3.2 –enable-shared –extra-ldflags=-LIBPATH:C:\\work\\github\\ffmpeg_src_3.2\\3rdparty\\lib

4,执行make和 make install之后即可

 

不要轻易的羡慕所谓的高薪,而是要看时薪、前途和钱途

首先说一下为啥会写这个文章,主要还是因为最近遇到某些大公司的人,实在受不了那种高高在山的样子,以及一些小朋友的各种有色眼镜去看待农民工一个月两万的收入。下面就是正文:

 

 

我现在基本不看高薪职位,更不会向往什么大公司。原因很简单,中过不少招,刚刚从这些坑里爬出来。

首先,一个公司对人力的支出成本大致如下:
1,五险一金及其其他可能有的福利或保险(公司部分)
2,房租、办公用品成本均摊费
3,员工工资以其他奖金

我为什么会知道这些?因为当年在某大公司的时候,我和 hr 混的相对熟,他们告诉我的一种算法。所以说,睡前月薪如果 1w,那么按照五险一金全额缴,公司 1+月薪得到的成本可能是 1.3w 起。

不要带着任何有色眼镜去看农民工,工作无高低贵贱之分。如果你们有兄弟姐妹在工地干活,那么你们将会知道这是一个风险巨大没有任何保障的工作。例如,尘肺病,腰肌劳损等。而我们做办公室的,看似体面,但却是风险和保障上相对会好一些。或者不相信就去查一查快递和外卖行业的送货员年交通事故平均值是多少就知道了。

同时也不要迷信任何高薪,以前大公司流行拿所谓的高薪、期权、股票、多少多少薪来吸引一大堆简历,但一旦成功入职后或者转正后;大部分人经历的将是无休止的加班、办公室政治、价值观、拥抱变化等等。
等年长一些,身体一堆病,最后如果不慎病倒或者去世了,搞不好可能还会被公司恶心一把,甚至还会有其他同事会在各种场合数落你;这就是人性的冷漠!

最近几年中小、微型公司也开始流行大公司的套路了。事实上什么叫做合适的薪水?

看时薪和是否有生活成分,如果被工作占据太多时间,那么在我之前呆过的一家公司里曾有这么一句话:“有命赚钱没命花钱”。

现在的社会越来越世俗和浮躁,人和人之间感情也越来越淡薄,甚至有些人把“利用”和“斗争”当作家常便饭,说到底是啥?物质欲太强烈,月薪 1k 的看着月薪 2k 的,月薪 1w 的看着月薪 2w 的,一山望着一山高而已。

我也是经历了一大堆破事,被迫深陷漩涡之中出来后来明白的。一些打着高薪但时薪低的岗位或者公司,均是耍流氓!