两种“软件陷阱技术”的比较
两种“软件陷阱技术”的比较
发布: | 作者: | 来源:
| 查看:1227次 | 用户关注：
引 言 　　单片机应用系统的抗干扰具体可分为软件和硬件两方面，其中，软件抗干扰以其设计灵活、节省硬件资源、降低成本等优势越来越得到广泛采用。软件抗干扰技术主要有“指令冗余技术”、“软件陷阱技术”、“软件看门狗技术”、“数字滤波技术”等。本文就软件陷阱技术对单片机应用系统抗干扰的原理与具体实现方法进行探讨和研究，给出实现软件陷阱技术的两种形式，并将该技术成功地使用在多个实际的单片机应用系统中，保证系
引 言 　　单片机应用系统的抗干扰具体可分为软件和硬件两方面，其中，软件抗干扰以其设计灵活、节省硬件资源、降低成本等优势越来越得到广泛采用。软件抗干扰技术主要有“指令冗余技术”、“软件陷阱技术”、“软件看门狗技术”、“数字滤波技术”等。本文就软件陷阱技术对单片机应用系统抗干扰的原理与具体实现方法进行探讨和研究，给出实现软件陷阱技术的两种形式，并将该技术成功地使用在多个实际的单片机应用系统中，保证系统的可靠运行。 　　1 程序跑飞和软件陷阱技术概述　　程序正常运行时，程序计数器PC始终指向正在执行的这条指令的下一条指令的第一个字节的程序存储器单元地址，这样就保证了单片机能够正确地读取每一条指令的各个字节，即CPU先读取操作码，再读取操作数(如果有操作数字节的话)。在MCS-51系列单片机中，程序计数器PC的寻址范围是0000H~FFFFH，共64 KB。用户应用程序中，根据系统要求，规定了程序运行的惟一路径。这体现在系统上电后，程序计数器PC有唯一的变化历程，保证了程序正常、有序地运行。程序跑飞是指系统受到某种干扰后，程序计数器PC的值偏离了给定的唯一变化历程，导致程序运行偏离正常的运行路径。程序跑飞因素及后果往往是不可预计的。　　在很多情况下，程序跑飞后系统会进入死循环而导致死机。这时，应采取有效措施引导跑飞的程序尽快退出死循环并迅速复位。实践证明，软件陷阱技术能有效引导跑飞的程序尽快退出死循环并迅速复位。　　2 两种软件陷阱技术的比较分析　　当单片机应用系统的CPU受到干扰时，不良影响的主要形式有：①非正常修改程序计数器PC指针；②改写可编程输出端口的状态；③非正常修改重要数据区的数据。以上三个方面的不良影响会使单片机应用系统程序失控，控制状态失灵，其后果是非常严重的，它甚至会使系统崩溃，造成严重的工业事故。以上几个方面的不良影响可以使用软件陷阱技术加以解决。现将这一技术的实现方法归纳总结为两种。　　2.1 软件陷阱技术实现形式之一　　单片机应用系统的用户应用程序一般由循环结构的主程序和中断服务子程序组成．将下面的软件陷阱程序段插入到用户应用程序中(如何插入的问题将在下面的第3点中详细讨论)，即在用户应用程序存储器不用区域写入代码．　　&当单片机应用系统工作正常时，单片机的CPU不会执行软件陷阱程序段；但是，当单片机应用系统受到干扰而程序跑飞后，由于程序计数器PC值错误，破坏了正常的指令格式，导致执行非正常指令，从而执行软件陷阱程序段，落入软件陷阱，将跑飞的程序引导到复位入口地址0000H。软件陷阱程序段中的连续2条NOP指令是为了增强“LJMP 0000H”被捕获的能力，即“IJMP0000H”不会被冲散，当程序跑飞后会得到完整地执行，从而使跑飞的程序纳入正常轨道。　　2.2 软件陷阱技术实现形式之二　　虽然上述的软件陷阱技术能实现可靠回复功能，但是有两个方面的严重隐患。第一，隐患主要是在对中断的处理上：首先，程序跑飞很可能是发生在中断服务子程序中，其次，一些未使用的中断很可能因为程序跑飞而被错误地激活，而这时只是简单地让跑飞的程序从头开始运行，就不能关闭已激活的中断，这样，单片机的中断系统会认为程序仍在处理中断，就不会再响应同级中断。第二，大部分单片机应用系统在上电复位初始化后，不希望在程序跑飞而用软件陷阱回复后又重新初始化。　　为了解决第一个隐患，当程序跑飞时，一定要想办法关闭可能发生的中断，然后再执行用户应用程序。大家知道，当CPU进入中断后，就只能用RETI指令关闭中断．解决第一个隐患的具体方法是，改变软件陷阱程序段：当程序跑飞后，将跑飞的程序引到0202H处，然后在0202H处完成关闭中断的工作，即在用户应用程序存储器不用区域写入代码“H”。需要注意的是，程序存储器不用区域的最后两个存储单元，一定要分别写入代码“00H”。　　NOP　　NOP　　LJMP 0202H ；前面的连续2条NOP指令是为了；增强“LJMP 0202H”被捕获的能力　　而在0202H开始的程序存储器单元进行如下的编程：　　ORG 0202H　　MOVDPTR，#ERRl　　PUSH DPL　　PUSH DPH　　RETI ；关闭第1级中断，并跳转到ERRl处　　ERRl： CLR A　　PUSH ACC　　PUSH ACC　　RETI ；关闭第2级中断，软件回复到0000H处　　这样，就保证了无论在什么情况下，都可以关闭2级中断。当然，如果没有中断被激活时运行了这段程序，也不会有什么不良影响。　　为了解决第二个隐患，可以在系统主程序入口处加一个软件开关来判别是上电复位直接进入0000H的，还是经过软件陷阱回复而进入0000H的，根据不同的判别结果执行不同的程序。　　单片机应用系统上电时，上电复位电路会使单片机处于复位状态。这一般称为冷启动。　　但是，软件陷阱技术使跑飞的程序回复到主程序入口地址0000H时，不影响特殊功能寄存器SFR的有效位。解决第二个隐患的具体方法是，设置上电复位标志。例如，以PSW．5作为上电标志位，当PSW.5=0时，表示是上电复位；当PSW.5=l时，表示是软件陷阱回复。图2是上电复位与程序跑飞后软件陷阱回复初始化处理框图。0000H是MCU的复位入口，程序启动后，首先判断是上电复位，还是程序跑飞后软件陷阱回复。上电复位是开机操作，要建立上电标志，并进行系统的完全初始化。程序跑飞后软件陷阱回复应该进行相关资源的检查与修复，以防止系统运行出错。另外，根据系统特点，需要保留一些过程数据，不得进行完全初始化。　　为了解决上述两个隐患，有如下具体编程。其中，START0为系统上电复位完全初始化于程序入口，ER-ROR为程序跑飞后软件陷阱回复应进行的系统部分初始化和相关资源的检查与修复程序入口，LOOP是用户应用程序功能模块入口。　 ORG0000H　 LJMP START&&& ORG 0100H&&& START： MOV C，PSW．5&&& JC ERROR&&& SETB C&&& MOV PSW.5，C&&& LCALL STARTO&&& LJMP LOOP&&& ERROR： ……&&& L00P： …… ；应用程序功能模块&&& LJMP LOOP&&& ORG 0200H&&& NOP&&& NOP&&& MOV DPTR，#ERRl&&& PUSH DPL&&& PUSH DPH&&& RETl ；关闭第1级中断，并跳转到ERRl处&&& CRRl： CLR A&&& PUSH ACC&&& PUSH ACC&&& RETI ；关闭第2级中断，软件回复到0000H处　 3 软件陷阱在用户应用程序中的安排位置　 软件陷阱程序段可以插入到主程序中或者中断服务子程序中。根据实际应用情况，对软件陷阱程序段的位置安排可以有5种方式。　 (1)在主程序的应用功能模块之间　 在单片机应用系统程序设计时，将软件陷阱程序段分散地放在各应用功能模块之间空余的程序存储器单元里。当用户应用程序正常运行时，这些软件陷阱程序段并不会执行，但是，当单片机应用系统的CPU受干扰而使程序失控时，程序计数器PC指针一旦落入这些陷阱区，就可以马上将跑飞的程序拉回到正确的轨道。这种方法的确很有效。软件陷阱的多少一般依据用户应用程序大小而定，一般1KB的用户应用程序有2~3个软件陷阱就可以了，具体方法如下：&&&& · 应用功能模块1&&&&&· 软件陷阱程序段&&&&&· 应用功能模块2&&&&&· 软件陷阱程序段　 (2)在闲置未使用的EPROM／Flash ROM空间　 在闲置未使用的EPROM／Flash ROM空间设置软件陷阱，即在这些闲置未使用的EPROM／Flash ROM空间写满代码“H”。值得注意的是，最后两个存储单元一定要分别写入代码“OOH”。当程序跑飞而进入此区后，便会被软件陷阱迅速拉回正常轨道。　 （3）在中断服务子程序中　 软件看门狗(soltware watchdog)实际上是软件陷阱的一个应用实例。以MCS-5l系列单片机为例，在系统初始化时将MCU内部的定时器／计数器T0设置为定时器，并将TO定时溢出中断设置为高级中断．如果系统采用6 MHz时钟，可以用如下的初始化程序段使TO定时约130 ms来形成软件看门狗：&&&&&· MOV TMOD， #01H ；将T0设置为16位定时器&&&&&· SETB ETO ；允许TO中断&&&&&· SETB PTO ；将TO定时溢出中断设置为高级中断&&&&&· MOV TH0，#0；给TO赋初值，定时约130/ms&&&&&· MOV TLO，#0&&&&&· SETB TR0 ；启动T0开始定时&&&&&· SETB EA ；允许CPU中断&&&&&另外，TO定时溢出中断服务子程序编程如下：&&&&&· INTO-PRo； MOV A，#02H&&&&&· PUSH ACC&&&&&· PUSH ACC&&&&&· RET1 ；中断返回到0202H单元　& 当用户应用程序运行正常时，在小于130 ms的时间内，CPU应该及时“喂狗”一一执行清狗指令“MOV THO，#0”和“MOV TLO，#0”。这样，TO就不会产生定时溢出，从而T0定时溢出中断服务子程序不会被执行。但是，当单片机应用系统的CPU受干扰而使程序失控时，CPU就不会及时执行清狗指令，以致于产生TO定时溢出中断，就可以马上将跑飞的程序拉回到正确的轨道。实现及时“喂狗”的具体方法是在用户应用程序中的适当位置插入指令“MOV TH0，#0”和“MOV TLO，#O”。实际上，TO定时溢出中断服务子程序就是一个软件陷阱，一旦执行T0定时溢出中断服务子程序，就是把跑飞的程序强行拉回到0202H程序存储器单元。由前面的分析可知，已经跑飞的程序可以迅速地被纳入正确的轨道。　 (4)在未使用的程序存储器地址空间　 对MCS-51系列单片机而言，程序计数器PC的寻址范围是0000H~FFFFH，共64 KB；然而，在实际的单片机应用系统中，一般没有使用到64 KB的程序存储器，这样就会余下大量的程序存储器地址空间。例如，系统中仅选用了1片2764作为程序存储器，其地址空间为8 KB。那么将有56 KB程序存储器地址空间被闲置。当CPU受到干扰而使程序计数器PC指向这些被闲置的程序存储器地址空间时，CPU取指令得到的指令代码为“0FFH”(这个结论可以根据图3所示电路分析后得出)。该代码是“MOV R7，A”指令的机器码。显而易见，当单片机应用系统的CPU受干扰而使程序失控时，程序计数器PC指针一旦落入这些被闲置的程序存储器地址空间时，CPU执行该指令不仅将错误地修改寄存器R7的内容，而且无法将跑飞的程序纳入正确的轨道。可以使用下面的软件陷阱技术解决这个问题。　 EPROM芯片2764的地址空间为0000H~lFFFH，译码器74LSl38的输出Y0为其片选信号，2000H~FFFFH为未使用的程序存储器空间。当程序计数器PC的值落入2000H~FFFFH空间时，一定有Y0为高电乎；当取指令操作时，PSEN为低电平，则74LS244的选通信号有效，所以74LS244被选中。进一步分析图3所示电路可知，当用户应用程序失控而程序计数器PC指向被闲置的程序存储器地址空间2000H~FFFFH时，总线驱动器74LS244被选通，这时CPU通过总线读入的指令机器码为020202H，正好是一条转移指令“LJMP0202H”，这样，使程序计数器PC指向0202H程序存储器单元。由前面的分析可知，已经跑飞的程序可以迅速地被纳入正确的轨道。　 (5) 对外部RAM写操作实旆监控保护而设置软件陷阱　 在单片机应用系统的外部数据存储器RAM中，一般保存了大量的预置数据和程序运行时产生的中间数据。外部数据存储器RAM的写入是由指令来完成的。当CPU受干扰程序跑飞而误执行了该指令时，就会改写RAM中内容，导致RAM中的重要数据丢失。为了减小这种RAM中数据丢失的可能性，应在外部RAM写操作之前，对写操作进行条件判断。如果条件满足才执行写入操作；如果条件不满足，则将写入操作屏蔽，并使程序落入陷阱，进入死循环。在程序落人死循环陷阱后，便只能由其他软、硬件抗干扰技术(如看门狗技术)使系统退出死循环陷阱，从而使系统恢复正常。具体源程序代码如下(不妨设要写入外部RAM的内容存放在累加器A中，要写入数据的外部RAM单元地址存放在DPTR中)：&&&&&· MOV 6EH， #55H&&&&&· MOV 6FH， #OAAH&&& &·& LCALL WRlTE&&&&&· RET&&&&&· WRITE：NOP&&&&&· CINE 6EH，#55H，TRAP&&& ；写入条件是(6EH)=#55H&&&&&· CJNE 6FH，#OAAH，TRAP且(6FH)=#OAAH&&&&&· MOVX @DPTR，A&&&&&· NOP&&&&&· M0V 6EH，#00H&&&&&· M0V 6FH，#OOH&&&&&· RET&&&&&·& TRAP， SJMP TRAP ；落入死循环陷阱&&&& && 4 结 论&&&&&& 与第1种形式的软件陷阱技术比较，第2种形式的软件陷阱技术消除了两个严重的隐患，因此，第2种形式的软件陷阱技术是一种有效实用的单片机应用系统抗干扰技术。本文所介绍的软件陷阱技术已成功地使用在多个实际的单片机应用系统中，保证了系统的可靠运行。
本页面信息由华强电子网用户提供，如果涉嫌侵权，请与我们客服联系，我们核实后将及时处理。
应用与方案分类
这段时间，巨头高通似乎有些“点背”。苹果欠的专利费不给还（国家广电总局广播科学研究院互联网技术研究所）
互联网电视作为一种新的内容服务方式正在快速发展。本文详细介绍了互联网内容传输技术发展历史，总结了互联网内容传输技术的三种方式。并针对目前国外主要的4种互联网电视技术方案进行了分析，重点研究了其中的关键内容，优势和不足。
互联网电视 流媒体 传输 方案
1． 互联网内容传输方式的转变
在几年以前流媒体传输领域就出现了一种发展趋势，流媒体传输由传统的RTSP MMS RTMP 等协议在线服务向纯粹的HTTP下载转变。现在已经有许多视频网站采用HTTP传输方案进行媒体内容的传输，形成这种转变主要有以下几个理由：
CDN以及服务器主机提供的网页下载服务比传统的媒体流服务要便宜；
传统的媒体传输协议通常很难穿过防火墙或是路由器，因为它们主要是基于UDP协议不定端口传输，而HTTP协议没有这个问题，HTTP基于80固定端口，网络设备对80端口默认支持；
HTTP方式媒体传输不需要特别的缓存或代理；
通过HTTP封装将数据传给用户比其他方式更加方便及便宜；
即使流媒体传输协议是设计用来专门传输媒体的，但事实上是互联网是基于HTTP方式来建设和优化的。这便产生了一个有趣的问题，“为什么要整个互联网去适应媒体传输，而不是让媒体传输适应互联网”。
2． 互联网内容传输三种形式
互联网上媒体传输主要有三种类型：传统流媒体、渐序性下载及自适应流媒体传输。
2.1 传统流媒体
RTSP协议是一个典型的流媒体传输协议，也是一个有状态的协议。有状态的意思是指从客户端连接上流媒体服务器的那一刻起，一直到客户端断掉与流媒体服务器端的连接，流媒体服务器一直保持着与客户端的连接状态。客户端通过play、pause、teardown等命令来与流媒体服务器进行通信。
在客户端和服务器端建立连接之后，服务器端开始稳定发送小数据格式的媒体流，传输协议通常采用RTP协议，RTP数据包是1452字节，这就意味着在一个1Mbps视频流中，每个数据包包含大约11毫秒的节目。RTSP协议既可以基于UDP传输也可以基于TCP传输。UDP比TCP更容易被防火墙或代理服务器阻隔，但是TCP容易产生延迟。
从另一个方面来说，HTTP是一个无状态的协议。如果HTTP客户端请求数据，那服务器端会及时响应，但是服务器不会记住客户端的状态，每个HTTP请求都是在一个时间会话中独立处理。HTTP无状态协议很难直接应用在媒体流传输上。Windows Media Service使用改进版本的HTTP协议，MS-WMSP协议作为微软媒体传输的基础协议。MS-WMSP使用标准的HTTP协议来传输数据和信息，同时也为此会话状态，有效的将HTTP协议转化成类似RTSP的传输协议。类似RTSP和Windows Media HTTP传统流媒体协议有两点比较重要：
服务器向客户端实时发送数据包，媒体流的码率在编码时被决定。例如：一个视频节目被编码成500Kbps的码流，那么传输到客户端的码率大约也是500kbps。
服务器只会发送部分未播放节目的数据包去填充客户端缓冲区。通常，客户端的缓存区是1秒到10秒之间。这就意味着，如果你暂停一个节目流10分钟，在这段时间内大约只有5秒钟的节目被下载到客户端。
2.2渐序性下载
另一种通常的互联网媒体传输形式是渐序性下载，它本质上和从网页服务器上下载一个文件差不多。大多数的播放器和媒体传输平台支持渐序性下载，渐序性来自于大多数播放器允许媒体文件回看，而后台同时也在下载节目。支持HTTP 1.1的客户端能够定位到未下载完整的文件位置。目前流行的视频分享网站包括：YouTube、Vimeo、Myspace、MSN 都支持渐序性下载。不像传统流媒体服务器很少能在一个时间段内够发送超过10秒媒体数据给客户端，HTTP网页服务器能够保证持续的节目数据传输直到整个文件下载完成。即使客户端在回看时暂停节目播放，节目数据依然会持续下载到浏览器的缓存中，保证用户能有良好的收看体验。这种方式也有它的问题，如果客户端找30秒内下载完成了10分钟的节目，而用户只观看了30秒钟的节目就退出观看，那就浪费了9分30秒的带宽资源。为了解决这个问题，微软IIS
7.0提出了一个名为“Bit Rate Throlling”的技术，它能够控制流媒体服务器的内容传输速率，以达到减少带宽浪费的目的。
2.3 HTTP为基础的流媒体自适应传输
HTTP为基础的流媒体自适应传输是一种混合型的传输方式，它的传输动作类似流媒体，但是实际上是基于HTTP渐序性下载。HTTP为基础的自适应流媒体传输的好处是使用了已有的HTTP协议而不是去开发一个新的传输协议。微软提出的Smooth Streaming和移动网络自适应码流传输都是HTTP为基础的自适应流媒体传输的应用实例，该技术能够实现持续的小数据的下载，而不是一个大文件的连续下载。在典型的HTTP为基础的自适应流媒体传输方案中，音视频节目被编码成许多小的数据片，这些小的数据片组成一个数据块，一个数据卡通常是2～4秒长。从编码技术角度，一个数据块正好就是一个GOP的大小，每个GOP里有一个关键帧，每个数据块或GOP的解码都是独立不依靠其他的数据块或GOP。
码流自适应技术有几个共同的技术特点，第一，它从同一个源产生多个不同码率的节目流以适应不同的带宽和不同的设备类型。第二.自适应分发文件以及码流传输的变化都是适应有效网络吞吐量和可用的CPU资源。第三：所有的操作对用户都是透明的，节目流的切换都在后台进行，用户很难注意到节目流的变化。同时，码流自适应技术运行特点也是相似的，当然也有几点关键不同点，相同点是所有的码流自适应技术都有几个相关的关键参考参数，例如：视频缓存区状态、网络有效吞吐量、CPU利用率以及丢帧后消耗的计算资源等，这些参数决定了何时去改变码流。不同厂家的在码流自适应技术一个关键的不同就在是否部署流服务器上。一种设计方案是由流服务器来实现不同码率节目的切换，而另一种则没有码流服务器，而是同时部署多个网页服务器或利用一台网页服务器来提供不同码率节目的传输，而用户端的设备通过监视终端CPU利用率、缓存区状态等参数以决定何时在不同的码率节目见切换。
自适应流媒体传输相对与传统流媒体传输具有以下几个优点：
（1）由于该技术方案能够充分利用广泛存在HTTP基础环境，它实施起来成本更低；
（2）它具备了更好的伸缩性和可达性，减少了最后一英里带来的问题；
（3）它能够让观众有更好的体验，而不需要内容提供商或运营商去猜测用那种码率传输更适合观众；
对用户而言它同样具有以下几个优点：
（1）快速播放以及拖动，因为播放或拖动节目都是在低码率下完成，等动作完成后客户端会主动切换到高码率上去；
（2）没有缓冲等待、没有链接中断、没用回看停顿；
（3）平滑的在不同码率节目间切换；
目前，不同的IT、软件已经互联网企业已经看到了未来互联网电视发展趋势，纷纷推出自己的解决方案，以下主要想介绍Apple、Microsoft、Adobe以及MPEG组织的互联网电视技术方案。
3．APPLE HLS
3.1.1 发展历史
Apple公司首次在2009年IOS 3.0中集成了HLS HTTP Live Streaming技术，截止到今天HLS是全球应用最广发的互联网电视传输技术协议，该技术被广泛应用到Apple公司产品终端和机顶盒中。在日，Steven Jobs报告中公开介绍了基于HLS的直播技术，同时宣布了APPLE TV 2。IPAD的成功很大程度上适合了用户使用IPAD看视频的需要。MeFeedia公司一向研究报告表明IPAD用户在线看视频时间长度是传统视频网站用户的三倍。
3.1.2 关键技术点
HLS主要基于TS的视频流或文件进行封装传输，HLS类似一个容器封装MPEG TS传输格式。TS是广播电视行业中采用的节目传输格式。HLS编解码采用MPEG-4或H.264，音频采用AAC。这样技术路线使得APPLE可以使用成熟工业标准，将其应用在互联网电视技术方案上几乎不需要改动，对现有标准兼容的越好，HLS便可以更快进入到产业链中。
HLS方案主要技术特点：
（1）节目源采用H.264/TS编码格式，可变码率；
使用流切片技术将一个完整的节目切成若干小片，通常是10秒每片，同时使用m3u或m3u8格式生成播放列表文件用来指导播放器如何播放文件切片；
（2）通过HTTP Server分发节目，同时提供合适的缓存。
HLS技术另外一个优势是能够实现动态自适应码率传输。相对于移动流媒体RTP传输技术，HLS能够根据终端用户带宽的可用性在终端而不是在前端视频服务上，实现对码率的切换。这种实现方式是为用户在无保障的网络上提供好的用户体验。
（3）索引文件说明了在同一个频道或文件中不同码率节目流的对应性；
（4）终端根据接收切变文件的时间长度来选择最合适的码率；
（5）每个切片文件最长10秒，所以接收设备可以自动适应码率变化；
开发基于HLS DRM客户端并不困难，Verimatrix,& Widevine, NDS, Latens与SecureMedia 一些DRM公司基于PC平台的DRM解决方案也可以适应HLS方案。如果进一步研究HLS中的DRM技术，会发现HLS只是描述了如何利用128位AES算法加扰HLS流，并没有说明如何从DRM 密钥服务器中获取密钥。这就说明DRM与HLS之间并不完全兼容。
3.1.4 优势
截至到2011年9月，APPLE已经出售了13亿台IPHONE，6千万台IPOD Touch，以及超过3千万台IPAD，因此HLS技术有着巨大的市场，特别是针对便携设备。HLS为不可靠的开放网络提供了一种有效的码率自适应方案。HLS使用成熟的H.264编解码技术，目前H.264解码芯片提供商有很多。HLS基于TS技术，使得它可以很容易集成到已有的数字电视系统中，许多IPTV DRM方案提供商能够提供相应的解决方案。
3.1.5 不足
自适应技术方案只限制在用户端，这种动态方法可能限制某些专业用户希望能够自己对特殊内容传输进行微调和控制；APPLE并没有支持主要浏览器集成HLS，缺乏插件使得利用Web TV收看HLS节目变得困难；HLS主要使用MPEG标准，兼容HLS技术的设备可能需要向MPEG LA支付一定的专利费。HLS中DRM加密采用是端到端整体加密实现，这样降低了系统的灵活性；目前，HLS只能提供一个音轨在一个视频流中。IOS 5能够提供可切换的音轨，但是音轨数量被限制在2个，而在Smooth Streaming或MPEG-DASH中则对音轨的数量没有限制。
3．2& Microsoft Smooth Streaming
3.2.1 发展历史
微软在1998年在Netshow Service和Windows Media Player 6.1中首次采用了根据客户端状态自适应节目传输码率的“stream thinning”的技术。该技术通过自动检测终端网络情况，自动减少帧率。在网络条件比较恶劣的情况下，客户端可能会终止整个视频的播放而只是播放声音。最早的多码率媒体流传输时在Microsoft 2000中，作为Windows Media Technology 4.0和Windows Media Service 4.1服务的一部分，和Windows
Media Player 6.4一起发布的。在2002年，微软在Windows Media 9系列产品中引入了 “Intelligent Streaming”。Intelligent Streaming依然采用ASF封装格式，但是在该技术的设计上，它将带宽侦测、streaming thinning、MBR以及更好的图像处理结合起来。随着技术发展，微软在2009年发布Microsoft Smooth Streaming是Silverlight 3.0相关标准。Microsoft在它的技术方案中采用H.264与AAC编码方案，也能够支持微软自己提出的WMA与VC-1或者能够支持3GP封装支持的编码方案。
3.2.2关键技术点
IIS采用MPEG-4 Part14标准格式作为其文件存储格式以及传输封装格式。Smooth Streaming方案中定义每个文件块/GOP作为一个MPEG-4电影帧，并将其存储在一个联系的MP4文件中以利于系统读取。一个MP4文件编码成一个码率。当客户端从IIS网页服务器上请求一个特点时间片段的节目源时，服务器将动态联系的MP4文件中寻找合适的电视帧单元（BOX），并且将它作为一个独立的文件发送。换句话说，Smooth Streaming方案中文件块是在服务器端接收到客户端请求时产生的，在服务存储中视频内容是以一个完整的单一码率文件形式存在。
（1）Smooth Streaming流格式介绍
Smooth Streaming格式涉及两个部分，封装格式和硬盘存储格式。Smooth Streaming中视频作为一个单一码率文件完整的存储在硬盘中，在传输给客户端的时候会转换成许多小的文件数据块。封装格式是用来传输时使用，而文件格式用来描述文件在硬盘的存储格式。MP4允许文件以一系列片结构组织及存储，这就意味着Smooth Streaming封装格式是文件存储格式的子集。
（2）Smooth Streaming文件硬盘存储格式
MP4文件的基本单位是“BOX”。这些“BOX”中即包含数据也包含元数据。MP4支持在一个文件内容以不同的方式来组织数据和元数据。在大多数媒体场景中，将元数据放在负载数据之前对于播放器的读取时非要有用的，因为播放器可以在播放之前可以更多的知道负载数据信息。然而，不太可能在整个数据流前写入元数据。较少的元数据信息意味着小的数据包头，有利于更快的启动播放器。基于以上理由MP4 文件格式中允许存在一系列晓得元数据、负载数据对，而不是一个长的元数据/负载数据对。下图描述了在一个Smooth Streaming文件中文件组织格式：
从上图中我们能看到在一个外壳中，文件以文件元数据信息（moov）开始，但是负载带元实际包含在片BOX单元中，在这些BOX中又携带了准确的文件片元数据（moof）和媒体数据（mdat），格式以mfra索引BOX结束。
（3）Smooth Streaming文件封装格式
当一个播放器客户端向IIS服务器请求一个视频时间片段时，服务器会在MP4文件中寻找合适的文件片，并将其取出封装完成后传输给客户端。文件片经过封装后可以有效提高传输效率。下图描述了一个MP4文件片封装结构
微软在MP4 ISO媒体文件描述格式的基础上自定义了BOX组织数据结构和BOX信息。为了区分Smooth Streaming文件和标准的“vanilla”MP4文件格式，微软使用了新的文件扩展：*.ismv(视频和音频)和*.isma音频
（4）Smooth Streaming 播放
Smooth Streaming自适应播放的设计原理本质上是将一个长的视频文件切成许多小的文件片。为了从Web服务器中获取这些文件片，客户端播放器只需要按照连续的逻辑序列0001.vid 0002.vid 0003.vid…下载文件即可。
在Smooth Streaming的设计方案中，微软使用了更加复杂的设计。视频文件不需要被切成无数小的文件片，而只是在传输时按照文件片的方式传输，而这些文件片实际上来自MP4文件中的GOP片段。这样的设计需要在服务器端和客户端实现以下两点改变：
服务器必须能将URL转换成在MP4文件中的准确的偏移范围；
（5）客户端能够支持更加开放的请求格式；
客户端播放器首先从Smooth Streaming服务器上获取*.ismc客户端文件块索引文件文件。该文件告诉播放器节目内容的编码格式、码率、清晰度以及可用数据块列表。
在Smooth Streaming中客户端请求文件数据块的URL以以下方式描述：
/NBA.ism/Qualitylevels(400000)/Freaments(video=)
在以上URL中出现的数字分别代表了编码码率和在一个单位时间段内（通常是100ns）片段开始位置的偏差值。在服务器端收到客户端请求后，Smooth Streaming在服务器文件块索引文件文件中查找码率，并寻找对应的.ismv .isma文件。然后基于tfra索引单元（BOX）找到相应片段（moof+mdat）和开始时间偏差值，读取相关的MP4文件封装后发送给客户端。这个部分的设计对于整个传输设计是至关重要的。客户端下载的内容会在网络中自动缓存，如果其他的客户端请求了同样的内容便会从缓存中获取这样就大大节省了服务端的压力。
3.2.3 优势
Smooth Streaming在一个码流中能够支持多声道和多个主题。这为用户提供了与收看数字广播想同的体验。相对于其他互联网电视方案而言，Smooth Streaming已经将DRM很好的集成到其中。虽然，微软也有自己的PlayReady解决方案，它也明确的支持其他的DRM厂家与Smooth Streaming的集成。在网页媒体领域，Smooth Streaming在高清直播中获得了很好的图像质量，与以flash技术为基础的视频网站相比，Silverlight能够根据客户端的解码能力去选择合适的节目码率进而保证节目的流畅。对于微软的互联网电视方案来说，这可能是一个优势也可能是一个劣势，微软互联网电视技术方案说明十分详细，使用了许多例子进行说明，这使得技术人员很容易理解该方案，但是可能会花很多时间进行部署。
3.2.4 不足
正如上文提到的，微软的互联网电视方案非常详细，所以部署起来很费时间，结果是该方案不如HLS那样容易被接受。尽管Smooth Streaming以Web媒体为目标，但是客户端必须嵌入Silverlight，及时是IE浏览器也必须安装额外的插件。像HLS一样，Smooth Streaming不能依靠网络中心服务器来管理带宽，这些工作必须依靠客户端设备。
3．3& Adobe HTTP Dynamic Streaming
3.3.1 发展历史
如果我们回看本世纪初开始整个互联网视频传播的发展历史，我们会发现Adobe毫无疑问是其中的主要贡献者，许多知名网站如：YouTube、Dailymotion、Hulu以及成百上千的视频网站都使用了Adobe的方案。然后，大多是视频采用的是.FLV格式（不是直播流媒体），无法支持DRM,也不支持码率自适应。Adobe Flash在1996年发布，根据Adobe公司的报告，在2010年全美98%的网页使用者使用Flash Player。然后第一个能够播放视频段的Flash payer是version 6.在2010年七月，Adobe发表了互联网电视方案，支持码率自适应机制，支持直播，支持Adobe自己的Flash
Access DRM方案。
3.3.2 关键技术点
从技术角度来看，HDS方案与微软的Smooth Streaming十分相似，HDS系统主要由以下几个部分组成：
一个以XML为基础的索引文件.f4m
包含MPEG-4编码格式内容的片文件.f4f
包含切片文件说明信息的索引文件.f4x
HDS支持H.264以及VP6视频编码格式，AAC和MP3音频编码格式。.f4m 文件块索引文件文件包好一个bootstrap，它相对于MPEG-DASH的初始化段，这能够指示终端播放器从哪一个片开始解码。在文件块索引文件中，如果有多种码率可选，播放器能够根据内容回看效果选择最合适的码率。播放器是用ActionScript语言编写，能够运行在Flash或者Adobe AIR框架下。Adobe提供了一个参考视频播放器，称为Open Source Media Framework（OSMF），在互联网上已经有一些flash/javascript播放器基于这种方式编写，这些播放器基本上是完全定制化播放HDS视频流。对于内容保护而言，HDS唯一支持的DRM方案是其自身Adobe
DRM系统，Flash Access服务器，Flash Access方案是一个很有特点的加扰系统，版权管理中有很灵活的控制权，它能够对保护层进行保护也能够对视频文件切片进行保护。
3.3.3 优势
Adobe成功在月在互联网早期发展过程中将其框架作为一种强制插件嵌入到网页中。同时，Flash插件到今天已经有能力自动更新，现在几乎所有的PC都能播放Adobe HDS码流。HDS在Adobe为VOD应用提供了丰富的文档，他们能够为开发送人提供一些参考源代码以支持对方开发有价值的第三方插件。
3.3.4 不足
Apple目前在Apple产品中不支持Flash。但是对于Android平板电脑和智能手机，Flash的支持非常依靠具体的Android版本，即使是特定Android版本，Flash支持也依赖硬件平台厂家。HDS只支持自己的DRM方案，从Adobe开放出来的文档中也很难看出Flash Access是如何工作的，尤其是直播应用。和Apple HLS一样，HDS码流目前只能提供一个音轨。在改进版的系统中对于点播节目能够提供可替换音轨，但是直播节目不具备这个功能。
3．4& MPEG-DASH
3.4.1 发展历史
2010年，3GPP和OIPF发布了自己的码率自适应方案，Adaptive HTTP Streaming（AHS, part of 3GPP R9）和HTTP Adaptive Streaming(HAS), 但是，这些协议没有兼容。MPEG-LA和ISO标准组织创立了横跨整个业界的HTTP Streaming协议小组：MPEG-DASH（Dynamic Adaptive Streaming over HTTP）,第一个DASH草稿在2011年2月发布。DASH技术目的是标准化HTTP Streaming技术以取代目前已经存在的不同厂家的技术方案，如：Microsoft
Smooth Streaming、Apple HTTP Live Streaming。DASH工作组已经在产业界取得了一定的支持，但是目前Adobe和Apple并未明确表态支持DASH。对于DASH来说现在它不支持HTML5 传输的编码节目，这就意味着它可能采用H.264或是WebM编码方式。最后，DASH是否免费还不知晓，这可能会影响一些潜在用户，如Mozilla。所有的HTTP为基础的码流传输技术都包含两个功能模块，节目码流和文件块索引文件，在DASH方案中节目码流称之为媒体表示，而文件块索引文件称之为媒体描述，如下图所示。
3.4.2 关键技术点
下图描述了MPEG-DASH前端HTTP服务器和MPEG-DASH客户端之间的逻辑关系。节目内容首先存储在MPEG-DASH前端HTTP服务器上，随后使用HTTP协议进行传输。媒体内容在服务上存储方式由两个部分组成：第一：媒体内容描述Media Presentation Description (MPD)，其中包括内容的文件块索引文件文件、内容的变量信息、URL以及其他特点。第二：文件片段，它代表了该节目所有的节目数据块。
在播放节目内容时，MPEG-DASH客户端首先要获取MPD文件，MPD文件可是通过HTTP、email、广播或者其他方式传输。通过解析MPD文件，email客户端可以了解节目的时间信息、节目的可用性、节目类型、清晰度、最大与最小带宽，以及几种不同编码码率的节目流、DRM信息、节目位置以及与内容相关的其他信息。利用以上这些信息，MPEG-DASH客户端选择合适码率进行播放。在节目内容开始传输并开始缓冲时，客户端继续从服务器端获取节目片段，并检测网络带宽变化。通过对网络带宽的检测客户端可以选择接受多大码率的节目。在MPEG-DASH中只定义了MPD和文件片段的格式，并没有定义二者的封装格式以及客户端如何获取二者。
3.4.3 优势
从纯技术的观点，在所有的互联网电视方案中MPEG-DASH看起来像最好的选择，它采用了好的设计思想，同时保持了很好的兼容性。作为被ISO和MPEG-LA推动的标准，与其他软件或互联网公司设计的互联网电视方案，它的设计更好满足产业实际。Ultraviolet很好了反映了“buy once, play anywhere”的设计思想，只有很少数的消费者是Apple或Android的忠实支持者，大多数用户拥有多个不同类型和厂家的终端设备；
3.4.4 不足
从用户端看，非常少的播放器采用MPEG-DASH方案，而且MPEG-DASH方案仍然处在起草阶段；Apple和Disney公司没有参加Ultraviolet组织，Ultraviolet是对Apple产品的一种潜在威胁，它允许用户在其他不同的设备上观看同一个视频流。
综上所述，对于哪种互联网电视方案是最好的，并没有一个明确的回答，所有的方案都有着优势和不足。现在很难预测哪一种互联网电视技术会在未来成为最终的赢家，就目前而言，由于Apple在全球取得的巨大成功，使得HLS方案在目前市场竞争中保持领先优势。当网络运营商在自有的IPTV专网中提供多屏服务时，视频服务的质量和视频数量是吸引用户的关键，而互联网电视对于想提供视频服务的新厂商提供了一种重要机会，新的竞争者不需要复杂网络基础环境就可以提供创新的服务。
参考文献：
[1] Lionel Bringuier, White Paper OTT Streaming – 2nd edition, ;
[2] Alex Zambelli , IIS Smooth Streaming Technical Overview, http://jmvm.vse.cz/wp-content/uploads/2011/05/t_IIS_Smooth_Streaming_Technical_Overview.
[3] I. Sodagar, The MPEG-DASH Standard for Multimedia Streaming Over the Internet, IEEE Multimedia, IEEE MultiMedia, October–December 2011, pp. 62–67.
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：3674次
排名：千里之外
原创：39篇
(29)(17)(2)