CN112929691B - 多用户全景视频传输方法 - Google Patents

多用户全景视频传输方法 Download PDF

Info

Publication number
CN112929691B
CN112929691B CN202110124180.4A CN202110124180A CN112929691B CN 112929691 B CN112929691 B CN 112929691B CN 202110124180 A CN202110124180 A CN 202110124180A CN 112929691 B CN112929691 B CN 112929691B
Authority
CN
China
Prior art keywords
video
user
bandwidth
video block
client
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202110124180.4A
Other languages
English (en)
Other versions
CN112929691A (zh
Inventor
徐跃东
张超
吴俊�
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fudan University
Original Assignee
Fudan University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fudan University filed Critical Fudan University
Priority to CN202110124180.4A priority Critical patent/CN112929691B/zh
Publication of CN112929691A publication Critical patent/CN112929691A/zh
Application granted granted Critical
Publication of CN112929691B publication Critical patent/CN112929691B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/231—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion
    • H04N21/23106—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion involving caching operations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234381—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by altering the temporal resolution, e.g. decreasing the frame rate by frame skipping
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2385—Channel allocation; Bandwidth allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2407—Monitoring of transmitted content, e.g. distribution time, number of downloads
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4331—Caching operations, e.g. of an advertisement for later insertion during playback
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/4402—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display
    • H04N21/440281—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display by altering the temporal resolution, e.g. by frame skipping
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44204—Monitoring of content usage, e.g. the number of times a movie has been viewed, copied or the amount which has been watched

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

本发明提供了一种多用户全景视频传输方法，具有这样的特征，包括以下步骤：步骤1，为多用户全景视频传输问题定义模型，并量化QoE指标；步骤2，码率决策器记录所有参与流媒体传输的客户端的状态，若用户数量≤5，使用全局最优化算法对全景视频传输带宽进行分配，并且使用遍历码率分配方案求解多用户的全局QoE最优解；若用户数量大于5，使用基于用户缓存队列长度的启发式分配方法对全景视频传输带宽进行分配；步骤3，客户端请求视频块，服务器端响应并推送数据，其中，步骤1中，对于用户c对视频块i的QoE，其具体定义为视口清晰度Q、帧内质量平滑度VI、帧间质量平滑度Vi B以及卡顿时长Ti S这四个因素的加权和。

Description

多用户全景视频传输方法
技术领域
本发明属于流媒体视频传输领域，具体涉及一种多用户全景视频传输方法。
背景技术
360°视频亦称作全景视频(Panoramic video或Omnidirectional video)，指能通头盔式VR设备、手机或拖拽电脑屏幕等方式让观看者在任何一刻能够看到360°全方位场景的视频。视频的采集通常借助多摄像头全景相机与相应的拼接算法实现，然后通过等距柱状投影(ERP,Equirectangular Projection)或矩形球面投影(CMP,Cubemap Projection)等投影算法将球面视频仿射到二维平面。
360°视频正在得到几乎所有主流内容提供商以及大众用户越来越广泛的关注。包括爱奇艺、Facebook、网飞以及Hulu等服务商都在加紧对360°视频技术相关探索以及生态的建设。但与此同时，360°视频传输所面临的挑战要远超传统的平面视频传输。为了向用户提供沉浸式体验，360°视频需要传输整个观影球面上足够清晰的内容，这使得360°视频若想达到与普通视频相同主观清晰度，其视频码率会极大增加，下面举例来说明两者在传输时体现出的差别。一般的视频常用PPI(Pixels per Inch)来衡量视频的清晰度，即屏幕上每英寸空间上的像素点数量；而在VR视频清晰度量化表述中，则使用PPD(Pixels perDegree)这一指标，它是指在每单位弧度上显示的像素点个数，两者在观察者与屏幕的距离一定时可以相互转换。对于一个PPD为40且人眼观察范围为48°的普通视频来说，其在传输时的码率大约在5Mbps左右；与之相对应的是对于一个360°视频，要达到同样的观看质量(相同的PPD)则需要占用接近400Mbps，80倍于普通视频的带宽。
许多研究做了深入的探索希望能在不降低观看者对视频质量的主观感受的前提下，降低传输360°视频所占用的带宽资源。基于方格(Tile-based)的360°传输方法在这一背景下被提出，但其缺点在于，与传统的自适应码率传输算法一样，目前所有基于方格的客户端侧算法性能受到客户端对网络带宽估计误差的极大限制，而基于方格的算法中视角预测误差量的引入更是给相关的算法设计提出了更大的挑战。
现有的全景视频传输算法在预测带宽与用户视角时由于预测的不准确会导致大量误差，造成QoE的大幅下降。造成这种情况的一个重要的原因在于目前的算法都是从客户端的角度进行变量的预测，但客户端对于整个网络有限的先验知识，限制了这类方法所能达到的性能上限。
发明内容
本发明是为了解决上述问题而进行的，目的在于提供一种多用户全景视频传输方法。
本发明提供了一种多用户全景视频传输方法，具有这样的特征，包括以下步骤：步骤1，为多用户全景视频传输问题定义模型，并量化QoE指标；步骤2，码率决策器记录所有参与流媒体传输的客户端的状态，若用户数量小于等于5，使用全局最优化算法对全景视频传输带宽进行分配，并且使用遍历码率分配方案求解多用户的全局QoE最优解，从而为每个用户分配合理的视频方格请求码率，若用户数量大于5，使用基于用户缓存队列长度的启发式分配方法对全景视频传输带宽进行分配；步骤3，客户端请求视频块，服务器端响应并推送数据，其中，步骤1中，对于用户c对视频块i的QoE，其具体定义为视口清晰度Q、帧内质量平滑度VI、帧间质量平滑度Vi B以及卡顿时长Ti S这四个因素的加权和，步骤2还包括，在得出分配结果后，码率决策器一方面向内部控制器上安装计量表项以控制特定对服务端与客户端的端到端的流速，另一方面将分配结果返回给相应的客户端。
在本发明提供的多用户全景视频传输方法中，还可以具有这样的特征：其中，步骤1具体包括：将一个完整的视频表述为一系列连续的视频块的集合，H＝{1,2,3,...,N}，每一个视频块包含有一段独立编码的长度为L秒的视频片段，最后一个视频块HN除外，其中每个视频块都会被编码为多个清晰度级别，并保存为不同的文件；令R＝{1,2,3,...,K}表示所有可以选择的码率级别的集合，并用ri∈R表示在视频传输过程中，对于第i个视频块决策算法所具体选择的视频码率；集合U则表示所有加入该视频传输系统的用户，其中用户总数为P，对于单独的某个用户端，自行维护一个缓存视频队列以避免卡顿的发生，当客户端开始下载视频块Hi时，其缓存队列的长度用Bi表示，另外用BWall表示决策器可用来分配的总的带宽资源，而某个特定的用户c被分配到的带宽为BWc。
在本发明提供的多用户全景视频传输方法中，还可以具有这样的特征：其中，步骤2中，视口清晰度Q的计算公式如下：
Figure BDA0002923373140000031
pVP指代用户视线焦点的坐标；ptile-j指代编号为j的方格的中心点坐标；M是组成一个视频块的方格的总数；函数distance(p1，p2)计算坐标点p1,p2之间的球面距离；θ(·)是一个最大值位于坐标原点的凸函数，它的作用是为视口内不同的方格赋予权重，距离用户注视点越近的方格将获得更大的权重，反之亦然，最后xj用于判断方格j是否位于视口之内：
Figure BDA0002923373140000032
h(·)是一个映射函数，它将方格文件的码率映射为人眼主观上对视频质量感受。
在本发明提供的多用户全景视频传输方法中，还可以具有这样的特征：其中，函数h(·)的实现方法为：使用结构相似性或图像峰值信噪比作为视频质量的映射函数，计算峰值信噪比首先需要计算均方误差，对于一幅图像来说，其均方误差为原无损图像与目标图像对应两两像素点之间差值平方的均值，其计算公式如下：
Figure BDA0002923373140000033
其中W是图像中的像素点总数，S为原无损图像，T为带噪图像，在此基础上，峰值信噪比(dB)定义为：
Figure BDA0002923373140000041
其中MAX是像素点可能的最大取值。
在本发明提供的多用户全景视频传输方法中，还可以具有这样的特征：其中，帧内质量平滑度VI用以下标准来度量：
Figure BDA0002923373140000042
其中，StdDev(·)函数计算集合内所有元素的标准差，
帧间质量平滑度Vi B为当前请求视频块质量与上一个请求的视频块的质量差值的绝对值，其度量方式如下：
Vi B＝|Qi-Qi-1|
其中，下标i代表视频块的编号，
卡顿时长Ti S的计算公式如下：
Figure BDA0002923373140000043
其中，函数d(ri,j)用于计算第i个视频块的第j个方格所对应的方格视频文件的大小；
Figure BDA0002923373140000044
表示下载第i个视频块过程中的平均带宽的预测值，
任意一个用户c的QoE模型公式为：
QoEi＝Qi-αVi I-βVi B-γTi S
其中，VI、VB和TS作为三个惩罚项加入QoE的计算当中，α，β，γ为三个惩罚项的相应权重，其根据算法的实际侧重点加以选择，
对于分配给用户c的带宽资源
Figure BDA0002923373140000045
添加两个约束分别对应瓶颈
Figure BDA0002923373140000046
将这两个约束合并，可以得到：
Figure BDA0002923373140000047
第i轮决策过程中，N个用户的整体视频体验质量QoEALL为：
Figure BDA0002923373140000051
通过以下公式对目标函数QoE引入多步决策：
OBJ:
Figure BDA0002923373140000052
其中，O表示决策次数，
在多用户的系统中，最终的目标是要最大化全体用户的视频观看体验，对应的优化模型如下：
find ri,j
Figure BDA0002923373140000053
Figure BDA0002923373140000054
Figure BDA0002923373140000055
ri,j∈R
在本发明提供的多用户全景视频传输方法中，还可以具有这样的特征：其中，步骤2中，启发式分配方法的核心是控制用户客户端的缓冲队列维持一个特定的长度，称为目标队列长度Btarget，基于缓存队列的方法如下：
Figure BDA0002923373140000056
其中，Cbase为基础带宽，其均分给每一个视频用户；Cextended为拓展带宽，Cbase+Cextended＝Call，Call为所有可用的带宽，拓展带宽专门用于对缓存队列长度小于目标长度的用户作带宽补偿，促使其缓存队列尽快回归到目标长度。
在本发明提供的多用户全景视频传输方法中，还可以具有这样的特征：其中，步骤3中，客户端通过以下步骤请求视频块文件步骤3-1，通过使用线性回归模型进行视口预测；步骤3-2，通过以下公式进行吞吐量预测，
Figure BDA0002923373140000061
步骤3-3，进行码率选择，若码率决策器采用全局最优化算法，客户端直接选用码率决策器给与的码率建议值，若码率决策器采用启发式分配方法，客户端获得的决策结果是它可用的带宽上限，此时对下一个要下载的视频块来说，首先给所有的区域分配最低的比特率，然后将分配的带宽和预测的带宽作比较，如果还有带宽资源剩余，计算会出现视野区域的区域并且将剩余的带宽等量地分配给这些区域，并选择小于分配得到的带宽最贴近的比特率；步骤3-4，与服务端进行通信，从服务端通过服务器推送功能得到视频文件，视频文件被打包为一个视频块对象压入视频播放器的缓存队列中；步骤3-5，周期性地从缓存队列中取得视频块并进行播放。
在本发明提供的多用户全景视频传输方法中，还可以具有这样的特征：其中，步骤3中，服务器端的响应过程包括：服务器端预先将待传输视频切分为不同清晰度级别的方格文件，并生成响应的媒体描述文件，当服务器端收到客户端的视频块请求时，查询方格文件是否存在，并将所有所需的方格文件通过HTTP/2支持的服务器推送功能一次性推送给客户端。
发明的作用与效果
根据本发明所涉及的多用户全景视频传输方法，因为其引入软件定义网络对流速的控制，在这个前提下，基于用户缓存队列长度的启发式算法以及基于用户视频体验质量建模的全局最优化算法，从网络全局的角度，统一调配可用的网络带宽资源，更准确地为客户端提供吞吐量约束，从而达到了减少视频客户端之间的资源争用，以达到提升算法传输性能的目的；并对特定情形下的客户端进行带宽补偿，从而实现更好的传输性能与用户体验质量。
附图说明
图1是本发明的实施例中多户全景视频传输系统的运行流程图；
图2是本发明的实施例中多户全景视频传输方法的工作拓扑图；
图3是本发明的实施例中软件定义网络交换机流速控制工作流程图；
图4是本发明的实施例中客户端与决策器交互示意图；
图5是本发明的实施例中多户全景视频传输系统的工作时序图；
图6是本发明的实施例中使用等距柱状投影到二维平面的全景视频的一帧画面；
图7是本发明的实施例中码率自适应视频传输示意图；
图8是本发明的实施例中基于方格的码率自适应全景视频传输示意图；
图9是本发明的实施例中QoE定义使用的高斯掩模；
图10是本发明的实施例中传输视频质量对比图；
图11是本发明的实施例中传输视频卡顿情况对比图；
图12是本发明的实施例中传输视频用户公平性对比图。
具体实施方式
为了使本发明实现的技术手段、创作特征、达成目的与功效易于明白了解，以下实施例结合附图对本发明多用户全景视频传输方法作具体阐述。
图1是本发明的实施例中多户全景视频传输系统的运行流程图；图2是本发明的实施例中多户全景视频传输方法的工作拓扑图。
如图1、2所示，本实施例提供了一种多户全景视频传输系统100及其多户全景视频传输方法。多户全景视频传输系统100包括服务器端10(又叫视频服务器或服务器)客户端20以及控制器30。
服务器端10的最核心的功能是作为一个HTTP服务器，监听特定的TCP端口，提供对HTTP文件请求的应答功能。具体来说，当有用户请求视频的媒体描述文件时，服务器端10会根据具体的URL找到相应视频的媒体描述文件并返回给客户端；当有用户发起方格文件请求时，服务器端10首先解析URL，从中获取客户端20想要的所有方格文件并保存在内存中，然后从视频数据库中一一查找获取每一个方格文件，通过服务器推送功能依次向客户端20发送。
客户端20包括视频播放器、视口预测模块、带宽预测模块、码率选择模块、服务器端通信模块、控制器通信模块、MPD解析器、HTTP2 API模块。
视频播放器用于从视频缓存中恢复并消耗已下载好的视频块。该视频播放器从抽象意义上来说是客户端缓存队列的消费者，它周期性地访问缓存队列并从中取出一个视频块进行播放，当播放器想要获取一个视频块但缓存为空的时候，播放器会启动另一个定时器去记录播放卡顿的持续时间。
视口预(Viewport)测模块用于通过使用线性回归(LR)模型进行视口预测。考虑过去的时间窗(t0-δ,t0]中的头部方向采样用来预测用户在时间t0+t的未来的头部方向，这里t0代表做出预测时的时间，δ决定了多少个过去时间的采样会被用于预测。头部的方向使用欧拉角表示，即偏航角，俯仰角，翻滚角，在这其中翻滚角的值被忽略因为我们用一个圆形区域去近似用户的视口。这种近似使得翻滚角与用户的视口无关。因此，线性回归是分别考虑偏航角和俯仰角来执行的。
带宽(吞吐量)预测模块用于对前N次视频块传输的带宽(吞吐量)取调和平均值。其公式为
Figure BDA0002923373140000081
其中，
Figure BDA0002923373140000082
是指下载视频块时的平均带宽。
码率选择模块，用于选择码率，即获得各方格的码率分别结果，并将其映射到具体的方格视频文件。若码率决策器采用全局最优化算法(又叫QoE模型法)，码率选择模块直接选用码率决策器给与的码率建议值；若码率决策器采用启发式分配方法，码率选择模块获得的决策结果是它可用的带宽上限，此时对下一个要下载的视频块来说，首先给所有的区域分配最低的比特率，然后将分配的带宽和预测的带宽作比较，如果还有带宽资源剩余，计算会出现视野区域的区域并且将剩余的带宽等量地分配给这些区域，并选择小于分配得到的带宽最贴近的比特率。
服务器端通信模块用于与服务器端10进行通信，从服务器端10通过服务器推送功能得到视频文件(包括媒体描述文件文件)。当码率选择模块获得各方格的码率分配结果，并将其映射到具体的方格视频文件时，服务器端通信模块通过将所有需要从服务器请求的文件名通过统一资源定位符参数的形式封装于HTTP头部，并向服务器端10发送。当服务器端10返回一个视频块内全部的方格文件后，服务器端通信模块将这些文件打包为一个视频块对象压入视频播放器的缓存队列中。
控制器通信模块用于与控制器30进行通信，该通信同样使用HTTP协议来实现。在启发式分配方法中，控制器通信模块会在一个视频块下载完成和一个视频块被播放器播放完成时向控制器30进行上报工作，并从控制器30获取返回的带宽上限；在全局最优化算法(QoE模型法)中，控制器通信模块还会额外上报自己的视角预测结果供控制器30的码率决策器32分析。
MPD解析器在视频开始播放前运行，其从服务器端10获取目标视频的MPD文件并且并且解析文件得到必要的视频信息包括视频长度、视频块长度、可选质量级别以及对应的比特率。
HTTP2 API模块由Nghttp2库支持，提供友好的HTTP/2应用程序接口包括服务器端推送功能。客户端20与服务器端10的HTTP/2通信都由Nghttp2库进行支持，而对于客户端20来说，主要使用到其提供的四个接口，如表1所示。
表1客户端用到的HTTP/2接口
Figure BDA0002923373140000091
综上，客户端20主要负责完成以下工作：(1)具体地去请求所需的媒体描述文件(.mpd,Media Presentation Description)与视频块文件；(2)作为视频播放器，它需要进行带宽与用户视角的预测，并能够播放传输的视频；(3)作为本文全景视频算法的一部分，它需要能与控制器30进行可靠稳定的数据交互；(4)最后作为视频的最终消费者，它需要能进行完善的日志记录以便进行后续的实验结果分析。
控制器30包括内部控制器31(又叫Ryu控制器)和码率决策器32(又叫外部控制器)。
其中，内部控制器31用于实现控制层的功能，是整个系统中负责流速控制的核心因素，负责管理和控制整个网络的转发与资源分配。具体地，通过内部控制器31实现了一个单表的四层交换机功能和相应的计量表功能，此外为了控制流速还实现了为软件定义网络交换机添加、删除、修改计量表的功能。之所以使用四层交换机是因为我们的计量表对于流速的控制是基于端的，也就是说当设定了针对特定客户目标(客户IP地址)相应的计量条目之后，交换机会监控所有转发目标为该ip的数据包，并且在流速超过限制时将多余的数据包直接丢弃，这样在TCP的拥塞控制机制下会自动调整发送速度。
值得一提的是，我们使用的CPqD软件交换机对于计量表的实现，使用令牌桶的机制。对于每一个计量项都会有一个相应的令牌桶，令牌桶的大小与计量带的限速正相关。
图3是本发明的实施例中软件定义网络交换机流速控制工作流程图
如图3所示，当数据包进入之后，判断剩余计量表中是否存在匹配项(步骤SA-1),若判断为是，就将其放入令牌桶并取走与数据包大小一致数量的令牌，令牌桶以固定速度补充令牌，然后判断流速是否超过该项中的计量带(步骤SA-2)，若判断为是(即当令牌耗尽还未来得及补充足够的令牌时)，新进入的匹配数据包就会被丢弃(步骤SA-3)。
码率决策器32是一个周期性运行着决策算法的HTTP服务器，借用Webpy模块来帮助快速搭建一个HTTP服务器框架。决策控制器32一共包含两个线程，一个是负责响应HTTP请求的HTTP线程，另一个是负责进行码率决策的决策器线程。
图4是本发明的实施例中客户端与决策器交互示意图。
如图4所示，每当客户端20向控制器30上报其当前状态时，HTTP线程会通知决策器线程进行决策动作，并将码率决策器32的返回结果通过同一个HTTP连接返回给客户端20。
其中，客户端20向控制器30上报状态只包含两个部分：一个是当前客户端缓冲队列长度，另一个是视角预测结果，由于上报的状态量十分有限，直接将数据放在HTTP头部的URL中进行传输，其格式为：http://<controller ip>/param？buffer＝xxx&viewpoint＝xxx。
客户端20获得码率决策器32返回的结果后，与之相应的是在模型方法中，码率决策器32直接返回码率分配结果，客户端20则直接应用该结果。而后码率决策器32调用Openflow协议向软件定义网络交换机安装计量表表项以限制端到端的流速，避免带宽争用，其中流速控制使用丢包的方式实现。
多户全景视频传输系统100进行多户全景视频传输的方法包括以下步骤：
步骤1，为多用户全景视频传输问题定义模型，并量化QoE指标。步骤1具体包括：
图6是本发明的实施例中使用等距柱状投影到二维平面的全景视频的一帧画面；图7是本发明的实施例中码率自适应视频传输示意图；图8是本发明的实施例中基于方格的码率自适应全景视频传输示意图。
如图6-8所示，在服务器端将待传输视频基于方格的方法在传统码率自适应传输(DASH)的基础上切割出来的一个个持续1秒的视频文件，进一步在空间域上进行划分为一个个方格(Tiles)，并生成响应的媒体描述文件。具体切割方法是将画面在水平方向上等分12个部分，在垂直方向上等分6个部分，共12×6＝72个方格。例如当选用的视频分辨率为3840×1920像素，则每个方格都是一个320像素×320像素的方形区域，视角宽度为30°。如图4所示，每个方格代表了球面画布上的一部分图像，每个方格将使用独立的编码并被编码为单独的文件保存在视频服务器上，与DASH算法一致的是每一个方格区域也会被编码出多个清晰度级别以供自适应码率算法进行选择，如在图4中，红色视野区域(所有序号6方格区域)内的方格客户端将请求高码率的方格视频文件；而视野以外的部分将请求低清的方格视频文件，并且距离视野区域的距离越远，选择的方格文件码率也就越低。
对于一个完整的视频，我们将其表述为一系列连续的视频块的集合，H＝{1,2,3,...,N}，每一个视频块包含有一段独立编码的长度为L秒的视频片段(最后一个视频块HN除外)，其中每个视频块都会被编码为多个清晰度级别，并保存为不同的文件；令R＝{1,2,3,...,K}表示所有可以选择的码率级别的集合，并用ri∈R表示在视频传输过程中，对于第i个视频块决策算法所具体选择的视频码率；集合U则表示所有加入该视频传输系统的用户(客户端10)，其中用户(客户端10)总数为P。对于单独的某个客户端10，自行维护一个缓存视频队列以避免卡顿的发生，当该客户端10开始下载视频块Hi时，其缓存队列的长度用Bi表示，另外用BWall表示决策器可用来分配的总的带宽资源，而某个特定的用户c(客户端10)被分配到的带宽为BWc。
对于用户c对视频块i的QoE，考虑四个影响因素：视口清晰度、帧内质量平滑度、帧间质量平滑度与卡顿时长。其中，视口清晰度指在用户视野以内的方格的整体清晰程度表现，用Q来代表视口清晰度；帧内平滑度指的是不同码率的方格在拼接后所形成的视频图像的分辨率平滑程度，用VI加以表示；帧间平滑度指的是前后视频块的分辨率变化剧烈程度，用Vi B表示；而卡顿时长Ti S则是下载当前视频块i可能带来的卡顿时间长度。QoE具体定义为视口清晰度Q、帧内质量平滑度VI、帧间质量平滑度Vi B以及卡顿时长Ti S这四个因素的加权和。
步骤2，码率决策器32得出分配结果并安装计量表。其具体过程包括：
码率决策器32记录所有参与流媒体传输的客户端20的状态，若用户数量小于等于5，使用全局最优化算法(QoE模型法)对全景视频传输带宽进行分配，并且使用遍历码率分配方案求解多用户的全局QoE最优解，从而为每个用户分配合理的视频方格请求码率；若用户数量大于5，使用基于用户缓存队列长度的启发式分配方法对全景视频传输带宽进行分配。在得出分配结果后，码率决策器一方面向内部控制器上安装计量表项以控制特定对服务器端与客户端的端到端的流速，另一方面将分配结果返回给相应的客户端。
其中，在全局最优化算法(QoE模型法)中，考虑四个会对用户主观感受产生影响的因素：
(1)视口清晰度，是指在用户视野以内的方格的整体清晰程度表现，我们用Q来代表视口清晰度。这一指标显而易见与方格的分辨率之间呈正相关关系，但受限于人眼对于高分辨率的辨识能力，这一关系并非严格的正比关系，视频的码率越高，额外的细节信息所能带来的人眼主观体验上的提升越有限，边际效应递减。
此外，在基于方格的视频传输中，并不是所有的方格都对体验质量有着相同的贡献。一方面，用户无法看到视口以外的方格视频，因此计算Q时只应该考虑视口以内的方格的贡献；另一方面，即使是适口内的方格视频，它们的重要性也不完全相同，用户总是对自己目光的焦点(Viewpoint)及其附近的区域更为关注，而很难察觉自己视野区域边缘地带的图像细节，因此对于视口内的方格在计算Q时也应该赋予它们不同的权重。综上，视口清晰度Q的计算公式如下：
Figure BDA0002923373140000131
其中，pVP指代用户视线焦点的坐标；ptile-j指代编号为j的方格的中心点坐标；M是组成一个视频块的方格的总数；函数distance(p1，p2)计算坐标点p1,p2之间的球面距离；θ(·)是一个最大值位于坐标原点的凸函数，它的作用是为视口内不同的方格赋予权重，距离用户注视点越近的方格将获得更大的权重，反之亦然，最后xj用于判断方格j是否位于视口之内：
Figure BDA0002923373140000132
h(·)是一个映射函数，它将方格文件的码率映射为人眼主观上对视频质量感受。函数h(·)有很多种实现方法，从图像的物理表现来说，可以使用结构相似性或图像峰值信噪比作为视频质量的映射函数，计算峰值信噪比首先需要计算均方误差，对于一幅图像来说，其均方误差为原无损图像与目标图像对应两两像素点之间差值平方的均值，其计算公式如下：
Figure BDA0002923373140000133
其中W是图像中的像素点总数，S为原无损图像，T为带噪图像，在此基础上，峰值信噪比(dB)定义为：
Figure BDA0002923373140000134
其中MAX是像素点可能的最大取值。例如在深度为8的灰度图中，每个像素点可能的最大取值为255。值得注意的是上述PSNR的计算方法适用于单通道的灰度图像，而对于彩色的RGB图像则需要计算多个通道分别的均方误差，求取平均值后再计算PSNR。
(2)帧内质量平滑度，与一般的平面视频视频传输不同，基于方格的方法中客户端收到的是一个个方格视频文件，将这些文件拼接以得到完整的360°视频块。这带来的问题是不同码率的方格在拼接后所形成的视频图像中存在清晰的不均匀性，这会影响画面质量的平滑程度从而导致用户体验质量的降低。对于帧内质量平滑度VI用以下标准来度量：
Figure BDA0002923373140000141
其中，StdDev(·)函数计算集合内所有元素的标准差。
(3)帧间质量平滑度，视频驱动的VoD点播与离线的本地视频播放不同的是，由于视频在时间轴上被切分，并且每个视频块可能请求不同码率的视频块，因此会导致视频的清晰度随时间轴发生波动，频繁且剧烈的清晰度切换会导致观看者发生眩晕症状，严重影响视频体验质量，因此在对视频块的请求中，我们希望清晰度保持尽可能的平稳。对于视频块之间的帧间质量平滑度Vi B，其度量方式如下：
Vi B＝|Qi-Qi-1|
其中，下标i代表视频块的编号，帧间质量平滑度Vi B为当前请求视频块质量与上一个请求的视频块的质量差值的绝对值。
(4)卡顿总时长，在视频播放过程中，当客户端缓存队列耗尽且未完成下一视频块的下载任务时就会发生卡顿。在之前的一些研究中，对于卡顿的严重性的衡量方式有两种，一种是计算卡顿的总次数，一种则是统计卡顿的总时长，在实施例中使用统计卡顿总时长的方法，卡顿时长Ti S的计算公式如下：
Figure BDA0002923373140000142
其中，函数d(ri,j)用于计算第i个视频块的第j个方格所对应的方格视频文件的大小；
Figure BDA0002923373140000151
表示下载第i个视频块过程中的平均带宽的预测值。
结合上述对于四个衡量指标的定义，可以得到对任意一个客户端的QoE模型为四个指标的加权和：
QoEi＝Qi-αVi I-βVi B-γTi S
其中，VI、VB和TS作为三个惩罚项加入QoE的计算当中，α，β，γ为三个惩罚项的相应权重，其根据算法的实际侧重点加以选择。
通过建立上述用户对于视频的体验质量模型QoE，使得能够将用户的主观上对视频的体验质量转化为能够参与计算的量化指标，而后需要在网络条件以及视频传输场景的约束下，最大化该指标以取得最佳的用户服务质量。约束条件主要涉及网络瓶颈、多用户公平性以及算法远见性。
(i)关于网络瓶颈
在全景视频传输场景中可能出现带宽瓶颈的位置主要有三处，首先是在多用户的内网中，从某个用户到网络的出口——软件定义网络交换机之间的逻辑链路带宽上限；其次则是软件定义网络交换机本身连接的外网的出口链路的容量，这一资源也是我们的算法的核心关注点，它对于我们的算法模型来说应该是一个已知量，供算法进行资源的分配；再次一个可能出现的瓶颈在从软件定义网络交换机的出口链路到相应的视频服务器之间的以太网黑盒之中，数据在因特网中的通信链路由数据通过的各网络结点的路由转发规则所决定，比起第一个可能的瓶颈所经过的从软件定义网络交换机到客户端的链路，其可能经过的网络节点数和网络设备的多样程度还有网络情况的复杂度都有极大的可能要高得多，因此也更有可能成为木桶的短板。
为解决上述问题，令
Figure BDA0002923373140000152
分别代表对于用户c上述三个可能的网络瓶颈处的带宽上限，则其中在软件定义网络交换机的控制之下
Figure BDA0002923373140000153
而
Figure BDA0002923373140000154
则不受系统的控制并会随着时间因网络状态的改变而不断波动。因此，对于分配给用户c的带宽资源
Figure BDA0002923373140000155
添加两个约束分别对应瓶颈
Figure BDA0002923373140000156
将这两个约束合并，可以得到：
Figure BDA0002923373140000161
(ii)关于多用户公平性
多用户公平性是设计多用户视频传输算法所必须面临的问题之一。与客户端侧的码率自适应算法以最大化自己的用户体验质量为目标不同的是，基于软件定义网络的网关侧算法希望通过整体地决策，为每一个用户分配带宽与方格视频请求码率，从而使得所有用户的整体视频体验质量达到最佳。在这个过程中，码率决策器32的决策结果可能会由于不同用户观看视频的特性或客户端历史状体的不同而产生一定的“偏见”，这种偏向性可能导致码率决策器过多地向某一个或部分用户倾斜带宽资源以获得多用户QoE之和的最大化，本发明中希望保证尽可能的用户间体验公平性。
对每个用户的QoE计算结果做对数运算，这样做的原因在于对数函数能够体现出比例公平的性质。因此第i轮决策过程中，N个用户的整体视频体验质量QoEALL为：
Figure BDA0002923373140000162
(iii)关于算法远见性
算法远见性这一概念针对的是QoE定义中的总卡顿时长项。实际的视频传输系统中，卡顿的发生对用户体验质量的影响是最为致命的，因此在一步决策控制中，视频卡顿总时长这一项在某种程度上显得不够合理，因为既然卡顿是必须要避免的，码率决策器完全可以将会引起卡顿发生的视频块下载时长作为一个单独的对于请求码率的约束项，即下载时长应小于开始下载时的剩余缓存队列长度，而不是将其与QoE的定义相结合。对于上述问题，我们使用滚动优化的策略来调和两者矛盾。首先来看如何在目标函数中体现滚动优化的思想：
OBJ:
Figure BDA0002923373140000163
为保证算法的远见性，在对全局QoE进行优化的时候并不只做单步的决策，而是同时计算并最大化接下来O次决策的全局QoE之和，取下一步的决策结果并在下一轮预测开始后继续优化其后O次决策的目标和。在引入多步决策之后，QoE定义中的卡顿时长项不在仅仅局限于保证下一步的决策不会引起卡顿，也同时保证了决策不会在未来一段时间内不会发生卡顿，避免了单步决策中决策算法的贪婪性会导致缓存队列持续处于接近耗尽的状态。
基于上述约束条件，在多用户的系统中，最终的目标是要最大化全体用户的视频观看体验，因此，对应的优化模型如下：
find ri,j
Figure BDA0002923373140000171
Figure BDA0002923373140000172
Figure BDA0002923373140000173
ri,j∈R
由于视频中方格的引入，导致决策变量的维度极高，提高了求取最优解的复杂度。针对这一问题，对于每个用户，将其决策变量维度降为1，再通过一个高斯掩模将这一决策结果泛化到每一个具体的方格上，具体方法如下：由于人眼总是对视线注视点附近的图像信息有最细致的观察，而对视野内边缘区的部分则往往无法感受到其细节信息，因此即使是落在视野内的方格视频同样有着重要性上的差异。
令j′为用户注视点所落在的方格的编号，将方格j′的码率作为高斯函数在原点上的取值，对每个方格j，计算其中点与方格j′中点之间的距离，对该距离取其高斯函数值，并以该值作为折扣因子乘以决策值得到方格j的码率决策结果，图9是本发明的实施例中QoE定义使用的高斯掩模。值得一提的是，这样计算得到的码率决策结果为一个连续值，而实际的码率等级却只有离散的几个取值，因此必须将决策结果映射到具体的某一个码率等级上。在这里我们使用的具体方案是向上取值法，即将决策结果向上取比其码率大的第一个可选码率的码率等级。
码率决策器通过求解该优化模型，为每一个加入视频传输系统的用户分配一个最优的码率选择版本并将该结果返回给每个用户。用户采纳该码率选择结果并根据该结果向视频服务器请求响应的视频方格文件。
启发式分配方法的核心是控制用客户端20的缓冲队列维持一个特定的长度，称为目标队列长度Btarget。其分配的基本思想为：首先将所有可用的带宽资源划分为两部分，一部分称为基础(Base)带宽，另一部分称之为拓展(Extended)带宽，因此有Cbase+Cextended＝Call，其中，Cbase为基础带宽，Cextended为拓展带宽，Call为所有可用的带宽。基于缓存队列的方法如下：
Figure BDA0002923373140000181
其中，基础带宽被均分给每一个视频用户(客户端20)；拓展带宽专门用于对缓存队列长度小于目标长度的用户作带宽补偿，促使其缓存队列尽快回归到目标长度。
步骤3，客户端请求视频块，服务器端响应并推送数据。其具体过程包括：
客户端通过以下步骤请求视频块文件：
步骤3-1，视口预(Viewport)测模块通过使用线性回归模型进行视口预测。考虑过去的时间窗(t0-δ,t0]中的头部方向采样用来预测用户在时间t0+t的未来的头部方向，这里t0代表做出预测时的时间，δ决定了多少个过去时间的采样会被用于预测。头部的方向使用欧拉角表示，即偏航角，俯仰角，翻滚角，在这其中翻滚角的值被忽略因为我们用一个圆形区域去近似用户的视口。这种近似使得翻滚角与用户的视口无关。因此，线性回归是分别考虑偏航角和俯仰角来执行的。
步骤3-2，带宽预测模块通过以下公式进行吞吐量预测，
Figure BDA0002923373140000182
带宽预测模块通过对前N次视频块传输时的数据吞吐量进行调和平均值计算得到的，吞吐量的预测主要用于在未能与决策器取得通信时自行决策时使用。
步骤3-3，码率选择模块进行码率选择。
若码率决策器采用全局最优化算法，客户端直接选用码率决策器给与的码率建议值。
若码率决策器采用启发式分配方法，客户端获得的决策结果是它可用的带宽上限，此时对下一个要下载的视频块来说，首先给所有的区域分配最低的比特率，然后将分配的带宽和预测的带宽作比较，如果还有带宽资源剩余，计算会出现视野区域的区域并且将剩余的带宽等量地分配给这些区域，并选择小于分配得到的带宽最贴近的比特率；
步骤3-4，服务器端通信模块与服务器端10进行通信，从服务器端10通过服务器推送功能得到视频文件(包括媒体描述文件文件)。然后，码率选择模块获得各方格的码率分配结果，并将其映射到具体的方格视频文件。服务器端通信模块通过将所有需要从服务器10请求的文件名通过统一资源定位符参数的形式封装于HTTP头部，并向服务器10发送。当服务器10返回一个视频块内全部的方格文件后，该模块将这些文件打包为一个视频块对象压入视频播放器的缓存队列中。
步骤3-5，视频播放器周期性地从缓存队列中取得视频块并进行播放。
服务器端的响应过程包括：
服务器端10预先将待传输视频切分为不同清晰度级别的方格文件，并生成响应的媒体描述文件。当服务器端收到客户端20的视频块请求时，查询方格文件是否存在，并将所有所需的方格文件通过HTTP/2支持的服务器推送功能一次性推送给客户端。
在本实施例中，由于对于每个视频块需要请求传输多个视频方格文件，因此使用HTTP2的服务器推送功能帮助传输系统减少多次请求、传输视频方格文件所导致的额外的网络开销。具体做法是，在客户端20的视频请求的统一资源定位符中通过参数的形式将所有需要的方格文件一次性告诉服务器端10，服务器端10依次将每个方格文件主动地推送给客户端20。
我们分别测试了流媒体传输系统在不使用SDN控制、为每个用户均分总可用带宽以及使用启发式分配和最优化模型分配方法下的性能表现。图10是本发明的实施例中传输视频质量对比图，两幅小图分别代表多个用户在多次测试中所达到的平均视频码率与视频QoE指标，可以看出系统在加入SDN控制后性能有着超过50％的明显提升，而启发方法与模型最优化的方法又在简单的均分带宽方法上进一步取得了20％～50％的性能提升。图11是本发明的实施例中传输视频卡顿情况对比图，横轴为总可用带宽资源，纵轴为各用户平均卡顿时长，可以看出引入SDN也极大优化了系统在视频播放流畅度方面的性能，而启发方法由于引入了目标队列的思想在这一指标中表现最为突出。图12是本发明的实施例中传输视频用户公平性对比图，我们用方差来衡量在同一传输算法下不同用户之间的公平性，可以看出由于在目标函数的设计中突出了公平性的重要性，因此基于最优化模型的方法在不同用户之间的流媒体效果表现最为均衡。
实施例的作用与效果
根据本实施例所涉及的多用户全景视频传输方法，因为其引入软件定义网络对流速的控制，在这个前提下，基于用户缓存队列长度的启发式算法以及基于用户视频体验质量建模的全局最优化算法，从网络全局的角度，统一调配可用的网络带宽资源，更准确地为客户端提供吞吐量约束，从而达到了减少视频客户端之间的资源争用，以达到提升算法传输性能的目的；并对特定情形下的客户端进行带宽补偿，从而实现更好的传输性能与用户体验质量。
此外，通过应用HEVC编码以及服务器推送功能，减少了基于方格的传输算法中划分方格所带来的额外编码消耗与网络传输延迟。
另外，本实施例的方法结合已有的全景视频数据集以及相应的用户观看视频的视角移动数据，对其加以仿真与对比，证明了在全景视频传输系统中引入软件定义网络控制的有效性，实验显示通过引入软件定义网络对流速的控制，传输系统全局性能能提升50％以上，同时能保证很好的用户间公平性。
上述实施方式为本发明的优选案例，并不用来限制本发明的保护范围。

Claims (7)

1.一种多用户全景视频传输方法，其特征在于，包括以下步骤：
步骤1，为多用户全景视频传输问题定义模型，并量化QoE指标；
步骤2，码率决策器记录所有参与流媒体传输的客户端的状态，若用户数量小于等于5，使用全局最优化算法对全景视频传输带宽进行分配，并且使用遍历码率分配方案求解多用户的全局QoE最优解，从而为每个用户分配合理的视频方格请求码率，若用户数量大于5，使用基于用户缓存队列长度的启发式分配方法对全景视频传输带宽进行分配；
步骤3，客户端请求视频块，服务器端响应并推送数据，
其中，步骤1中，对于用户c对视频块i的QoE，其具体定义为视口清晰度Q、帧内质量平滑度VI、帧间质量平滑度Vi B以及卡顿时长Ti S这四个因素的加权和，
步骤2还包括，在得出分配结果后，所述码率决策器一方面向内部控制器上安装计量表项以控制特定对服务端与客户端的端到端的流速，另一方面将分配结果返回给相应的客户端，
步骤2中，所述启发式分配方法的核心是控制用户客户端的缓冲队列维持一个特定的长度，称为目标队列长度Btarget，基于缓存队列的方法如下：
Figure FDA0003506367730000011
其中，P为总用户数；Cbase为基础带宽，其均分给每一个视频用户；Cextended为拓展带宽，Cbase+Cextended＝Call，Call为所有可用的带宽，拓展带宽专门用于对缓存队列长度小于目标长度的用户作带宽补偿，促使其缓存队列尽快回归到目标长度。
2.根据权利要求1所述的多用户全景视频传输方法，其特征在于：
其中，步骤1具体包括：
将一个完整的视频表述为一系列连续的视频块的集合，H＝{1,2,3,...,N}，每一个视频块包含有一段独立编码的长度为L秒的视频片段，最后一个视频块HN除外，其中每个视频块都会被编码为多个清晰度级别，并保存为不同的文件；令R＝{1,2,3,...,K}表示所有可以选择的码率级别的集合，并用ri∈R表示在视频传输过程中，对于第i个视频块决策算法所具体选择的视频码率；集合U则表示所有参与请求视频数据的用户，其中用户总数为P，对于单独的某个用户端，自行维护一个缓存视频队列以避免卡顿的发生，当客户端开始下载视频块Hi时，其缓存队列的长度用Bi表示，另外用BWall表示决策器可用来分配的总的带宽资源，而某个特定的用户c被分配到的带宽为BWc。
3.根据权利要求2所述的多用户全景视频传输方法，其特征在于：
其中，步骤2中，所述视口清晰度Q的计算公式如下：
Figure FDA0003506367730000021
pVP指代用户视线焦点的坐标；ptile-j指代编号为j的方格的中心点坐标；M是组成一个视频块的方格的总数；函数distance(p1，p2)计算坐标点p1,p2之间的球面距离；θ(·)是一个最大值位于坐标原点的凸函数，它的作用是为视口内不同的方格赋予权重，距离用户注视点越近的方格将获得更大的权重，反之亦然，最后xj用于判断方格j是否位于视口之内：
Figure FDA0003506367730000022
h(·)是一个映射函数，它将方格文件的码率映射为人眼主观上对视频质量感受。
4.根据权利要求3所述的多用户全景视频传输方法，其特征在于：
其中，函数h(·)的实现方法为：使用结构相似性或图像峰值信噪比作为视频质量的映射函数，计算峰值信噪比首先需要计算均方误差，对于一幅图像来说，其均方误差为原无损图像与目标图像对应两两像素点之间差值平方的均值，其计算公式如下：
Figure FDA0003506367730000031
其中W是图像中的像素点总数，S为原无损图像，T为带噪图像，在此基础上，峰值信噪比定义为：
Figure FDA0003506367730000032
其中MAX是像素点可能的最大取值。
5.根据权利要求3所述的多用户全景视频传输方法，其特征在于：
其中，所述帧内质量平滑度VI用以下标准来度量：
Figure FDA0003506367730000033
其中，StdDev(·)函数计算集合内所有元素的标准差，
所述帧间质量平滑度Vi B为当前请求视频块质量与上一个请求的视频块的质量差值的绝对值，其度量方式如下：
Vi B＝|Qi-Qi-1|
其中，下标i代表视频块的编号，
所述卡顿时长Ti S的计算公式如下：
Figure FDA0003506367730000034
其中，函数d(ri,j)用于计算第i个视频块的第j个方格所对应的方格视频文件的大小；
Figure FDA0003506367730000035
表示下载第i个视频块过程中的平均带宽的预测值，
任意一个用户c的QoE模型公式为：
QoEi＝Qi-αVi I-βVi B-γTi S
其中，VI、VB和TS作为三个惩罚项加入QoE的计算当中，α，β，γ为三个惩罚项的相应权重，其根据算法的实际侧重点加以选择，
对于分配给用户c的带宽资源BWc alloc，添加两个约束分别对应瓶颈
Figure FDA0003506367730000041
将这两个约束合并，可以得到：
Figure FDA0003506367730000042
第i轮决策过程中，N个用户的整体视频体验质量QoEALL为：
Figure FDA0003506367730000043
通过以下公式对目标函数QoE引入多步决策：
OBJ:
Figure FDA0003506367730000044
其中，O表示决策次数，
在多用户的系统中，最终的目标是要最大化全体用户的视频观看体验，对应的优化模型如下：
find ri,j
max
Figure FDA0003506367730000045
s.t.
Figure FDA0003506367730000046
Figure FDA0003506367730000047
ri,j∈R。
6.根据权利要求2所述的多用户全景视频传输方法，其特征在于：
其中，步骤3中，所述客户端通过以下步骤请求视频块文件：
步骤3-1，通过使用线性回归模型进行视口预测；
步骤3-2，通过以下公式进行吞吐量预测，
Figure FDA0003506367730000051
步骤3-3，进行码率选择，
若所述码率决策器采用所述全局最优化算法，所述客户端直接选用所述码率决策器给与的码率建议值，
若所述码率决策器采用所述启发式分配方法，所述客户端获得的决策结果是它可用的带宽上限，此时对下一个要下载的视频块来说，首先给所有的区域分配最低的比特率，然后将分配的带宽和预测的带宽作比较，如果还有带宽资源剩余，计算会出现视野区域的区域并且将剩余的带宽等量地分配给这些区域，并选择小于分配得到的带宽最贴近的比特率；
步骤3-4，与所述服务端进行通信，从所述服务端通过服务器推送功能得到视频文件，所述视频文件被打包为一个视频块对象压入视频播放器的缓存队列中；
步骤3-5，周期性地从缓存队列中取得视频块并进行播放。
7.根据权利要求1所述的多用户全景视频传输方法，其特征在于：
其中，步骤3中，所述服务器端的响应过程包括：
所述服务器端预先将待传输视频切分为不同清晰度级别的方格文件，并生成响应的媒体描述文件，
当所述服务器端收到所述客户端的视频块请求时，查询方格文件是否存在，并将所有所需的方格文件通过HTTP/2支持的服务器推送功能一次性推送给所述客户端。
CN202110124180.4A 2021-01-29 2021-01-29 多用户全景视频传输方法 Active CN112929691B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110124180.4A CN112929691B (zh) 2021-01-29 2021-01-29 多用户全景视频传输方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110124180.4A CN112929691B (zh) 2021-01-29 2021-01-29 多用户全景视频传输方法

Publications (2)

Publication Number Publication Date
CN112929691A CN112929691A (zh) 2021-06-08
CN112929691B true CN112929691B (zh) 2022-06-14

Family

ID=76168413

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110124180.4A Active CN112929691B (zh) 2021-01-29 2021-01-29 多用户全景视频传输方法

Country Status (1)

Country Link
CN (1) CN112929691B (zh)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114268835B (zh) * 2021-11-23 2022-11-01 北京航空航天大学 一种低传输流量的vr全景视频时空切片方法
CN114630150A (zh) * 2022-02-17 2022-06-14 儒安物联科技集团有限公司 一种适应用户多样性的视频流abr算法
CN114554252A (zh) * 2022-02-17 2022-05-27 儒安物联科技集团有限公司 一种适应用户多样性的QoE建模方法
CN114640851B (zh) * 2022-03-18 2023-06-23 广西昊华科技股份有限公司 基于质量感知的自适应全向视频流的传输方法
CN114979089B (zh) * 2022-04-25 2023-03-24 北京邮电大学 一种实时传输全景视频的系统和方法
CN115052182B (zh) * 2022-06-27 2023-07-21 重庆邮电大学 基于队列学习和超分辨率的超高清视频传输系统与方法
CN114900506B (zh) * 2022-07-12 2022-09-30 中国科学技术大学 面向用户体验质量的360度视频视口预测方法
CN115955580B (zh) * 2023-03-14 2023-06-06 江西财经大学 基于可伸缩编码的全景视频边缘缓存方法及系统

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108235131A (zh) * 2018-01-30 2018-06-29 重庆邮电大学 一种基于dash的全景视频自适应传输方法
CN109286855A (zh) * 2017-07-19 2019-01-29 北京大学 全景视频的传输方法、传输装置和传输系统
CN110235443A (zh) * 2017-07-18 2019-09-13 惠普发展公司有限责任合伙企业 虚拟现实缓冲
CN110248212A (zh) * 2019-05-27 2019-09-17 上海交通大学 多用户360度视频流服务器端码率自适应传输方法及系统
CN110266714A (zh) * 2019-06-28 2019-09-20 合肥工业大学 一种QoE驱动下的VR视频自适应采集与传输方法
CN110602506A (zh) * 2019-09-25 2019-12-20 咪咕视讯科技有限公司 视频处理方法、网络设备及计算机可读存储介质
CN112055263A (zh) * 2020-09-08 2020-12-08 西安交通大学 基于显著性检测的360°视频流传输系统

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10595069B2 (en) * 2016-12-05 2020-03-17 Adobe Inc. Prioritizing tile-based virtual reality video streaming using adaptive rate allocation
US10979663B2 (en) * 2017-03-30 2021-04-13 Yerba Buena Vr, Inc. Methods and apparatuses for image processing to optimize image resolution and for optimizing video streaming bandwidth for VR videos
WO2018193330A1 (en) * 2017-04-20 2018-10-25 Nokia Technologies Oy Method and apparatus for delivery of streamed panoramic images
US10757482B2 (en) * 2017-12-05 2020-08-25 Fdn. for Res.&Bus., Seoul Nat. Univ. of Sci.&Tech. System and method for predicting user viewpoint using location information of sound source in 360 VR contents
US10659815B2 (en) * 2018-03-08 2020-05-19 At&T Intellectual Property I, L.P. Method of dynamic adaptive streaming for 360-degree videos

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110235443A (zh) * 2017-07-18 2019-09-13 惠普发展公司有限责任合伙企业 虚拟现实缓冲
CN109286855A (zh) * 2017-07-19 2019-01-29 北京大学 全景视频的传输方法、传输装置和传输系统
CN108235131A (zh) * 2018-01-30 2018-06-29 重庆邮电大学 一种基于dash的全景视频自适应传输方法
CN110248212A (zh) * 2019-05-27 2019-09-17 上海交通大学 多用户360度视频流服务器端码率自适应传输方法及系统
CN110266714A (zh) * 2019-06-28 2019-09-20 合肥工业大学 一种QoE驱动下的VR视频自适应采集与传输方法
CN110602506A (zh) * 2019-09-25 2019-12-20 咪咕视讯科技有限公司 视频处理方法、网络设备及计算机可读存储介质
CN112055263A (zh) * 2020-09-08 2020-12-08 西安交通大学 基于显著性检测的360°视频流传输系统

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
QoE驱动的VR视频无线传输机制研究;杨军超;《中国博士学位论文全文数据库(信息科技辑)》;20210115;全文 *
Tile-Based Qoe-Driven Http/2 Streaming System For 360 Video;Zhimin Xu等;《2018 IEEE International Conference on Multimedia & Expo Workshops(ICMEW)》;20181129;1-4 *

Also Published As

Publication number Publication date
CN112929691A (zh) 2021-06-08

Similar Documents

Publication Publication Date Title
CN112929691B (zh) 多用户全景视频传输方法
Nathan et al. End-to-end transport for video QoE fairness
Xiao et al. Bas-360: Exploring spatial and temporal adaptability in 360-degree videos over http/2
Hooft et al. Tile-based adaptive streaming for virtual reality video
US20130304934A1 (en) Methods and systems for controlling quality of a media session
US10154074B1 (en) Remediation of the impact of detected synchronized data requests in a content delivery network
US9549043B1 (en) Allocating resources in a content delivery environment
CN105338372B (zh) 一种应用于游戏直播平台的自适应视频串流转码方法
US20140181266A1 (en) System, streaming media optimizer and methods for use therewith
Ramakrishnan et al. SDN based QoE optimization for HTTP-based adaptive video streaming
Yuan et al. Spatial and temporal consistency-aware dynamic adaptive streaming for 360-degree videos
CA2981983A1 (en) Method and apparatus for automatic discovery of elements in a system of encoders
Hu et al. Proxy-based multi-stream scalable video adaptation over wireless networks using subjective quality and rate models
CN105164982A (zh) 通过指派丢弃优先级来管理流之间的带宽分配
de Morais et al. Application of active queue management for real-time adaptive video streaming
Zhou et al. QoE-aware 3D video streaming via deep reinforcement learning in software defined networking enabled mobile edge computing
Aksu et al. Viewport-driven rate-distortion optimized scalable live 360° video network multicast
CN110099294A (zh) 一种针对360度视频的保持时空一致性的动态自适应流媒体码率分配方法
van der Hooft et al. Quality assessment for adaptive virtual reality video streaming: A probabilistic approach on the user’s gaze
CN111447511A (zh) 一种带有用户感知体验质量的带宽分配方法
De Cicco et al. QoE-driven resource allocation for massive video distribution
Yahia et al. Http/2-based streaming solutions for tiled omnidirectional videos
Feng et al. Perceptual quality aware adaptive 360-degree video streaming with deep reinforcement learning
Fu et al. QoE-based SVC layer dropping in LTE networks using content-aware layer priorities
Nguyen et al. An adaptive streaming method of 360 videos over HTTP/2 protocol

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant