【vs2013、msys2】vs2013命令行环境变量不继承到msys2
编译一些开源的时候不得不需要用到msys2。所以需要现在vs2013的命令行环境中启动msys2环境，这样就可以把vs的命令行环境变量继承到msys2。
目前最新版本的msys2会出现不继承的情况，主要由于msys2 中/etc/profile文件中继承脚本的过滤了vs的一些有效环境，参考csdn上一个博客的修改方法，修改成如下：
分类目录归档: 音视频容器
【winxp、vista、webrtc、chromium】放弃支持xp的路上webrtc跟上了！
最近拿了59的分支代码，后来偶然看到webrtc把wavein/waveout函数族相关的代码删除掉，看git注释另外根据chrome弃疗的心语路程，webrtc终于放弃xp了。
但苦了我了。。。。。。因为国内还有着一大群xp用户。。。。
【chrome、webrtc】python-boto代理设置
webrtc最近半年的时间里又改代码框架，又改下载脚本！真***法科！
目前除了使用到python-curl、git、还用到了一个叫做python-boto的玩意，用来从aws上下东西的。不理解为啥不用自家的云。。。。
现在拿webrtc的代码，除了需要配置git、python-curl的代理，还需要配python-boto的代理。
python-boto的代理配置方式如下：
1，在某个目录中创建一个.cfg后缀的文件
2，然后填入内容如：
-
[Boto]
proxy=127.0.0.1
proxy_port = 10808
3，命令行中输入！
-
NO_AUTH_BOTO_CONFIG=C:\work\depot_tools\boto.cfg
【c++11、webrtc、stl】利用stl“就地构造”提高代码性能
最近在看webrtc的trunk上最新的代码，今天无意间留意到了stl容器中的“std::vector<T>::emplace_back”。事实上在接触webrtc之初我就经常能看到这个方法的使用，只不过那时候的对webrtc完全不了解，所焦点都在webrtc是个什么东西上。
后来查stl官方文档，看到的解释为：
构造并插入元素
同时网站上也给出了列子，但并不是很明确。看vs2015中对该函数的实现，实在看不懂（因为和push_back的一个分支实现很非常相似）。google看到这个函数代表在vector内部进行构造并放到数组里。
这样做的好处在于不需要去特意写移动构造函数，也不需要进行任何移动操作。间接的加快了性能。
ps：由于网上的说法存在问题，所这里要明确更正一下。
emplace_back和push_back两个函数都是通过“布局new”的方式将元素对象的内存放到自己的堆中（并非栈中）。
【chromium、webrtc、gn】引入gn之后下载代码和生成vs工程的方法
按照惯例，还是一如既往的通过代理进行下代码，并生成工程。因为webrtc是chromium里面的一个组件，所以webrtc和chromium的下载和生成工程的方法大同小异。
具体步骤如下：
1. 首先把depot_tools装好。
2. 配置代理
netsh set winhttp proxy 127.0.0.1:10808 set http_proxy=http://127.0.0.1:10808 set https_proxy=https://127.0.0.1:10808
3. 按照官方的步骤，下载代码
mkdir webrtc-checkout cd webrtc-checkout fetch --nohooks webrtc gclient sync
4*. 如果gclient sync过程出现异常，或建议最好执行本步骤
gclient runhooks
5. 通过gn生成vs2015的工程
cd src gn gen --ide=vs2015 /out/Default
结束。
这个过程中比较头疼的问题就是需要一个稳定的代理
flash弱交互和强交互中的好与坏
由于最近在做强交互的在线直播，所以不得不对flash这玩意产生各种新的实用性认识，这主要还是由于先流行直播和点播中对flash的滥用造成的。
首先我不敢说我是完整经历了flash 1.0但现在的人，但至少当年的<阿贵>我还是印象深刻的。
在以前，浏览器就像不怎么支持tiff 一样是完全不支持flash的。要想用flash那就需要装插件，ie和firefox都是如此。
如今的浏览器为了迎合大众，都默认捆绑了flash插件。
由于activex控件存在开发麻烦，跨平台等问题，所以flash也间接成为了一个网页上的音视频播放器。
正因为方式软件工业在操作系统，多媒体接口，音视频编解码等方面还没有现在这样的一致性相对较好和可靠，所以大家都转为用相对简单的东西去设计系统。
首先从播放器角度去看，flash就不是一个很好的播放器，性能低下过度依赖浏览器特性，以及自身的不开放加之兼容范围较小，很难做到高保真和高响应。
以现在主流的一些直播网站为例，他们采用的均是单向音视频直播，弱交互，rtmp+h.264+aac。仅仅从h.264上来说要做到高质量，势必要提高码率，按照2m-5m码率去测试，我一个i5 460m的u上仅仅解码就至少要吃点40%的性能，而且还不能开显卡加速，要不然花屏，绿屏的问题就来了。
然后再说说aac，这个音频编码本来就不是为低延时设计的，也没有对延时做过太多要求，虽然有低延时版的aac。
显然单向的直播模型是可以用flash这套东西的，因为他成熟且方便用户使用。
但由于有这样的一些网站在用这套体系，无形中绑架了那些要做强交互的在线直播。
通过我对少量在用flash做强交互，和我们自身用flash做强交互的同行们沟通情况来看，大家用flash主要原因是较低用户的学习成本，或简化客户端复杂度，或有web端。
确实在各种流氓转正的今天，要想在用户电脑上正常的安装一个相对规矩的软件还是蛮难的。另外，在业务的开发周期，开发难度上和灵活性上，web确实要比native app好很多。
所以现在大家就陷入了一场困境，大势所趋下，技术实力或市场地位不是很强的公司显然只能顺应大流。
事实上，无论选用flash还是native app做强交互的直播，都是没问题的。但问题就在flash并非一个专业的音视频播放采集器，配套的系统也不见得能很好的处理网络一些问题所造成的体验不佳的情况。
所以在强交互的直播上，我个人及其反对使用flash用在任何和音视频的有关的地方。相信音视频方面用过flash或相应开发的人，应该会深有体会，这坑有多大……