工作

忙的不可开交，项目流程梳理，工作任务接手，团队建设，人员培养。
没有睡过一个懒觉！
技术没有进展，根本没时间看点技术的东西
今天抽时间测试出了一个兼容性比较好的版本，优化还待加强,基本能用，去掉了polyfill减小了核心文件体积

生活

儿子和父母回老家了，比较思念，但是只能通过视频看看儿子，平时照片发的也少，过几天放假了就能看到他了
最近在听领导的建议看电子版的 《人性的弱点》
思想和观念要转变了！

wav

wav是一种无损的音频文件格式，WAV符合 PIFF(Resource Interchange File Format)规范。所有的WAV都有一个文件头，这个文件头音频流的编码参数。WAV对音频流的编码没有硬性规定，除了PCM之外，还有几乎所有支持ACM规范的编码都可以为WAV的音频流进行编码
PCM（Pulse Code Modulation—-脉码调制录音)。所谓PCM录音就是将声音等模拟信号变成符号化的脉冲列，再予以记录。PCM信号是由[1]、[0]等符号构成的数字信号，而未经过任何编码和压缩处理。与模拟信号比，它不易受传送系统的杂波及失真的影响。动态范围宽，可得到音质相当好的影响效果。
简单来说：wav是一种无损的音频文件格式，pcm是没有压缩的编码方式。
WAV可以使用多种音频编码来压缩其音频流，不过我们常见的都是音频流被PCM编码处理的WAV，但这不表示WAV只能使用PCM编码，MP3编码同样也可以运用在WAV中，和AVI一样，只要安装好了相应的Decode，就可以欣赏这些WAV了。在Windows平台下，基于PCM编码的WAV是被支持得最好的音频格式，所有音频软件都能完美支持，由于本身可以达到较高的音质的要求，因此，WAV也是音乐编辑创作的首选格式，适合保存音乐素材。因此，基于PCM编码的WAV被作为了一种中介的格式，常常使用在其他编码的相互转换之中，例如MP3转换成WMA。简单来说：pcm是无损wav文件中音频数据的一种编码方式，但wav还可以用其它方式编码。

mp3

MP3是一种音频压缩技术，其全称是动态影像专家压缩标准音频层面3（Moving Picture Experts Group Audio Layer III），简称为MP3。它被设计用来大幅度地降低音频数据量。利用 MPEG Audio Layer 3 的技术，将音乐以1:10 甚至 1:12 的压缩率，压缩成容量较小的文件，而对于大多数用户来说重放的音质与最初的不压缩音频相比没有明显的下降。它是在1991年由位于德国埃尔朗根的研究组织Fraunhofer-Gesellschaft的一组工程师发明和标准化的。用MP3形式存储的音乐就叫作MP3音乐，能播放MP3音乐的机器就叫作MP3播放器。

1. MP3是一个数据压缩格式
2. 它丢弃掉脉冲编码调制（PCM）音频数据中对人类听觉不重要的数据（类似于JPEG是一个有损图像压缩），从而达到了小得多的文件大小；
3. MP3音频可以按照不同的位速进行压缩，提供了在数据大小和声音质量之间进行权衡的一个范围，MP3格式使用了混合的转换机制将时域信号转换成频域信号
4. 32波段多相积分滤波器（PQF）
5. 36或者12 tap 改良离散余弦滤波器（MDCT）;每个子波段大小可以在0…1和2…31之间独立选择
6. MP3不仅有广泛的用户端软件支持，还有很多的硬件支持比如便携式媒体播放器（指MP3播放器）DVD和CD播放器

ogg

Ogg全称是OGGVobis(oggVorbis)是一种音频压缩格式，类似于MP3等的音乐格式。Ogg是完全免费、开放和没有专利限制的。OggVorbis文件的扩展名是”.ogg”。Ogg文件格式可以不断地进行大小和音质的改良，而不影响旧有的编码器或播放器。
Ogg全称是OGG Vorbis， 是一种音频压缩格式，类似于MP3等的音乐格式。但有一点不同的是，它是完全免费、开放和没有专利限制的。OGG Vorbis有一个特点是支持多声道。
Ogg Vorbis文件的扩展名是.OGG。这种文件的设计格式是非常先进的。创建的OGG文件可以在未来的任何播放器上播放，因此，这种文件格式可以不断地进行大小和音质的改良，而不影响旧有的编码器或播放器。

• 优点1：Ogg Vorbis的音质和MP3不相上下，但无法和FLAC比。
• 优点2：Ogg Vorbis支持类似于MP3的ID3信息
• 优点3：Ogg Vorbis格式支持流式播放
• 优点4：Ogg Vorbis避免了像MP3文件的ID3标记那样烦琐的操作(有很多针对MP3的ID3修改软件标记早已不繁琐)
• 缺点1：播放兼容性差。
• 缺点2：mp3是1997年以前就已经诞生，将近20年垄断了消费机市场。
• 缺点3：相对于已经普及的微软WMA格式，ogg没有任何优势。
• 缺点4：多声道系统已经由DOLBY、DTS两家公司垄断，他们都有完整的制作发行体系。
• 缺点5：很多专业音频制作软件不支持ogg文件格式。
• 缺点6：现今HIFI已经被HIRES（高解析）代替，随着存储、网速等限制，用户的聆听设备已经上了一个台阶，有损格式已经渐渐失去市场。

参考资料

WAV和PCM的关系和区别
百度百科-MP3格式
百度百科-OGG格式

Web Audio API使用户可以在音频上下文(AudioContext)中进行音频操作，具有模块化路由的特点。在音频节点上操作进行基础的音频， 它们连接在一起构成音频路由图。即使在单个上下文中也支持多源，尽管这些音频源具有多种不同类型通道布局。这种模块化设计提供了灵活创建动态效果的复合音频的方法。

音频节点通过它们的输入输出相互连接，形成一个链或者一个简单的网。一般来说，这个链或网起始于一个或多个音频源。音频源可以提供一个片段一个片段的音频采样数据（以数组的方式），一般，一秒钟的音频数据可以被切分成几万个这样的片段。这些片段可以是经过一些数学运算等到 （比如OscillatorNode），也可以是音频或视频的文件读出来的（比如AudioBufferSourceNode和MediaElementAudioSourceNode），又或者是音频流（MediaStreamAudioSourceNode）。其实，音频文件本身就是声音的采样数据，这些采样数据可以来自麦克风，也可以来自电子乐器，然后混合成一个单一的复杂的波形。

这些节点的输出可以连接到其它节点的输入上，然后新节点可以对接收到的采样数据再进行其它的处理，再形成一个结果流。一个最常见的操作是通过把输入的采样数据放大来达到一个扩音器的作用（缩小就是一个弱音器）（参见GainNode）。声音处理完成之后，可以连接到一个目地地（AudioContext.destination），这个目地地负责把声音数据传输给扬声器或者耳机。注意，只有当用户期望听到声音时，才需要进行最后一个这个连接。

一个简单而典型的web audio流程如下：

1. 创建音频上下文
2. 在音频上下文里创建源 — 例如 <audio>, 振荡器, 流
3. 创建效果节点，例如混响、双二阶滤波器、平移、压缩
4. 为音频选择一个目地，例如你的系统扬声器
5. 连接源到效果器，对目的地进行效果输出

使用这个API，时间可以被非常精确地控制，几乎没有延迟，这样开发人员可以准确地响应事件，并且可以针对采样数据进行编程，甚至是较高的采样率。这样，鼓点和节拍是准确无误的。

Web Audio API 也使我们能够控制音频的空间化。在基于源 - 侦听器模型的系统中，它允许控制平移模型和处理距离引起的衰减或移动源（移动侦听）引起的多普勒效应。

Web Audio API 接口

原文链接

音频节点：模块化连接

网页音频接口(Web Audio API)主要是 音频环境(audio context) 中进行音频处理，它允许模块间的连接。基本的音频处理在 音频节点(audio node) 当中执行，这些系欸但连接在一起形成了 音频导向图(audio routing graph). 多个声源，甚至包含不同种类的声道，都可以在一个音频环境中进行处理。这种模块化的设计使得人们在创建复杂多变的声音特效时可以更加灵活。

音频节点可以通过各自的输入与输出相连，形成一个 从一个或多个声源开始，经过处理节点，终止于末节点 的链式结构（有时你不需要末节点，比如你只是想数字化处理某些音频数据的时候）。一个简单、典型的网页音频接口的操作流程可以是这样的：

1. 创建一个音频环境
2. 在音频环境中，创建声源——例如 <audio> 标签，振动发声器(oscillator)，音频流
3. 创建特效节点——例如混响，双二阶滤波，声相控制，音频振幅压缩
4. 选择音频的终点——例如系统的扬声器
5. 连接声源和特效，以及特效和终点。

每个输入和输出都可以包括几个声道，声道代表了一个特定的音效通道。各种声道分离结构都可以使用，包括单声道，立体声，四声道，5.1等等。

声源可以来自不同的地方：

直接通过 Javascript 生成声音节点产生（例如一个振动发声器）
由脉冲编码调制产生的原始数据（音频环境中可以调用一些方法来解码部分支持的格式）
从 HTML 元素中（例如 <video> 或者 <audio> 标签）
直接通过一个 WebRTC MediaStream 获取流媒体（例如一个摄像头或麦克风）

音频数据：什么是样本

当一个音频信号被处理时，取样意味着从一个连续的信号转化为离散的信号；更具体地说，一个连续的声波（例如一个正在演奏的乐队发出的声音）会被转化成一系列的样本点（一个时间上离散的信号），计算机只可以处理这些离散的样本块。

更多的细节可以查看维基百科的采样页面。

音频片段：帧，样本和声道

一个音频片段(AudioBuffer) 会包含几个组成参数：一个或几个声道（1代表单声道，2代表立体声等等），一个长度（代表片段中采样帧的数目）和一个采样率（是每秒钟采样帧的个数）。

每个样本点都是一个代表着该音频流在特定时间特定声道上的数值的单精度浮点数。一个帧，或者一个采样帧是由一组在特定时间上的所有声道的样本点组成的——即所有声道在同一时间的样本点（立体声有2个，5.1有6个等等，每个帧包含的样本点个数和声道数相同）。

采样率就是一秒钟内获取帧的个数，单位是赫兹(Hz)。采样率越高，音频效果越好。

现在让我们来看一下通道，一个单声道和一个立体声的音频片段，每个都是1秒钟，播放频率（采样率）为44100赫兹：

• 单声道片段会有 44100 个样本点和 44100 个帧。长度属性为 44100 。
• 立体声片段会有 88200 个样本点和 44100 个帧。长度属性依旧为 44100 ，因为长度总和帧的个数相同。

当一个音频片段开始播放时，你将会听到最左侧的样本帧，之后是他右侧相邻的一帧，以此类推。在立体声中，你将会同时听到两个声道。样本帧的概念在此时非常有用，因为每个样本帧代表特定的播放时间，而和声道个数无关，这种方式很有利于精确的多声道同步处理。

注意：只需用帧的数目除以采样率即可得到播放时间（单位为秒）。用样本点数目除以声道个数即可得到帧的数目。

下面我们将展示几个浅显易懂的示例：

1
2

var context = new AudioContext();
var buffer = context.createBuffer(2, 22050, 44100);

如果你使用上面的方法调用，你将会得到一个立体声（两个声道）的音频片段(Buffer)，当它在一个频率为44100赫兹（这是目前大部分声卡处理声音的频率）的音频环境中播放的时候，会持续0.5秒：22050帧 / 44100赫兹 = 0.5 秒

在数字音频中，44,100 赫兹 （有时也写作 44.1 kHz）是一个常见的取样频率。 为什么选取44.1kHz呢？首先，因为人耳的接收频率大约在 20 Hz 到 20,000 Hz之间，根据采样定理，采样频率一定要大于最终生成数据最大频率的二倍，因此就一定要大于40,000 Hz（即 40kHz）。不仅如此，在采样之前信号还必须通过低通滤波器 ，否则会发生混叠现象，一个理想低通滤波器会完全留下低于20kHz的信号（且没有使它衰减）并完美阻拦一切高于20kHz的信号，而事实上过度频带（英文）总是存在，在这个区域内信号会被部分衰减。这个频带越宽，建立一个抗混叠滤波器才越容易。因此我们选取44.1kHz允许我们有2.05kHz的空间预留给过度频带。

1
2

var context = new AudioContext();
var buffer = context.createBuffer(1, 22050, 22050);

如果你这样调用，你将会得到一个单声道的音频片段(Buffer)，当它在一个频率为44100赫兹的音频环境中播放的时候，将会被自动按照44100赫兹重采样（因此也会转化为44100赫兹的片段），并持续1秒：44100帧 / 44100赫兹 = 1秒。

注意：音频重采样与图片的缩放非常类似：比如你有一个16 x 16的图像，但是你想把它填充到一个32 x 32大小的区域，你就要对它进行缩放（重采样）。得到的结果会是一个叫低品质的（图像会模糊或者有锯齿形的边缘，这取决于缩放采用的算法），但它却是能将原图形缩放，并且缩放后的图像占用空间比相同大小的普通图像要小。重新采样的音频道理相同——你会介于一些空间，但事实上你无法产出高频率的声音（高音区）。

分离式与交错式音频片段

网页音频接口使用了分离式的片段储存方式：左(L)右(R)声道像这样存储：

LLLLLLLLLLLLLLLLRRRRRRRRRRRRRRRR （对于一个有16帧的音频片段）

这种储存方式在音频处理中非常常见：这种方式允许对每个声道单独处理。另一种储存方式是使用交错式的片段储存方式：

LRLRLRLRLRLRLRLRLRLRLRLRLRLRLRLR （对于一个有16帧的音频片段）

这种方式在存储以及播放音频等不需要音频加工的操作中非常常见，例如一个解码后的MP3流媒体。
在开发者接触到的网页音频接口中只有分离式音频片段，因为它主要用于音频加工。在处理过程中它使用分离式，但是当它传送到声卡中用于播放时，音频片段会被转化为交错式。反过来，当MP3被解码时，初始状态它是交错式的，但是他会被转化成分离式以用于音频加工。

声道

不同的音频片段可能包含不同数量的声道个数，从基本的单声道（只有一个声道），立体声（左右两个声道），到更加复杂的四声道，5.1。由于每个声道中包含的音频数据可以不同，因此声道越多听觉效果越好。在不同声道模式中，表示特定声道的缩写如下表所示：

向上和向下混频

当输入与输出的声道数不同时，我们就需要按照如下方法进行混频。这些封装好的方法可以通过设置声音节点的 AudioNode.channelInterpretation 属性为 "speakers"（扬声器） 或 "discrete"（离散声道） 进行混频。

可视化

一般来说，可视化是通过获取各个时间上的音频数据（通常是振幅或频率），之后运用图像技术将其处理为视觉输出（例如一个图像）来实现的。网页音频接口提供了一个不会改变输入信号的音频节点 AnalyserNode，通过它可以获取声音数据并传递到像 <canvas> 等等一样的可视化工具。

你可以通过如下方法获取需要的音频数据：

AnalyserNode.getFloatFrequencyData()
返回一个Float32Array 数组，其中包含传递到此音频节点声音的实时频率数据。
AnalyserNode.getByteFrequencyData()
返回一个Uint8Array 无符号字节数组(unsigned byte array)，其中包含传递到此音频节点声音的实时频率数据。
AnalyserNode.getFloatTimeDomainData()
返回一个Float32Array 数组，其中包含传递到此音频节点声音的实时波形，时间数据。
AnalyserNode.getByteTimeDomainData()
返回一个Uint8Array 无符号字节数组(unsigned byte array)，其中包含传递到此音频节点声音的实时波形，时间数据。

注意： 更多信息可以参考我们的这篇文章：基于Web Audio API实现音频可视化效果 。

空间位置化

音频的空间化（由网页音频接口的 PannerNode 和 AudioListener 节点处理）允许我们对空间中某一点的音频信号，以及这一信号的接听者建立位置和行为模型。

声相控制器的位置可以通过笛卡尔坐标系进行描述，控制器的运动可以由速度向量来表示，这会引起多普勒效应，它的传播方向可以用一个方向圆锥来表示，当它是一个全方向声源时，圆锥会变得非常大。

接听者的位置可以用笛卡尔坐标系来表示；他的运动可以用方向向量表示；头部姿态可以用两个向量表示：一个向上向量表示头顶正对的方向，一个向前向量表示鼻子所指向的方向（面向的方向），这两个向量应该互相垂直。

扇入与扇出

对于音频来说，扇入是指 ChannelMergerNode 节点接收一系列单声道输入声源，并将它们整合输出为一个多声道音频信号的过程：

扇出恰恰相反，是指一个 ChannelSplitterNode 节点接收一个多声道输入声源并将它分离成多个单声道音频信号的过程：

原文链接

初识node

从node一出来就刮起来一阵狂风，来势汹汹。记得初识node的时候被官网首页的7行代码的Hello world惊艳到了,它既充当了web容器,又担任了后台逻辑编码.似乎要颠覆,后来慢慢接触以后把一些项目开始使用它来编写，逐渐的承担起大前端这个潮流的主演,而后各种的基于node的前端构建工具或工作流层出不穷,把前端开发推向了一个新的高潮！我们极力的追赶着，却总是迷失在频繁的技术变革中.

Chrome V8

第一次听说这个引擎的时候我联想到的是跑车或是赛车的V8发动机，我猜测谷歌公司给这个渲染器命名的时候应该有这个方面的考虑。正如他们所愿，V8引擎已经承载了太多，他已经从单纯的做浏览器渲染引擎开始向桌面客户端进军~

初识 electron

记得很早的时候看到几篇博文在描述这个技术，然后在里面看到网易云音乐就是采用该技术开发的,而后出现的 vscode，到目前为止这些应用也是为数不多横跨各大操作系统的应用，它的出现似乎为跨平台应用指出了新的方向，以前可能有qt，现在的electron让前端开发工程师就能享受到开发桌面应用的便捷,他基于node平台开发依托于V8高性能渲染，让你的跨平台应用如虎添翼~

技术栈与特点

• html/css/javascript
• 基于Chromium与Node.js
• 开源Github
• 跨平台
• 支持自动更新
• 原生菜单和通知
• 奔溃报告
• 调试&性能分析
• windows 安装包

快速开始

# 克隆示例项目
$ git clone https://github.com/electron/electron-quick-start
# 进入这个仓库
$ cd electron-quick-start
# 安装依赖并运行
$ npm install && npm start

一些思考

1. 上手比较快，基本上很多现有的B/S架构的系统都很好移植到electron上面来变成C/S架构
2. 所有的UI都是基于Chromium来进行渲染，所以浏览器上面开发遇到的问题基本在这个上面会遇到
3. 开发的时候尽量是把调用 electron的api部分和ui部分的进行隔离，方便移植为B/S
4. UI部分的开发推荐使用SPA的方式去做，会有更好更流畅的操作体验
5. 整体打包的体积比较大，这一块需要多花心思来进行压缩和精简，毕竟要打进去一个浏览器和node
6. 用着基于Electron开发的VS Code去开发基于Electron的应用总感觉怪怪的

写在前面

今天又重新把github的个人博客倒腾了一番。很早就注册了，也开通开人博客方式了，但是一直都是放在那里长草，期间也捣鼓了一番想自己独立服务器来搞，但是各种麻烦。
这篇文字就把我的这些点滴折腾记录一下，好给我重新开个头，以后要坚持写了，随便什么类型的内容，至少要为自己留下一些东西,如果一个月能产一篇亦可以啊！

初识博客园

记得注册博客园是在2010年左右，这都过去7年多了，但是一直也只是在上面看看文章，需要登录评论了登录评论一下，偶尔发个闪存。一直都没有开博客，直到2015年的时候鼓起勇气
申请了博客，并顺利的审核通过了，然后就在上面发了第一篇文章，然后就没有然后了，各种懒癌！！

阿里云服务器

工作需要也正好是阿里云搞活动，就在上面开了一个ecs主机，选的最低配置，起初上的是windows系统，后来各种问题，于是就换了 center os ，一直也只是在上面乱捣鼓，并没有实际
利用起来，后来想在上面搭建个博客于是就找到了hexo,然后再上面跑了起来，但是没有写任何文字，就写了个个人介绍，于是又烂尾了。

注册域名

当时看到阿里云搞活动，域名很便宜就入手了一个 dehai.site 的域名，然后想着这个域名可以给自己的个人博客来用，于是就做了dns解析，结果都是大家预期的结果，很快不能访问提示
要备案，于是寻思着点了备案的链接进去备案，然后

无解

1. 选择重庆，要求身份证是本地的(我的身份证还是在老家)
2. 选择甘肃，要求当地的电话号码验证(我的号码只有重庆的)
3. 陷入死循环
4. 无解
5. 艹

写在前面

最近因为项目预研,花时间和精力了解并总结了现如今web在线视频的一些解决方案,由于资历薄浅,措辞或是表述难免出现遗漏,还望各位海涵,有好的建议或方案还望赐教,定细心学习品位.如今的web技术日新月异,凭借着自身与平台无关的特性发展的异常火爆,各种新技术的出现,催生了大前端的概念,各种系统都开始向着B/S架构靠拢,在公司产品向着web化进化的过程中,难免会遇到各种各样的问题,其中在线视频就是一个比较难的突破点,尤其是在pc/移动端、浏览器兼容性、时效性、性能等方面都或多或少的影响着现有各种解决方案的步伐，当然我也相信随着html5带动起来的软硬件web技术的发展大潮，必定在最后出现一种比较完美解决方案。

概述

Web在线视频从种类分主要分2种，直播和回放，它们各自的业务和需求都不尽相同；从Web视频宿主分类那就只有浏览器(或webbrowers)，说起浏览器在这里稍微多说几句，现在的浏览器可谓品种繁多，并且浏览器的品质也层次不齐，不过从内核划分的话就主要有这几种了(trident/gecko/presto/webkit(hot)/blink),那剩下的就是给这些内核穿衣服了，然后包装成各式各样的浏览器，有几个国内的浏览器就比较恶心了；从Web视频的传输来讲主要应该分为(websocket/socket);从Web视频支持的视频格式不好划分，因为使用不同的技术这个格式也不尽相同；

WebRTC

WebRTC(百度百科)，名称源自网页实时通信（Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的技术，是谷歌2010年以6820万美元收购Global IP Solutions公司而获得的一项技术。同时，Google也希望和致力于让WebRTC的技术成为HTML5标准之一，可见Google布局之深远。WebRTC提供了视频会议的核心技术，包括音视频的采集、编解码、网络传输、显示等功能，并且还支持跨平台：windows，linux，mac，android。

(图1：WebRTC架构图 (图片来源百度百科))

下面是园友对WebRTC的研究：

1. RTC.Blacker
2. 孤竹君

PS：WebRTC 是谷歌支持的开源技术，致力于推进到HTML5标准当中，目前大部分浏览器已经在支持当中，如果单纯的开发浏览器端-浏览器端的app，那么只需要掌握一些调用接口知识和前端功底，如果要实现其他视频采集源，那就要去研究和编译WebRTC服务器端代码，并进行改造到符合自己业务需要。

Html5

万维网的核心语言、标准通用标记语言下的一个应用超文本标记语言（HTML5）的第五次重大修改。2014年10月29日，万维网联盟宣布，经过接近8年的艰苦努力，该标准规范终于制定完成。

1. Video

HTML5 规定了一种通过 video 元素来包含视频的标准方法，该元素目前支持三种视频格式Ogg、MPEG4、WebM

视频格式细说参考:勿在浮沙筑高台 VIDEO ON THE WEB

2. Canvas+JavaScript+WebSocket+Node.js

这个方案是在我搜索资料中无意发现的一种，觉得比较新意，所以列在这里，可以作为一种参考或是实验的方式。请参考下面文章 使用 WebSockets 进行 HTML5 视频直播

PS:一个新鲜的技术或是标准都是需要一个发展的过程，我们在选择技术和标准的时候可以适当考虑一下新技术新标准，以此来推动该项技术或是标准的发展，不过这个听着简单做起来还是比较难的。现在YouTube已经开始全面html5化了。国内的优酷在看视频的时候已经有了html5选项。

ActiveX

ActiveX(百度百科) 是一个开放的集成平台，为开发人员、 用户和 Web生产商提供了一个快速而简便的在 Internet 和 Intranet 创建程序集成和内容的方法。 使用 ActiveX, 可轻松方便的在 Web页中插入 多媒体效果、 交互式对象、以及复杂程序，创建用户体验相当的高质量多媒体CD-ROM 。ActiveX插件以前也叫做OLE控件或OCX控件，它是一些软件组件或对象，可以将其插入到WEB网页或其它应用程序中。

PS：通过对该插件进行NPAPI接口的封装以后，可以在Chrome或是Firefox中调用，不过这项支持正在被google等公司抛弃。

Silverlight

Microsoft Silverlight是一个跨浏览器的、跨平台的插件，为网络带来下一代基于.NETFramework的媒体体验和丰富的交互式应用程序。Silverlight提供灵活的编程模型，并可以很方便地集成到现有的网络应用程序中。Silverlight可以对运行在Mac或Windows上的主流浏览器提供高质量视频信息的快速、低成本的传递。Microsoft .NET Framework3.0（Windows 编程基础结构）中的呈现技术XAML（可扩展应用程序标记语言）遵循WPF(Windows Presentation Foundation），它是Silverlight呈现功能的基础。对于开发设计人员而言，Silverlight是一种融合了微软的多种技术的Web呈现技术。它提供了一套开发框架，并通过使用基于向量的图像图层技术，支持任何尺寸图像的无缝整合，对基于asp .net、AJAX在内的Web开发环境实现了无缝连接。

PS：这个技术的出现，可谓是一统天下的气势，随着时间的流逝，“主角光环“在慢慢的消失，究其原因我估计没有几个人能够比较全面的分析或是说明白。希望在特定环境或领域能够有所作为。

Flash

Flash又被称之为闪客，是由macromedia公司推出的交互式矢量图和 Web 动画的标准，由Adobe公司收购。网页设计者使用 Flash 创作出既漂亮又可改变尺寸的导航界面以及其他奇特的效果。Flash的前身是Future Wave公司的Future Splash，是世界上第一个商用的二维矢量动画软件，用于设计和编辑Flash文档。1996年11月，美国Macromedia公司收购了Future Wave，并将其改名为Flash。后又于2005年12月3日被Adobe公司收购。Flash通常也指Macromedia Flash Player（现Adobe Flash Player）。2012年8月15日，Flash退出Android平台，正式告别移动端。

PS：从开始到现在一直被模仿从未被超越，不过随着退出移动界，html5的兴起，它的存亡也可能会是稍纵即逝，让我们珍惜现在所拥有的，怀着一颗感恩的心来静静的等待，等待。

总结

整体看来短期内ActiveX技术和Flash技术还是会作为Web视频的首选解决方案。
Html5的视频标准正在逐渐流行起来,对于移动端的浏览器视频方案目前来看只剩下html5标准，所以很期待。
对于一些特定行业或商务的应用还是可以选择比较适合自己的方案，比如Silverlight。
很期待园友们提出其他方案和好的建议，供大家参考。

参考资料

• 百度百科
• 博客园

欢迎转载，请保留著作信息