视频流的移动视频监控

基于视频流的移动视频监控GiovanniGualdi,AndreaPrati,Member,IEEE,andRitaCucchiara,Member,IEEE摘要：移动视频监控代表了一个新的解决基于计算机和基于人的监视办法，其一方面围绕无处不在的视频采集，另一方面围绕无处不在的视频处理、观看。为了达到这个目的，系统必需提供低延迟、低跳帧的高效视频流，即使系统在有限带宽网络。这项研究提出了MoSES（基于移动媒体流的视频监控），一个对于移动视频监控系统有效的PC和掌上电脑的客户端。它依赖H.264/AVC视频编码和GPES/EDGE-GPRS网络。自适应控制算法的目的就是实现低延迟与流畅视频间的最佳平衡。MoSES（基于移动流的视频监控）为基于计算机的视频监控应用提供优质视频流，用于对人的区分和跟踪。本文中提及新的通用流性能评价方法，其用于在不同的参数条件（延时、图像质量、视频流畅和帧丢失）中比较MoSES与现有解决方案，以及在对人的区分和跟踪方面的性能比较。关键词：H.264编码移动视频监控视频流引言得益于移动设备与无线网络的访问速度，近几年来多媒体社区的处处存在的多媒体接入（UMA）已成为共同的话题。研究中心和电信为来自世界各地的移动设备（如笔记本电脑、个人数字助理或者上一代手机）的处处存在的多媒体接入，特别是视频，提议了新的、灵活和高效的解决方案。这样的技术应用可能包括消费娱乐、数字电视广播、视频会议、电视医疗、遥控操作、军事应用和远程视频监控，所有这些应用都面临着共同的技术挑战。一方面，视频无论在网络上传输的数据量和计算资源数量方面都造成严重问题。另一方面移动设置和处处存在的多媒体接入需要通过不同的方式访问，并且通常受限于无线网络，即使是802.11无线局域网和HSPA（高速分组接入）、UMTS（通用移动通信服务）这样的3G网络，甚至是GPRS（通用分组无线业务）、EDGE-GPRS（增强型数据传输的全球演进技术）的2/2.5G网络。这些冲突的要求（高数据容量和有限的资源）使高效的编解码器不管是在下载和媒体流应用方面的需求更加突出。在视频数据方面，我们的目标是让UMA技术为个人用户以维持足够服务质量。尽管如此，在一些新兴应用上，数据品质与压缩系数必需针对苛刻的“非人类用户”进行评估，也就是软件处理和接收到的数据解释。本文重点在于这样的应用，特别是移动视频监控：此期我们涉及广泛的新一类实时视频监控应用，此应用案例的计算量不是在一个固定平台负责，而摄像机直接连接该系统平台。由于移动平台的存在，移动视频监控所有，与视频采集，处理，数据分析和相关的多媒体数据传输的问题变得更具挑战性，无论是在发送端或者是接收端，以及无线

互联。一词的“移动”的含义是相当模糊，根据上下文还可能会呈现不同的含义。例如，它可以不受制约留在一个固定位置安装，或者一个移动的设置，或者一个便携设备（比如掌上电脑和笔记本电脑），或后备电池供电设备。然而，在多媒体术语中“移动”一般涉及到连接。因此，我们假设参考移动视频监控系统是提供一个无处不在的无线连接（无论是在服务器上，客户端或两者都有）相反的“固定”将用于考虑与有线连接系统。用于移动视频监控体系结构的典型例子是如图1的三层架构。固定摄像机移动摄像机译码器的视频监控|2pdaS®#/类固定摄像机移动摄像机译码器的视频监控|2pdaS®#/类卜人电苗第三层图1通用移动视频监控体系结构第一层（发送端或编码器）是专门对实时数据源（摄像机）或者存储的视频进行编码的。编码的视频通过无线广播频道以尽可能广泛的覆盖范围发送到第二层（接收端或解码器）。接收到的视频一旦解码将在第三层处理；它可以是一个传统的人性化系统,它是由人工操作的视频分析或者以计算机为基础的移动物体自动提取和识别异常事件系统组成。这是不是唯一的移动视频监控可能的架构智能相机的发展使更多的实时处理任务转移到本地编码端成为可能。在一般情况下，以计算机为基础的视频监控算法的部分可以在第一层实现的，可以获得降低传输带宽和压缩的图像双重好处。然而，我们的重点依然是第一层的视频编码和媒体流，要求的任何监控任务的进一步措施：这一解决方案仍然是就第三层实施监控应用没有具体的设想前最灵活的。在我们的工作中，第一层将体现在一个标准的PC架构，并意识到标准视频编码器的实现往往通过嵌入式硬件实现。虽然整体构造，我们的重点将是最具挑战的现场摄像，以及现成的视频源的立即响应。有许多有趣的应用实例：在移动－固定情形：视频监控系统无线通信一个安装在一辆城市巡逻区域的警车的摄像头，一个装有摄像头的灾区监视机器人，一个在工地每天移动的安全摄像机，这些实时的视频流可能流向一个控制中心；反之，固定——移动的情形可能是一个警务人员在他的PDA观看收集于安装在一座建筑内移动/固定的摄像机（或者来自一个安装在移动车辆的摄像机的移动——移动情形）。在这项研究中我们提出了媒体流系统，叫做MoSES（基于移动媒体流的视频监控），有效的移动视频监控通用体系描述。MoSES支持不用状况下的视频流，针对带宽受到限制的低延时传输。此外，此视频系统为基于人或者基于计算机的正确分析提供足够质量的视频。为达到这个目的，我们提出了一个流参数自适应控制过程的优化。MoSES基于开源软件架构。原因有两个，第一，完整源代码可允许任何水平的修改和优化。第二，大部分开源软件或者组件可以而不同的体系结构交叉编译和/或操作系统以具体的调整：MoSES客户端意味着其不仅运行在个人电脑上，而且还运行在个人数字助理，因而夸体系结构软件是必需的。评估实时视频流既不明确也不简单。本文提出一个提供性能比较评估有效的图像分析新方法，通过四个关键参数，即延时，图像质量，视频流畅性和帧丢失。最后，我们对移动视频监控在运动体分割与追踪方面的上述参数比较MoSES和其他媒体流系统所取得的成果。本文的其余部分的结构如下:下一章节，我们定义有效的基于人和基于计算机的视频监控的必要条件。然后，第三节，我们回顾视频流媒体的一些商用和科研的方法，和有关移动视频监控工程。第四节提出MoSES的详情。试验结果（第六节），第七节重点描述使用的整套方法。第七节得出结论。二、系统需求移动视频监控要求视频直播，以保证在线观看控制现场。除了这个基本特征，为了定义一个成功的移动视频监控系统还有其他要求（如表1所示）。表1系统要求。“丁”和“一”分别代表“要求”和“不要求”#要求视频监控基于人基于计算机1Ubiquitousaccessibility无所不在的访问2Lowlatency低延时3Highimagequality咼质里图像Preferable较好4Videofluidity视频流畅Preferable一5Noframeskipping/loss无跳帧/丢帧一6Highframerate高帧速率一Preferable第一项要求视频编码充公适应不同仍然不提供全面覆盖的大宽带无线网络支持（例如WiFi或者UMTS/HSPA）。这项研究中选定GPRS/EDGE-GPRS网络作为移动数据服务，因为它在欧洲领土覆盖面广。这仅仅是实现可以提供基于IP的网络视频流并不损害系统的通用性的选择，鉴于可用的有效EDGEGPRS带宽和GPRS连接,MoSES将分别在80kbps和20kbps速率下测试，另外，在移动视频监控的视频信号源多种传输请求方面，将在20kbps和50kbps速率下模块四台摄像机视频传输。第二项要求低延时，因为监控系统应该具有对显示场景的变化的快速反应。况且，移动视频监控系统要求高质量图像（第三项）和视频流畅性（第四项）。两者都符合基于人监控的要求，和正确场景分析与视频识别要求的可取监控方案。这过程对噪声、环境变化很敏感，这是因为受人工编码和压缩量化的影响较大。因此，可用带宽越窄，视频压缩越大，越影响视频分析的正确性。视频监控范围的视频处理最基本步骤[1]：运动物体分割，对象和对象的跟踪分析。而最后一步在很大程度上依赖于应用程序的目标，分割和跟踪任务十分普遍：在分割和跟踪的降低了整个自动监测系统性能。就静态摄像机来说，分割的步骤通常根据背景抑制技术确定[2]，如比较实际像素值与静态背景模型对应点的相应值等等。很明显，改变像素值的帧压缩可以显着影响这一步骤，并使一个复杂的背景模型失效。因此，第三项至关重要。跟踪步骤通常根据帧内对象——跟踪配对和采取固定帧频的有效状态预测的跟踪算法确定。由此，第五项要求（无跳帧）是必需的。最后，在一个新的帧里搜索跟踪的范围与物体在两个帧之间的移位成正比。因此，第六项（高帧频）是为了防止过大搜索范围。大多数上述需要的要求大多数UMA服务和上一代视频流系统通常只是部分实现。另一方面，我们的MoSES系统专门为满足上述要求而设计的。它基于H.264/AVC（MPEG-4第10部分）[3]-[5],通过多种改进方法使流媒体自适应低容量网络。H.264/AVC保证更好的MPEG-2与MPEG-4图像质量和带宽占用的平衡点。三、相关作品视频流解决方案与架构多个视频流媒体解决方案处理步骤是视频采集，编码，网络传输和视频播放。两个流行的现成方案是基于流媒体技术的MicrosoftWindowsMedia和RealNetworks[6]。此系统的编码层目的是提供流媒体服务器功能等等，以处理密集型视频广播。他们需要强大的处理平台和/或面向服务器的操作系统。例如，WindowsMedia流媒体服务器只能在WindowsServer操作系统上运行。这些专利解决方案的主要目标是提供出于娱乐目实时和存储视频资源的大量大规模视频资源访问。因此，这些解决方案的延时相当高（如第六节所述），这与第二项要求冲突。况且，因为典型的用户都是非技术从业人员，往往它们主要在视频编码和网络视频流方面的设置相当有限的。无论如何，其在移动视频监控工作的表现情况是不容忽视。我们测定了两个WindowsMedia和RealNetworks的整体流性能表现，因为他们都提供了PC和PDA视频播放器。数值结果将在第六节讨论。Skype可能代表了最流行的音频和视频的免费软件工具了多媒体流播放、音频处理和视频。该系统的整体性能非常有趣，虽然它适用于移动视频监控有一些不足。特别是，设置灵活性甚至比上述工具粗糙，因为几乎一切都是自动处理。例如，抓取、帧尺寸、速度和视频比特率不可调。这种方法使得系统很容易用于音频/视频通话，但也很死板和不够灵活，肯定无法用于我们的目标。另外，根据第五部分介绍的方法，延迟的测量分析在这种条件下变得不可行。Skype意思为音频流，在视频支持方面不能说不行，产生的带宽浪费成为无线移动连接的关键问题。最后，Skype视频播放器当前只有PC版本。关于开放源码软件方面，VideoLAN（VLC）的客户端可能是最知名的可用工具。不同于以往所有的例子，VLC是设计用于研究或免费使用，不作商业用途；它提供了非常灵活和完善的设置，即达到了抓取视频细节、编码和网络流的最低水平。它支持多种视频压缩标准（包括H.264）和流媒体技术。但无论如何，我们的许多项目的要求使此系统受到强烈的限制。如第四节B所示，视频延迟（必要条件2）只能保持相当低的视频质量下降。关于带宽使用，H.264视频码率控制是非常严格的，不允许有优化。例如，H.264流媒体只允许在MPEGTS（传输流）封装：在［7］的研究表明，这是一个缺点，因为使用MPEG-TS/UDP/IP协议的堆栈比使用P/UDP/IP协议的堆栈多两倍多开销。最后，VLC控制的H.264视频参数不准确，因为它可以访问的参数的完整调色板，但却不能正确地处理它们。人为地针对低带宽进行偏离标准条件优化，将引入强烈的图像质量下降。另一种解决方案是适当地使用现有的组件专门针对移动视频监控设计和开发一个优化的系统。媒体流中最复杂的区块是视频编码和解码。由于对H.264编解码器的选择，我们根据计算性能和参数的灵活性比较了现有的编码引擎。工作性能要求必须执行的实时编码，相反地，如果配置了高编码配置文件H.264要求将非常苛刻。需要灵活调整编码器处理不同的需求，如高编码速度，高图像质量。JM参考软件，它是开源的，完全灵活和可修改的，但计算性能非常有限。相反地，英特尔集成性能基元提供一整套广泛的数字信号处理算法，其中也包括专门的H.264视频编码。此库经过优化，但不开源并且只能在英特尔处理器上执行。X.264［10］是今天开源H.264编码器之一，其在H.264标准下具有最佳性能和最高的完整性，基于这些原因它被选为图1第一层的基础块。关于对H.264解码器的选择，性能问题变得非常严格，因为我们不仅希望标准的x86架构上得到解决，而且CPU的有限计算能力时也能得到解决等等，如ARM架构的PDA。同样在JM和英特尔IPPH.264编码器上的考虑，对他们的解码器工具是有效的。从其他各种解码器，有很多是开源的，如果我们只考虑那些可以在PC和PDA上编译的解码器，那么我们的选择是有限的。我们基于FFMPEG选定解码器，因其处理能力大部分的H.264编码的能力和性能；它没有提供一个随时可用的PDA版本，但因为它是开源的，可以适当修改。这个库有额外的优势，即提供了许多不同的协议的网络流层实现。移动视频监控流视频监控在过去的十年已经达到了科学界的高峰期。就这一主题的认真调查文件已在2000年由Lu发表。它的报告和讨论信号处理的有关问题，并提出可能的解决方案。关于视频流，研究者们从不同角度解决问题。例如，其中一个研究者使用多请求的方法解决了服务器计算资源的分配问题。另一组论文的重点是系统架构，在双方的沟通模式方面（见参考文献［14］，其中的分析是基于真正的网络产品，但不考虑低容量网络）和数据同步（见参考文献［15］，考虑实时车辆视频流通信，即便基于802.11无线网络，也不适合普通移动视频监控）。有些研究提出了低容量网络系统视频流系统，如GPRS例如，Lim等人，见参考文献［16］。介绍了GPRS网络的基于PDA的视频直播系统。该系统是基于MPEG-4压缩，并包含在PDA上实现的优化算法。它可以实现编码端的21fps帧速率和解码端的29fps帧速率，并在128kbps下传输一个QCIF（176X144）视频。然而，他们的系统在通过GPRS传输时，帧速度降至2-3fps。此外，系统延迟的信息没有提供。参考文献［17］的研究，使用跳帧解决了GPRS实时视频传输的问题。Chuang等人，见参考文献［18］通过模块3G网络处理自适应的视频流媒体播放：建立发送和接收过程的统计模型，以避免保存缓冲区下溢与播放流畅。即使研究不清楚地处理延迟测量，并且假设一个附加的定时数据交换，适应视频播出的想法，以优化缓冲区管理将用于我们的研究工作中。在文献中已经设想移动视频监控无论是无线网络标准的视频流扩充，没有在远程端处理，但只有一个人远程控制操作［19］-［21］，或作为特殊情况下的分布式无线传感器网络，其中一种对应于视频传感器的传感类型［22］。此外，这些研究大多没有解决低容量网络问题。P.Mahonen在1999年发表了一个项非常有创意的研究。这项研究分析移动视频监控的关键问题，例如网络化和数字图像传输的要求。而且再者，与我们所做的相同，笔者评估视频监控最终应用中容易出错的传输和人工编码（特别是入侵报警，目标识别）。然而，主要是由于1999年该技术的不成熟问题。论文没有真正提出有关视频流在低容量移动视频监控网络的有效建议oLam等人提出了一个很有趣的研究类似于这项工作最终目标这一。无论如何，在他们看来，跳帧是在功能上使用帧的智能过滤以适合在低带宽要求一一只有通过非常积极的跳帧可承受近5kbps。正如前述，这个复杂的跟踪任务；再者，它要求移动一部分的计算到本地端的摄像头。体系构想MoSES的基本架构如图1所示。在这一节每一层将被细化。第四节A描述视频编码层（仅基于PC硬件开发）。解码层设计成两个不用的版本，根据客户端的计算资源，即基于PC（第四节B）和基于PDA（第四节C）.计算机的视频监控所使用的技术是基于SAKBOT（统计和基于知识的目标跟踪）［24］，一个移动目标检测和跟踪系统。A.视频编码层典型的媒体流系统编码层是由三个基本块组成（视频采集，编码和网络媒体流）加上进一步的控制步骤。我们的编码器层的目的是提供在视频源和压缩控制的高度灵活性，并保持延迟和帧丢失率最低水平。以下体系结构的独特方面是实现这些目标而特殊设计的。——多线程处理和管道：视频采集，编码和网络媒体流被专用线程通过循环缓冲区解耦处理（如图2）。经异步线程优化处理，每一个执行基本上是独立于其他的；这实现一个与简单串行处理相比降低了延迟的管道。最初的X.264源代码是为此修改的；低缓冲区占用：缓冲是必要的，以避免由于线程去耦造成视频数据线的损失；缺点是它引入了一些延迟，并因此应用程序被调整为保持在最低的缓冲区占用。图2视频编码器功能层划分实现这一目标的最好方式是设置抓帧速率等于（或稍低于）平均编码帧率；有第二个任务后编码器和网络流转化器之间的缓冲区并不重要，而着重于管理和保持缓冲区始终接近零占用率。——UDP流：原H.264编码的流持续的传输给网络流转化器并打包成固定字节大小的UDP数据报。应付网络上拥塞的优先发送，但这将付出数据报丢失的代价。尽管如此，得益于无线链路控制实施机制的自动重发请求，我们第六节的实验报告将显示通过EDGE-GPRS甚至是GPRS的传输是非常稳健的，因为数据报的丢失率极低，并且接收没有混乱。因此，事实上MoSES旨在没有额外的音频或文本同步下传送视频流，我们决定用原始的UDP代替RTP/UDP。如图2所示，开发是基于C#、.NET框架和一定的本地C/C++组件。特别是.NET框架只在非密集型任务中使用（如GUI和控制层）。B.PC视频解码器基于PC的客户端情况，解码器的功能层划分如图3所示。H.264解码需求的计算绝对低于编码，因此，这个基于PC的层的最关键的问题不是优化计算，更确切地说是高

效的网络缓冲和数据流管理。事实上，即使视频采集帧率（编码端）和播放帧率（解码端）被设置为相同的值，数据报的产生率（编码端）和数据报的提取率（解码端）因几个原因随时可能不同，比如无线网络不稳定，因操作系统任务而不同的CPU负载（无论是在编码器或解码端）等等。具体地说，下列程序采用以尽量减少延迟和保持从网络下行获得最佳视频质量。如图3所示。——动态缓冲区大小：一个足够长的时间内如果数据报产生率仍然高于数据报提取率，可能填满缓冲区和之后收到数据报将丢失（缓冲区溢出）。我们提出了缓冲区的大小动态地适应一个简单的算法：当输入输入超出X%时，缓冲区将为两倍，或者当它低于（100—X）%时减半。X值是经验估算且取决于网络的条件，缓冲区的初始大小和视

频比特率；视频比特率：即使延迟时间，由于显而易见的原因，直接关系到网络缓冲区

占用，调整该系统以保持缓冲区尽可能空，由于缓冲区下溢将会导致播放帧率倾向不均

匀。因此，实现低延迟和良好流畅性之间的最好权衡，播放帧率控制（见图3）一组规

则以保持缓冲区占用在T与T之间（典型值是T缓冲区的5%，T缓冲区的15%）—般LHLH说来，播放帧率在时间:上是两个值的函数：缓冲区占用（保持在TL和TH的缓冲区大小）和缓冲区的占用离散导数。自适应控制可归纳如下：FRtj•G+p),playbackifABt〉WoccFRt-i •\1—p),playbackFRtplaybackifABtFRtplaybackifABt〈—Wocc=SFRt-1playbackifFRt-1playback公式1^Bt,ABt'optimaloccocc(p )•1+ABt,<wocc>otherwise其中W定义为亘菇“的一个窗口（典型值是千分之几），这代表了一个缓冲区占用可持续变化的限制，如果持续超出…，该系统将在很短的时间结束缓冲区溢出或下溢。P是该自适应控制的反应系数（0<p<l,但典型值大约百分之几）。P越接近0,自适应控制作用越弱；最终当P=0时失效。 反作用随着P增加而增加，最终以一个不稳定的系统结束。二_二::的值在以下范围最佳：T〈Bt〈TaABta0TOC\o"1-5"\h\zLoccH occ<Bt〉Ta—W<ABt<0公式2occH occBt〈Ta0<ABt<WoccL occ换句话说，当缓冲区占用增加（或减少）的速度过快（也坯「』>许），控制将作用于播放帧率的增加（减少）。条件最佳时播放帧率保持不变。在所有其他情况下，帧速率通过一个正比于缓冲区占用变化的斜率因子略有调整。－解码器与显示耦合：在解码器和显示线程缺乏同步的情况下，将可能发生一个帧能正确在解压但不显示，因此失去，因为它被接下来解码的一个帧取代（帧覆盖效应）。帧流缓冲将解决这个问题，但它还将引入一些延时。另一种完全避免缓冲的方法是引入一个简单的同步解码器－显示，在一个该解决方案大量减少帧丢失，甚至对延迟有积极作用。帧被覆盖前，延迟解码器）直到帧被有效显示。如第六节C帧被覆盖前，延迟解码器）直到帧被有效显示。如第六节C所示,PDA的视频解码器图4显示了PDA解码器的构成。不同于PC版，由于这些设备的计算能力有限，基于PDA的解码器的成功实现需要特殊的解码器优化。尤其，视频解码和网络缓冲最关键的问题是进程和视频显示之间的数据交换。在这种严格的条件下，最适合的操作系统是嵌入式Linux系统，提供了开源的重要优势，如此能够对内存、网络和.进程管理进行低层次控制。遗憾的是，对大部分的设备和外围设备（如GSM/GPRS调制解调器）的有限支持阻止我们采用这一解决方案，从而在WindowsCE上寻求解决方案。如下每一个组件及其最重要的功能都是为一个基于PDA的解码器设计：一优化的显示控制：在基于PDA的解决方案的情况下，视频数据直接写入显存比依托操作系统的标准函数的计算非常省力。为此，显示控制是基于GAPI和DirectDraw，而不是GDI+函数。如需进一步加快控制，图像缩放和90度翻转我们可以使用预先计算的查表；用于适应需要播放的帧大小和方向；——进程间通信：解码和图形用户界面模块保持完全脱离于他们的进程（也就是它们运行在两个独立的进程），使每一个处理进程不会相互干扰（例如，当GUI模块调用无用单元收集程序时）如一个QQVGA视频，24位色RGB，帧率10fps，将产生4.6Mbps通信带宽，很显然，进程间通信（IPC）必须非常有效从而避免跳帧和保持视频流畅。通过本地UDP环或文件系统的数据交换是不可行的，这两个方法不能保持高数据传输速率且不损害系统的整体性能。此外，文件系统实际上是基于一个有限

数量擦写周期的闪存，基于IPC的文件系统将在短期内衰退对此的支持。影响IPC使用的最大因素是内存映射文件（MMFs）,也就是虚拟内存文件。这种方法允许线程间共享内存，性能与物理内存相媲美。自适应播放帧率：在基于PC的解码器所描述的自适应控制在PDA上成功实现需要重新讨论。由于WindowsCE不容许查询的缓冲区占用的UDP，必需在操作系统的UDP缓冲区缓冲区后追加一个应用程序的缓冲区（如图4）。另外，在第四节B提出的算法不能成功在PDA上实现，由于计算资源不能维持所需的帧速率，万一帧速度一定增加时（通常在 时发生）。为此，PDA解码器层采用了基于保持UDP缓冲区占用尽可能低的关键任务轻加权控制，使得尽量减少因播放中断引起的缓冲区下溢。给定一个值e，1的千分之几，作为如下控制：FRtplaybackFRtpFRtplaybackFRtpFRtj -g2,playbackifABt=0公式3occifABt〉0occ日从略高于一开始，在缓冲区占用大于0的情况下反应比其他情况下强。分析结果将在我们使用此参数的第六节C给出。此控制不是帧播放速率自适应优化算法（是为深入分析自适应播放，参见文献［18］）但我们的目的是验证，即使在功耗处理器一个简单的自适应控制无需进一步缓冲可显着提高视频播放的流畅性。关于缓冲区的大小和解码器显示耦合,PDA的解码器解码器实现在PC上所描述的同样的程序。V•性能评价评价一个视频流媒体直播系统的性能不是一个容易的任务，因为它主要基于以人类接收方式的视频源感知。我们提出与我们的要求一致的四个方面定量测量方法。另外，如下；提出评估的移动视频监控系统性能措施。1） 图象质量：它可以方便地测量PSNR（峰值信号的信噪比），它给出编码和传输过程引入的失真程度。即使这不完全对应的方式我们人类视觉系统的质量评估，但它是一种简单、而众所周知的方法来衡量图像质量。2） 视频延迟：没有普遍接受的分析方法测量延时的方法。一种近似的测量可以通过同一时间服务器的编码和解码单元之间的同步获得，同时，修改编码器以加速，再加上编码的帧，还有抓取的时间戳。然后，解码单元检测解压缩帧的显示时间扣除时间差［参见文献26］。这个程序有几个缺点：一方面为了测量得到准确的时间差，必须经常与时间服务器同步。这将既浪费CPU周期，又浪费带宽；而且每一帧嵌入时间戳将进一步导致带宽的浪费。此外，这一类的测量需要修改的视频采集核心函数、网络和显示，因此，它适用于开源代码,但并不适用于例如我们需要比较的WindowsMedia和RealNetworks

非开源系统。因此，必须使用另一种方法测量延迟。Schmidt［见参考文献27］提出了一个测量合成多媒体数据（视频，音频和文字）延迟的方法，即通过多个传感器观察媒体播放器。我修改和扩展了实时视频数据的方法。帧数目叠加在每一个录制的视频。然后，通过压缩和流处理后，我们既在编码单元播放，也在解码单元播放。我们称之为:，一个给定的时间常数，二和二'士：三分别显示在编码器和解码器的帧号。我们定义时间？使 。也就是两边同时看到同一个帧号的时间，隐含条件是「门。我们叫土心为编码器两个帧的时间差，这是不变的，因为抓帧速率是常数；在这个条件下一般时间:近似为 --同时，利用延迟的定义I?三？-？，我们可以写成：enc4decL仏t-—tencenc4decL仏t-—tencenc图5。实验方法测量延迟。（a）和（b）是同一个摄像机的两帧，帧号分别为1702和1718。流会话（如图（c））,由于延迟，当解码端显示（a）时编码端显示的是（b）帧。这个过程需要对视频帧嵌入帧编号然后它可以使一个工具自动识别图像上的数字，使用普通的数字可能会产生问题，因为强烈的图像压缩引入失真。出于这个原因，我们倾向于采用基于代码的数字表示。二进制编码的帧号叠加在每个图像的一小部分。更具体地说，白色和黑色的色块分别用来代码1和0。图5显示了这种方法的快照。最左上角两个色块是静态的，用途是用于校准。视频会话发起并且在双方的屏幕播放的视频编码器和解码器，物理位置上是相互靠近的。同时，外接高帧频摄像机获取并存储在两个屏幕上的处理的视频流变化（如图5（c））。得到的视频使用简单的图像处理算法处理，并通过识别黑色和白色块色块自动计算二□和 延迟。该工具非常灵活因为它可以地非开源系统测量时间，也就是WindowsMedia和RealNetworks。3）帧丢失：下面的公式丢帧量化二-利用同一帧号编码的方法：有- ， 是外部摄像机的离散采样时间，是录制视频

的普通帧。LF（（的普通帧。LF（（t）显申(j)where申（j）=J, 处FNdec（j）<1 公式（5）人FNdeCj）_1,otherwise.换句话说，已知编码的帧速率是不变，并且外部相机帧速率比编码和解码的帧速率产高得多，如果被采集相机抓取的两个连续帧包含相同的数字或连续数，表明没有帆丢失。帧的损失可能是由于网络数据报丢失（这最有可能引起连续数帧的丢失，由于使用高压缩率和有限的帧大小，一个数据包通常包含多个帧）由于压缩解码帧跳跃或覆盖。由于上述GPRS和EDGE，GPRS高度可靠性，在下一节我们将证明因为压缩跳跃和解码器帧覆盖造成的帧丢失，这主要影响是由于网络故障。4） 视频流畅：视频流畅可以衡量解码器播放的两个帧间的时间差的趋势。这些信息可以再利用帧编码计算。在最好的情况，-:注是常数且等于-:心，相反二注越离散，视频播放期间丢失越多5