由于最近在做强交互的在线直播，所以不得不对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或相应开发的人，应该会深有体会，这坑有多大……

最近由于项目需要，需要解决在强交互中，音视频延时、同步问题。

1，了解了一下AAC编码的特点，通过查阅得知，一个AAC的压缩包是由1024个压缩前的PCM样本构成。换句话说，AAC对样本数的要求较高，带来的是AAC需要才待编码缓存中存储大量的样本，才能进行编码。如果按照44khz采样计算，1024个样本大约是1/44/1000*1000*1024=23ms；即，每个AAC包携带了23ms，如果不计算AAC数据包交付时隙的话，那么理想情况下，AAC编码器每次对外部输出数据的间隔是23ms，这23ms就是编码延时。

2，例如在普通的商业网络中（非专线，ADSL），用户到服务器之间的双向延时100ms（32个字节）。那么即可得出，样本的理想情况下的最大延迟在23ms+50ms=73ms。

3，实际上在目前绝大部分直播组网里面，基本可以简化成下图：

通过延时计算，可以得知，服务器得到的第一个音频样本其实已经是过时了的，并且已经过时了73ms。当服务器对数据再次转发给播放者时，延时将会被加大到123ms。这都还不考虑其他因素引起的延时问题。

4，由此可以得出，对AAC来说，本身就存在固有的23ms延时，加上网络的一个基准延时后，整体延时被放大到123ms，如果加上客户端、服务器之间的性能考虑，那延时或许可以达到200ms-300ms。

在双向通讯，即强交互中可以做如下初步估计：

a) 模型：A  <—–> 服务器 <—–> B

b) 理想情况下，A说一句话，这句话经过了123ms后，B收到。

c) 不考虑解码延时等问题的情况下，B回复A说的这句话。再次经过123ms，A收到（此时A已经等待了大约123*2=246ms）。

经过简易的测试发现，在强交互中，人对延时的感知基本在300ms-500ms这个区间，按照个体素质不同，会存在一定的浮动；人对延迟的基本容忍，保持在3s左右。

所以可以得知，AAC方式的音频编码，在普通的商业互联网中进行直播交互是不适用的。

注意：由于本人没有对AAC-LD的相关资料进行查阅，只是看了通用的AAC资料，所以得出以上的判断。

首先看两张效果图（其中有一张是ps出来的，因为没有找到现有的素材）

（图A）

（图B）

再实时采集中，由于采集性能上的不足，会导致每一幅画面生成（模数过程、编码过程）会出现一定的延时。当数据生成时间较长的情况下，可能会出现画面被截断（或重影）的情况。

而在隔行和逐行中，分别为图A和图B。

因此在隔行扫描上，还需要考虑图像的平滑切换。

而对于隔行扫描出现的就是重影，需要对重影进行一定的抑制。

再看《深入理解windows》的时候，书中提到windows并非总是一个实时系统。主要原因是由于系统本身的设计，以及驱动，应用软件各方面一同构成的；然后就偶然了解到RTX这个辅助工具。

看了一下RTX的介绍，实际上RTX就是一个和windows内核相仿的一个系统。然后RTX会工作在一个或者几个独立的vcpu/cpu上，使得该vcpu/cpu变成一个实时系统。进而进行部分接管windows的一些中断响应、驱动操作。

然后就看到这个RTX的关于如何配置的视频时，听到对方介绍到用到RTX和没有用到RTX的系统。在用到了RTX的windows里面，对于一个1us采样的5s beep音频来说，能够流畅的播放出来。而对于一个没有使用RTX的是系统来说，就会出现断断续续的问题。

接着因为感兴趣对方是如何测试，就随手写了一段代码：

#include "stdafx.h"
#include <Windows.h>

int _tmain(int argc, _TCHAR* argv[])
{
for (int i =0; i<5000; ++i)
{
DWORD dwstart = GetTickCount();
Beep(750, 60);
DWORD dwend = GetTickCount();
printf("now cur %d, cost time %d\n", i, dwend - dwstart);
}

Sleep(1000*3600);
return 0;
}

由于gettickcount本身也是个严重不准的时间函数，所以也只能间接看一看；且整个声音均为断断续续。

通过测试发现，每个循环周期都有可能不是稳定的，有时候会存在2-5ms的误差，也或许和gettickcount的分辨率有关，或许确实和beep函数有关。

后来通过代码修改为如下，整个音频则变为流畅：

#include "stdafx.h"
#include <Windows.h>

int _tmain(int argc, _TCHAR* argv[])
{
Beep(750, 5000);
Sleep(1000*3600);
return 0;
}

通过上述观察然后跟踪了一下beep的汇编，汇编代码如下：

在msdn在NtDeviceIoControlFile中的描述：

参考beep函数的说明以后，在通过上述的描述；可见每调用一次beep始终是等待硬件处理完成以后，才会返回beep。然后又因为windows为非实时系统，所以就会出现上诉的代码1会出现发声会出现断断续续的问题。因为各种中断什么时候能够被处理，或者处理结束都是没有很强的约束性的。

当然，sleepex本身也是一个要走软中断的模块，显然也会影响到代码的发声情况。至于sleepex的精度情况，我自己没找到msdn官方说明，但参考waitforsingleobject和sleep，那sleepex精度也不会很高。