英语原文共 6 页，剩余内容已隐藏，支付完成后下载完整资料
使用网络套接字的Android设备上的低延迟实况视频流
作者：Behin Molaei Tabari ; Jafar Habibi ; Abolhassan Shamsaie ; Alireza Mazloumi ; Pedram Beheshti
摘要：
互联网上的视频流近年来引起了很大的关注。目前，全球数据流量的50％以上被视频数据包占用，到2020年这个数字将超过80％。实时流媒体具有挑战性，因为它需要低延迟的实时传输方法。智能手机和平板电脑是新一代的个人电脑，能够完成我们日常的工作。两个移动设备之间的实时流媒体在很多应用中使用，例如：监控，视频聊天等。在本文中，我们提出了一种使用网络套接字将移动设备的实时视频流传输到另一个移动设备的方法。对于评估，我们已经在android上实现了一个开源库，可供任何想将实时视频流作为其应用程序的一部分的人使用，并证明我们的方法可以在不同情况下播放延迟小于2秒的远程视频。此外，我们的方法根据网络状况增加和减少延迟，以便为观众提供更好的观看质量。
I. 介绍
自从第一个视频内容通过互联网传播以来已经超过20年了[1]。但直到最近几年，用户体验才变得可以接受。低带宽，高延迟和极高的成本是这些年来用户关注的主要问题。幸运的是，在过去的几年中，视频流已经成为互联网的热门服务。许多商业视频传输服务已经可用，导致全球多媒体业务的巨大增长[2]。思科创建了一个报告[3]预测全球互联网的IP流量。根据这份报告，到2020年，全球大约80％的流量将是视频数据包。
我们可以将视频服务分为两类。（1）用于录像，电影和电视节目等录像视频内容的VOD 1 ; 和（2）现场视频，如现场直播，闭路监控和视频聊天。用户体验质量2在不同场景下会有所不同，但实时视频流媒体用户大多需要低延迟[4]。视频流中的延迟是指事件的发生时刻与观看者的播放时间之间的时间差[5]。
传统上，大多数标准采用UDP 3进行实时视频流传输，因为UDP具有较少的开销，并且可以支持实时流式传输。但是TCP 4流在过去几年已经变得非常流行[6]。它在像Internet这样的非托管网络中具有更好的QoS5和可靠性。更具体地说，像HTTP 6和HTTP / 2这样的网络协议现在更流行，因为它们在路由器和防火墙中得到了更好的支持，大多数服务提供商保证了这些服务的QoS。这些协议的最大缺点是它们的延迟很高，因为它们不是为实时通信而设计的。
智能手机和平板电脑等移动设备是新一代的能够完成我们的日常工作的个人电脑。这些设备使人们能够在任何时间或地点利用互联网服务 [7]。由于4G / LTE 7网络的高速运行，现在可以通过移动设备实现快速可靠的视频流。随着移动设备上视频观看的增长，这些设备的流量占互联网总流量的比例正在增长。在这方面，思科[3]预测2015年到2020年间移动数据流量将增长8倍。
在本文中，我们提出了一种实时在两部手机之间流式传输实况视频的新方法。我们已经将web-socket作为我们的通信协议与我们提出的新型帧处理器相结合。与同类方法相比，我们的方法有三个优势。（1）由于web-socket，它具有低延迟（根据我们的评估，少于2秒）; （2）我们的帧处理器的缓冲区大小可以适应不同的网络条件; （3）当网络状况改善并且缓冲区包含足够的数据时，我们的帧处理器更快地播放一些帧以减少等待时间。本文的其余部分安排如下。第二节概述了互联网上直播的相关工作。我们在第三节描述了移动直播视频流的挑战。在第四节中，我们介绍了流式方法，然后我们在第五节中描述了我们的实现。之后，第六部分涵盖方法评估，最后是第七部分是我们的结论。
1Video on Demand
2Quality of Experience
3User Datagram Protocol
4Transmission Control Protocol
5Quality of Service
6Hyper-Text Transfer Protocol
7Long-Term Evolution
II. 相关工作
通过互联网进行低延迟实况视频流一直是一个挑战。
RTP 8是托管网络中实时流媒体的最大标准协议之一。RTP从低延迟和简单性中受益，但在像互联网这样的非托管网络中效果不佳，因为高的数据包丢失和延迟会使观看者看到的视频不清晰。
WebRTC 9 [8]是一种用于设备间实时通信的新方法。它提出了一个新的JavaScript API来支持两个浏览器之间的本地语音和视频流。WebRTC使用基于UDP的会话在浏览器之间传输音频/视频数据。它具有适应性的方法来减少网络条件差的流比特率，反之亦然。与以前的方法相比，这种方法具有许多优点，并且它是当前可用于浏览器中视频聊天的最佳方法之一。[9]的作者，评估了移动用户的WebRTC视频流的性能。在某些情况下，他们的评估显示高达30％的数据包丢失。在他们的结论中，他们表示，这种方法在具有挑战性的网络条件下不能达到可接受的服务质量。
正如所解释的，在过去几年中，新方法的QoS已经大幅提高。但UDP的自然特性阻止了科学家们保证视频质量和QoE。这就是为什么新一代实时视频流方法正在从UDP切换到TCP [1]。
TCP通常有两种类型的流式传输：（1）基于推式和（2）基于拉式。在基于推送的方法中，服务器在准备就绪时将视频数据推送到客户端，但是在基于拉方式的方法中，客户端在需要时请求并从服务器下载内容[10]。
[11]的作者开发了一种低延迟HTTP流媒体，将实时延迟降低到1或2个时间段。他们提出了一种时序算法，可以在发布整个片段之前播放部分片段。虽然他们的想法非常有趣，但由于块的持续时间，延迟仍然非常高。
在[5]中，作者提出了一种使用HTTP 2.0 SPDY [12]推送将视频流推送给观看者的新方法。他们的工作设法在只要数据可用时就将视频片段推送到客户端。他们通过一个HTTP 2.0连接发送所有视频内容，提高了方法效率并减少了延迟。他们的评估显示，他们的方法将实时延迟降低到少于5秒。
谢里夫等人[4]提出了一种快速启动DASH的新方法。他们使用网络套接字来估计服务器和客户端之间的带宽。他们专注于视频加载时间，他们已经设法将其减少约50％。Petrangeli等人 [13]使用超短（100到500毫秒）的段，以减少客户端缓冲区的大小来减少延迟。使用这种方法，HTTP请求的数量增加，导致高的通信建立开销。他们使用来自服务器的主动HTTP 2.0推送来消除这些缺陷。他们还设计了一个框架来避免视频冻结。
III. 移动视频流的挑战
在移动环境中进行实时视频流传输更具挑战性，因为移动设备的硬件规格有限，不可预知的网络和用户寻求出色的QoE，因为大多数移动应用都是以这种方式构建的。
A.实时流媒体
实时流媒体需要实时编码器，协议和解码器。编码器应该实时对相机拍摄的帧进行编码，因此不会被遗漏。像H.264 AVC 10和H.265 HEVC 11这样的现代编解码器是复杂的并且具有算法很耗时，使得移动设备不能使用软件实时编码帧。这就是为什么一些称为VPU 12的硬件加速器被添加到现代片上系统中。这些硬件加速器能够实时编码和解码一些有限的码片。
网络延迟和抖动有时会使缓冲区不再运行，并且用户应该等待缓冲区重新填充。这一事件增加了延迟，并且可能一遍又一遍地发生。虽然大多数新方法忽略它，但为了减少延迟，我们提出了一种自适应延迟实时流协议，如果网络条件变得更好并且缓冲区包含足够的数据，则会更快地播放视频。
B. 网络地址转换的阻拦
从技术上讲，IP地址用于识别网络中的客户端。但在互联网中，大多数设备都在路由器或网关之后。网络地址转换（NAT）是在许多设备之间共享一个公共地址的最常见解决方案。在这种情况下，他们有一个本地IP地址，并且可以在他们的本地网络中访问。NAT打破了设备之间的直接通信，也阻止了面向Internet的请求[14]。因此，从另一个设备识别或访问这些设备是不可能的。要启用两个移动设备在NAT后面的通信，我们需要一个具有可从双方访问的有效IP地址的服务器。该服务器必须充当代理，从而启动这两方之间的通信。ICE 13 [15]是基于UDP的多媒体会话中的网络地址转换的阻拦的著名解决方案。该协议使用TURN 14创建两个设备之间的直接连接。
C.经验的质量
与台式计算机相比，移动硬件规格要有限得多，但用户期望这些设备有桌面级性能[16]。移动操作系统的用户已经养成了面对任何人都可以操作的好的，快速且简单的用户界面的习惯。因此，流式传输方法不应要求用户设置代理服务器或执行大量配置，它们不应该显示不全面的错误消息。两个移动设备应与一个简单的机制配对，用户应通过一些简单的按钮来观看视频。
图一 我们的视频流方法结构
D.移动网络
移动设备以各种方式连接到互联网，这与PC利用的方式大不相同。移动设备通常使用WiFi或数据载体，如3G或4G / LTE。移动设备的移动性和便携性使得实时通信变得非常困难。事实上，网络连接可能会在几秒钟内从WiFi转移到另一个例如移动数据。
8Real-Time Protocol
9Web Real-Time Communication
10Advanced Video Coding
11High Efficiency Video Coding
12Video Processing Unit
13Interactive Connectivity Establishment
14Traversal Using Relays around NAT
IV. 通过Web-Socket实时流式传输
在我们的方法中，我们使用网络套接字中继服务器在源设备和目标设备之间建立连接。由于知道大多数移动网络将客户端置于NAT之后，并且他们无法直接相互通信，中继服务器必须具有有效的IP地址并且可以在Internet中显示。一个设备作为来源，另一个作为观众。在图1中，您可以一眼就看到整个系统。
在源设备中，首先我们必须捕捉摄像头和麦克风原始数据，然后这些数据将在编码器中进行压缩。之后，编码的音频/视频帧会在FrameHandler中获得时间戳和多路复用。源网络套接字处理程序将数据包打包成多个块并发送到中继服务器。中继服务器从消息头中提取消息的目的地并将它们中继到目的地。
在查看器中，这个过程是反向的，因为查看器Web套接字处理程序是第一个接收编码数据的，它将这些数据重定向到FrameHandler。解码器从FrameHandler接收帧并解压缩数据，然后显示表面上的视频帧并通过扬声器播放音频帧。
我们已经提出了我们自己的FrameHandler来处理每一帧以及它的时间和缓冲。尽管使用H.264和AAC而不使用任何容器来传输视频数据，但FrameHandler会为每个帧添加观看器上播放它的时间的标签，同时还会在源设备中混合音频/视频帧并将其解复用。源设备中的FrameHandler只捕获来自编码器的帧，并为每个帧添加一个简单的时间戳。在查看器设备中，FrameHandler使用算法向用户平滑地显示视频帧。
FrameHandler在查看器设备中有三个阶段。
- 缓冲阶段 FrameHandler尝试填充缓冲区，直到BufferThreshold帧可用。然后它转到播放阶段。
- 播放阶段 FrameHandler将缓冲帧一个接一个发送到解码器，在结果帧之间充分等待，以实现流畅的视频播放。如果缓冲区变空，则会增加BufferThreshold并返回到缓冲阶段。如果帧数超出BufferOverflow，则会移至缓冲区溢出阶段。
- 缓冲区溢出阶段在这个阶段，FrameHandler知道缓冲区中有很多帧可用，所以流延迟很高，因为FrameHandler播放每帧的速度要快10ms以减少延迟。它也减少了BufferThreshold，因为它知道网络状况已经得到改善。
在我们的方法中，BufferThreshold是动态的，所以它可能会在不同的网络条件下发生变化。使用高缓冲阈值，在播放视频之前增加缓冲并提高延迟，同时使用低BufferThreshold，增加用户在播放之前必须在缓冲阶段等待的次数。在我们的方法中，我们每次发生欠载时都会增加BufferThresh-old。缓冲区溢出情况会减少。
我们的方法中的音频/视频解码器不知道关于时间的任何信息。当帧可用时，帧将被解码并显示在画面上/用扬声器播放。Frame-Handler知道何时以不同的阶段将帧提供给解码器。
V. 实现
我们为Android设备开发了一个开源实时视频流媒体库15。目前它使用在API等级为16或更高上支持的MediaCodec ，因此它可以在运行Jellybean或更新版本的设备上运行。我们使用H.264视
全文共11915字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[12177]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
