影音流传输方法、影音装置以及影音提供装置

摘要

本发明公开了一种影音流传输方法、影音装置以及影音提供装置。当网络发生壅塞的一段时间中，本发明所提出的适应网络带宽的实时影音流系统及其方法，能使影音接收者平顺且正确地播放出此段时间内尽可能多的影音数据、或对影音提供者/接收者有意义的影音数据，且播放进度跟影音提供者提供的最新进度的差距须维持在一固定范围内。在一种实施方式，当影音流存在其它不同传输比特率的流时，影音接收者可以依据自身网络状况，尽快切换到不高于可用带宽的最高传输比特率的流来收看。

说明书

技术领域

本发明提出一种影音流传输方法、影音装置以及影音提供装置。

背景技术

现今人们非常习惯使用网络来收看实时的(1ive)影音流，例如大型 比赛或表演的直播、道路或大楼的监控、游戏画面撷取直播、远程教学、 在线实时新闻、灾难现场画面直播等。因为网络有多变的特性，所以影音 接收者会使用一个数据缓冲器来储存几百毫秒至几秒不等的影音数据，来 减缓网络延迟抖动所造成的播放不连续性。然而，这个简单的做法并不能 使实时影音流的传输适应网络的变动。当网络壅塞时间长到令缓冲器的数 据耗尽，影音接收者的传统播放器有下面两种反应。一种反应为不放弃任 何未播数据，暂停播放一段时间直到缓冲区又有一定量数据再继续播放， 但如此会造成收看进度与实时进度落差变大。另一种反应为丢弃任何接收 时间超过播放时间的数据，但这很可能会造成之后的画面不能正确呈现。

为了解决上述问题，这十几年来有许多方法被提出。其中有一种叫作 比特流切换(Bitstream Switch)的做法有逐渐变为趋势的倾向。此做法是 把一个节目流同时做出不同传输比特率(Bit Rate)的流。影音接收者在适 当时间点依据自身的网络环境，从上述流中选择不超过可用带宽的最高传 输比特率的流来观赏。这个做法的好处是影音提供者仅需就大多数使用者 感兴趣或有办法接收的几种传输比特率(通常为3～5种)进行压缩即可， 故不会对影音提供者造成巨大负担。另外，影音接收者得到的收看质量， 大多情况下也很接近该网络环境下所能达到的最佳质量。

目前市面上至少已有两种免费软件产品可以提供实时产生不同传输 比特率流的功能。一种是公司的“Flash Media Live Encoder”(简 称FMLE)软件，此软件可以把网络摄像机传过来的数据，同时压缩出3 种传输比特率的实时消息通讯协议(Real-Time Messaging Protocol，简称 RTMP)的影音流，视频压缩格式为VP6或H.264，声音压缩格式为mp3 或NellyMoser。另一种软件是开放源码的“FFMpeg”，此软件可以将原始 的一条影音流转换出众多数目(取决于硬件能力)的影音流(支持格式至 少有：RTP、LiveFLV、RTMP)，且几乎所有的压缩格式都支持。另外， 许多知名的影音分享平台，例如优酷等，上面的影片大多都 有几种不同质量可供选择。目前这些平台上的节目都是预先录制的，而非 实时产生，但大众已经很习惯这种使用模式，所以很自然地会期望以后的 实时影音分享平台也可以有不同质量的影音流可供选择。

然而，使用者并不能随时切换流，主要原因如下所述。一是网络的变 化可能是短期的，使用者若太积极地随网络变化来切换流，会加剧网络的 动荡。所以，使用者必须利用公知技术中的带宽评估技术，确认网络已经 达到另外一种稳定状况再行切换。另外，由于主流视频压缩算法(H.264 和Mpeg2、4)采用I、P、B三种不同的帧(Frame)来表示数据，其中P 帧或B帧必须直接或间接参照先前最新的I帧才可以正确解码出画面，故 使用者切换至另一流的时间点，会受限于I帧出现的时间点。这会衍生出 两个功能需求：一是在还未能切换前，要有办法维持住可接受的观赏质量， 一是必须帮助使用者尽快进行切换。

最后，从目前的技术可以观察到几个使用者使用习惯的趋势：(一) 越来越多使用者改用平板电脑或智能手机来收看影音流，这类设备的计算 能力和电力有限；(二)热门的节目通常会有几千或几百个以上使用者在 收看；(三)P2P(Peer-to-peer)的架构风行，在P2P系统中，每个使用 者同时也要把影音流分享给别人。这些使用习惯的趋势，会延伸出两个效 能需求：不可有太大的计算量，以及不可太耗费网络带宽。

发明内容

本发明提出一种适应网络带宽的实时影音流系统以及方法。

在本发明的一种实施方式中，提出一种影音流传输方法，包括接收流 数据，并监控从所述流数据取得并暂存的多笔编码数据，每一暂存的编码 数据包括多个编码译码单元，而所述编码译码单元以一传送顺序进行传 送，其中此编码数据在一实施例中可包括影音数据或可仅包括视频数据。

在此影音流传输方法中，当需要调整传输质量时，取得编码数据的信 息，并根据所述编码数据的信息取得对应每一编码数据内所包括的编码译 码单元对应的重要性参数，以及对应于所述的重要性参数，调整从影音流 传输通道所送的后续编码数据的多个编码译码单元的传送顺序。

上述根据所述编码数据调整编码译码单元的传送顺序方法在一实施 例中包括判断所述编码数据的存量是否低于第一阈值或高于第二阈值，其 中第二阈值大于第一阈值。当所述编码数据的存量低于第一阈值时，取得 编码数据的信息，并根据所述编码数据的信息取得对应每一编码数据内所 包括的编码译码单元对应的重要性参数，以及对应于所述的重要性参数， 调整从影音流传输通道所传送的后续编码数据的多个编码译码单元的传 送顺序。当编码数据的存量高于第二阈值时，停止调整此传送顺序。

在本发明的一种实施方式中，提出一种影音流传输方法，包括接收一 流数据，并将从流数据取得的多笔编码数据。输出暂存的编码数据以进行 播放，并判断当编码数据的存量是否低于第一阈值，当编码数据的存量低 于第一阈值或已经用尽时，暂停输出一第一时间区间，并暂存在第一时间 区间内所收到的编码数据。将在第一时间区间内所收到的编码数据调整为 在一第二时间区间内加速播放完毕，其中第二时间区间小于第一时间区 间，当所述影音数据的存量高于一第二阈值时，恢复正常播放速度。此编 码数据在一实施例中可包括影音数据或可仅包括视频数据。

在本发明的一种实施方式中，提出一种影音流传输方法，包括以一第 一比特传输率接收一第一流数据。在一切换时间切换到以一第二比特传输 率接收一第二流数据，其中此切换时间是以目前播放时间、第一重要编码 译码单元的播放时间、第二重要编码译码单元的播放时间进行判断。此目 前播放时间是第一流数据在判断时正在播放的时间，第一重要编码译码单 元的播放时间是第二流数据中比目前播放时间还早的第二流数据中的多 个编码数据中最新的重要编码译码单元的播放时间，此第二重要编码译码 单元的播放时间是第二流数据中的编码数据中比目前播放时间还晚的第 二流数据中最旧的重要编码译码单元，其中编码数据的重要性判断是根据 编码数据的信息取得对应每一编码数据内的多个编码译码单元所对应的 重要性参数比较取得。此编码数据在一实施例中可包括影音数据或可仅包 括视频数据。

在本发明的一种实施方式中，提出一种影音装置，适用于从一流数据 接收多笔编码数据，每一编码数据包括多个编码译码单元，而所述编码译 码单元以一编码顺序为传送顺序，其中此编码数据包括影音数据或仅包括 视频数据。此影音装置包括一缓冲器、一缓冲器监控模块以及一帧请求模 块。此缓冲器监控模块用以监控暂存于此缓冲器的编码数据的存量，当编 码数据的存量低于第一阈值时，发出一调整信号，当编码数据的存量高于 第二阈值时，发出一停止调整信号。帧请求模块响应于所述调整信号，输 出一帧请求信号，以调整流数据中，编码数据内的编码译码单元的传送顺 序。

在本发明的一种实施方式中，上述影音装置还包括一时戳调整模块， 用以接收下载的编码数据，并将编码数据暂存到该缓冲器，其中时戳调整 模块可将部分编码数据的播放时间进行修改。

在本发明的一种实施方式中，上述影音装置还包括一流请求模块，响 应于调整信号与带宽评估器的信号，输出一比特率请求信号，用以提供编 码数据的信息，以切换接收不同比特传输率的另一流数据。

在本发明的一种实施方式中，上述影音装置还包括一上传器与一排程 器。所述上传器用来将从该流数据接收到的编码数据传出。排程器用来接 收来自外部的另一帧请求信号，此另一帧请求信号包括由上传器传出的编 码数据中，每一编码数据内所包括的编码译码单元对应的重要性参数，其 中此重要性参数是根据这些编码数据的信息计算取得，排程器则根据重要 性参数调整上传器传出的编码数据内的编码译码单元的传送顺序。

上述影音装置还包括一时戳调整模块与一时戳复位模块。所述时戳调 整模块用以接收下载的编码数据，并将编码数据暂存到缓冲器，其中时戳 调整模块可将部分编码数据的播放时间进行修改。时戳复位模块连接到时 戳调整模块，用以将修改过的播放时间进行复位，以适合下一阶影音接收 者所要使用的影音流信息时间戳记。

另一实施例中，上述影音装置还包括流请求模块与一切换器。所述流 请求模块响应于调整信号与一带宽评估器的信号，输出一比特率请求信 号，用以提供编码数据的信息，以切换接收不同比特传输率的另一流数据。 切换器用来接收来自外部的另一比特率请求信号，用来切换由上传器所输 出的具有一第一比特传输率的一第一流数据切换到具有一第二比特传输 率的一第二流数据，并判断从第二流数据的合适播放时间点开始传送。

在本发明的一种实施方式中，上述影音装置还包括一时戳调整模块、 一时戳复位模块、一上传器与一排程器。此时戳调整模块用以接收下载的 编码数据，并将编码数据暂存到缓冲器，其中此时戳调整模块可将部分编 码数据的播放时间进行修改。时戳复位模块连接到所述时戳调整模块，用 以将修改过的播放时间进行复位，以适合下一阶影音接收者所要使用的影 音流信息时间戳记。上传器连接到所述时戳复位模块，用来将从流数据接 收到的编码数据传出。排程器用来接收来自外部的另一帧请求信号，此另 一帧请求信号包括由上传器传出的编码数据中，每一编码数据内所包括的 编码译码单元对应的重要性参数，其中此重要性参数是根据编码数据的信 息计算取得，而此排程器根据重要性参数调整上传器传出的编码数据内的 编码译码单元的传送顺序。

在本发明的一种实施方式中，提出一种影音装置，适用于从一流数据 接收多笔编码数据，每一编码数据包括多个编码译码单元，而这些编码译 码单元以一编码顺序为传送顺序，其中编码数据包括影音数据或仅包括视 频数据。此影音装置包括一缓冲器、一缓冲器监控模块、一时戳调整模块、 一帧请求模块、流请求模块、一时戳复位模块、一上传器、一排程器以及 一切换器。此缓冲器监控模块用以监控暂存于缓冲器的编码数据的存量， 当编码数据的存量低于第一阈值时，发出一调整信号，当编码数据的存量 高于第二阈值时，发出一停止调整信号。时戳调整模块用以接收下载的编 码数据，并将编码数据暂存到缓冲器，其中时戳调整模块可将部分编码数 据的播放时间进行修改。帧请求模块响应于调整信号，输出一帧请求信号， 以调整流数据中，所述编码数据内的编码译码单元的传送顺序。流请求模 块，响应于调整信号与带宽评估结果，输出比特率请求信号，用以提供编 码数据的信息，以切换接收不同比特传输率的另一流数据。时戳复位模块 连接到时戳调整模块，用以将修改过的播放时间进行复位，以适合下一阶 影音接收者所要使用的影音流信息时间戳记。上传器连接到时戳复位模 块，用来将从流数据接收到的编码数据传出。排程器用来接收来自外部的 另一帧请求信号，此另一帧请求信号包括由上传器传出的编码数据中，每 一编码数据内所包括的编码译码单元对应的重要性参数，其中重要性参数 是根据编码数据的信息计算取得，而此排程器根据重要性参数调整上传器 传出的编码数据内的编码译码单元的传送顺序。切换器用来接收来自外部 的另一比特率请求信号，用来切换由该上传器所输出的具有一第一比特传 输率的一第一流数据切换到具有一第二比特传输率的一第二流数据，并判 断从第二流数据的合适播放时间点开始传送。

在本发明的一种实施方式中，提出一种影音提供装置，包括一上传器、 一排程器以及一切换器。此上传器用来传送具有一第一比特传输率的一第 一流数据，其中此第一流数据包括多笔编码数据，每一编码数据包括多个 编码译码单元，而这些编码译码单元以一传送顺序排列，其中编码数据包 括影音数据或仅包括视频数据。排程器用来接收一帧请求信号，并根据帧 请求信号调整上传器传出的编码数据内的所述编码译码单元的传送顺序。 此切换器用来接收来自外部的另一比特率请求信号，用来切换由上传器所 输出的具有一第一比特传输率的一第一流数据切换到具有一第二比特传 输率的一第二流数据，并判断从第二流数据的合适播放时间点开始传送。

附图说明

图1A与1B为分别说明本发明所提出适应网络带宽的实时影音流系 统的不同实施例的架构示意图。

图2A～2C为本发明的一个实施例的实时影音流系统的客户端所使用 的系统方块示意图。

图3为本发明的一个实施例的实时影音流系统的服务器所使用的系统 方块示意图。

图4A～4C为本发明的一个实施例的实时影音流系统的客户端所使用 的系统方块示意图。

图5为本发明的一个实施例的重要性下载顺序的运作方法流程示意 图。

图6为说明本发明的实施例中判断帧最迟启动下载时间的方法示意 图。

图7A、7B、7C为说明本发明的实施例中，使用数据类型配置重要性 的示意图。

图8A、8B、8C为说明本发明的实施例中，依据播放时间的紧迫性来 调整影音数据的重要性的过程示意图。

图9为说明本发明的实施例中，依据额外的重要性指定策略，采用额 外标示法调整影音数据的重要性的过程示意图。

图10A、10B、10C为说明本发明多个实施例中，采用快速播放方法 以适应网络带宽过程的示意图。

图11A、11B、11C为说明本发明多个实施例中，采用可行立即切换 方法进行切换到不同传输比特率的流过程的示意图。

【主要元件符号说明】

100、300A、300A’、300A”、300B；客户端(Client)

200：服务器(Server)

210：播放器(Player)

220：缓冲单元(Buffer Unit)

222：缓冲器

224：缓冲器监控模块

230：带宽评估器(Bandwidth Estimator)

240：下载器(Downloader)

250：时戳调整模块(Timestamp Regulator)

260：帧请求模块(Frame Demander)

270：流请求模块(Stream demander)

310：上传器(Uploader)

320：排程器(Scheduler)

330：切换器(Switcher)

340～344：缓冲器

440：时戳复位模块(Timestamp Restorer)

1110、1120、1130、1140：流数据

1150：快速播放的时间区间

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，以下结合具体实 施例，并参照附图，对本发明作进一步的详细说明。

本发明提出一个适应网络带宽的实时影音流系统以及方法。

在一个实施例中，本发明所提出的适应网络带宽的实时影音流系统以 及方法，当网络发生壅塞的一段时间中，影音接收者可以平顺且正确地播 放出此段时间内尽可能多的影音数据、或是对影音提供者/接收者有意义的 影音数据，且播放进度跟影音提供者提供的最新进度的差距须维持在一固 定范围内。

在一个实施例中，本发明所提出的适应网络带宽的实时影音流系统以 及方法，当影音流存在其它不同传输比特率的流时，影音接收者可以依据 自身网络状况，切换到不高于可用带宽的最高传输比特率的流收看。

在一个实施例中，本发明提出一个适应网络带宽的实时影音流系统以 及方法，在效能上，可以达到不增加影音提供者/接收者太多的计算负担， 不增加冗余影音数据以节省带宽。某些相关研究采用增加I帧的做法，如 此会增加冗余影音数据。某些相关研究采用FEC或MDC的编码方式，如 此会增加冗余数据与计算负担。

本发明提出一个适应网络带宽的实时影音流系统以及方法，适合用于 使用者想要跟上最新进度的应用环境，例如在部分实施例中，适用于道路 或大楼监控、灾难现场直播、影音接收者之间或影音接收者与提供者之间 有互动需求的影音直播(例如Call-in节目、远程教学、购物节目、视频 会议)等。

本发明提出一个适应网络带宽的实时影音流系统以及方法，适合用于 影音接收者的硬件能力不高(例如手持装置等)，以及影音提供者的资源 也需要节约的情况(例如有限数目的服务器希望服务尽可能多的使用者)， 或是点对点(Peer-to-Peer，P2P)架构下每个点(Peer)也是一个影音提 供者下使用。

本发明提出一个适应网络带宽的实时影音流系统以及方法，在一实施 例中，包括一或多个影音提供者与一或多个影音接收者，即所谓客户端/ 服务器(Client/Server)架构)。在另一实施例中，本系统中的影音接收者 亦可同时为影音提供者，也就是点对点(P2P)架构下的每个点(Peer)。

在本发明所提出的系统与方法中，可将网络的状态分为至少四类，例 如包括：

1.壅塞-数据匮乏状态：网络可用带宽低于比特传输率，以至于影音接 收者缓冲器中的暂存数据量少于一阈值。

2.壅塞-数据耗尽状态：网络可用带宽低于比特传输率，以至于影音接 收者缓冲器中的暂存数据已经耗尽。

3.切换低比特率状态：网络可用带宽低于比特传输率的时间超过一阈 值，且用带宽评估技术确认网络可用带宽适合选择另一较低比特传输率的 流。

4.切换高比特率状态：网络可用带宽高于比特传输率的时间超过一阈 值，且用带宽评估技术确认网络可用带宽适合选择另一较高比特传输率的 流。

上述四个网络的状态，可以称为需要进行调整传输的事件之一，一旦 发生此调整传输的事件后，可以使用本发明中适应网络带宽的实时影音流 的一至数个方法，而达到较平顺且正确的播放效果。而在本发明中适应网 络带宽的实时影音流的一至数个方法中，可分别采用重要性下载顺序方 法、快速播放方法、切换比特率方法等，或是在这三种方法中根据设计上 的需求而例如选择其中的一或部分的组合达到预定的效果。

例如在以下多个实施例的网络状态中采用不同的组合：

1.在壅塞-数据匮乏状态下，采用例如重要性下载顺序方法，优先下载 重要数据。

2.在壅塞-数据耗尽状态下，影音接收者暂停播放一小段时间，同时使 用例如重要性下载顺序方法优先下载重要数据，再搭配快速播放方法播放 上述重要数据以追上实时时间。

3.在切换低比特率状态，可行立即切换方法判断网络状况是否适合在 新流于目前播放进度之后第一个I帧出现前进行切换。若是，则采用重要 性下载顺序方法下载新流中必要的数据并以快速播放方法播放它，然后回 复正常播放。若不适合立即切换，则使用重要性下载顺序方法及快速播放 方法继续播放原流，直到新流于目前播放进度之后第一个I帧的播放时间 切换至新流。

4.在切换高比特率状态，运作方式原理同在切换低比特率状态下的运 作方式。

本发明所提出适应网络带宽的实时影音流系统以及方法，所传输的视 频压缩数据，适用于各种包括例如以下特性的压缩数据。例如在压缩的数 据中，某部分的数据仅依赖本身信息即可解压缩，而剩余的数据须依赖自 身以外的数据才能解压缩的特性。符合上述特质的压缩算法有例如国际标 准组织(ISO)的移动画面专家组(MPEG)系列、H.264标准、高效率视 频编码(High Efficiency Video Coding，HEVC)。H.264标准是在ISO组织 中则纳入MPEG-4地时部分(ISO/IEC14496-10)并命名为先进视频编码 (Advanced Video Coding，AVC)，通常合并称为H.264/AVC。高效率视频 编码(HEVC)是一个由ISO/IEC MPEG及ITU-T VCEG所共同开发，被 认为是H.264/AVC的后继者并预期在未来会成为热门的新一代视频编码 标准。

为方便说明，以下的描述仅采用I帧、P帧、B帧来解释，但H.264 中所使用的I、P、B片段(Slice)或是任何用以编码/译码视频的单元都可 适用于本发明所提出的系统及/或方法。

请参照图1A与1B，为分别说明本发明所提出适应网络带宽的实时影 音流系统的不同实施例的架构示意图。在一实施例中，如图1A所示，本 发明所提出实时影音流系统可运用在客户端/服务器(Client/Server)架构。 服务器(Server)200提供实时影音流给客户端(Client)100。由于服务器 200经由网络传输提供影音流给想要跟上最新进度的客户端100，但因为 网络传输有其限制，因此，本实施例在此披露的所谓实时影音流，只要能 符合系统所要求一定时间传送到客户端100的状态，都可符合本实施例所 谓的实时状态或是接近实时的状态，例如与记录事件所对应的影音流发生 时间到传送到客户端100的时间是例如在十秒之内，或是在二十秒之内等 等都可称为实时或是接近实时的状态，但并非以此为限制，而是以系统所 要求的时间为主。例如道路或大楼监控、灾难现场直播等等，所要求反应 的时间，会依照状况有所差异。

在另一实施例中，如图1B所示，本发明所提出实时影音流系统可运 用在点对点(P2P)架构。服务器(Server)200提供实时影音流给客户端 (Client)300A。而客户端(Client)300A则是可以成为点对点(P2P)架 构下的一个点(Peer)。而其它的影音接收者，例如图示中的客户端(Client) 300B，则是可以从其它一至多个影音接收者下载影音数据，例如从客户端 300A取得实时影音流。在P2P架构中，每个影音接收者还可以提供本身 暂存的影音数据给一或多个影音接收者。

请参照图2A～2C，其为本发明所提出关于实时影音流系统多个实施例 的客户端所使用的系统方块示意图，但并非以此为限制。

在一个实施例中，请参照图2A，其为实时影音流系统的客户端所使 用的系统方块示意图。此客户端100包括播放器(Player)210、缓冲单元 220、带宽评估器(Bandwidth Estimator)230以及下载器(Downloader) 240。而用以达成本发明所提出实时影音流系统的客户端100所使用的系 统包括帧请求模块(Frame Demander)260。

上述在客户端100所使用的系统可以是由个别单独物理设备所执行， 也可以是由处理器(Processor)执行储存在内存装置内的韧体或是软件模 块。上述的方式都可达到本发明所提出实时影音流的系统。下载器240用 以接收编码数据，并传送到缓冲单元220。而缓冲单元220则是连接到播 放器210与帧请求模块260。

播放器210可以是目前市面上已有的主流播放器，例如快闪播放器 (Flash player)，也可以是自行开发的播放器，并播出声音与视频 (Audio/Video，A/V)数据。缓冲单元220是位于播放器210外部的缓存 单元器，用以缓冲暂存欲提供给播放器210的影音数据，例如带有流通讯 协议(例如RTMP)信息的影音数据。此缓冲单元220包括缓冲器(Buffer) 222以及一缓冲器监控模块(Buffer Monitor)224。缓冲器监控模块224 用来监控缓冲器222存量是否不足。带宽评估器230利用带宽评估机制来 评估目前的影音提供者到自身，以及其它可能的影音提供者到自身的可用 带宽。下载器240用来下载影音数据。帧请求模块260传送一帧请求给影 音提供者，用以提供必要信息给影音提供者，请其改变影音数据传送的优 先级。

在一个实施例中，请参照图2B，其为实时影音流系统的客户端所使 用的系统方块示意图。此客户端100包括播放器210、缓冲单元220、带 宽评估器230以及下载器240。而用以达成本发明所提出实时影音流系统 的客户端100所使用的系统包括时戳调整模块(Timestamp Regulator)250 以及帧请求模块(Frame Demander)260。

与图2A相同的元件用相同的标号表示，在此不再冗述。下载器240 连接到时戳调整模块250，用以接收编码数据，并传送到时戳调整模块250。 缓冲单元220则是连接到播放器210、时戳调整模块250与帧请求模块260。 时戳调整模块250将编码数据传送到缓冲单元220暂存。

下载器240用来下载影音数据。时戳调整250接收来自下载器240所 下载的影音数据，并将某些特定视频数据的播放时间进行修改，使其根据 修改的时戳(Timestamp)调整播放的速度。帧请求模块260传送一帧请 求给影音提供者，用以提供必要信息给影音提供者，请其改变影音数据传 送的优先级。

在一个实施例中，请参照图2C，其为实时影音流系统的客户端所使 用的系统方块示意图。此客户端100包括播放器210、缓冲单元220、带 宽评估器230以及下载器240。而用以达成本发明所提出实时影音流系统 的客户端100所使用的系统包括时戳调整模块250、帧请求模块260、以 及流请求模块(Stream demander)270。

与图2A相同的元件用相同的标号表示，在此不再冗述。下载器240 连接到时戳调整模块250，用以接收编码数据，并传送到时戳调整模块250。 缓冲单元220则是连接到播放器210、时戳调整模块250、帧请求模块260、 以及流请求模块270。时戳调整模块250将编码数据传送到缓冲单元220 暂存。

时戳调整250接收来自下载器240所下载的影音数据，并将某些特定 视频数据的播放时间进行修改，使其根据修改的时戳(Timestamp)调整 播放的速度。帧请求模块260传送一帧请求给影音提供者，用以提供必要 信息给影音提供者，请其改变影音数据传送的优先级。流请求模块270传 送一比特率请求给影音提供者，用来提供必要信息给影音提供者，请其提 供不同比特率的新流影音数据给客户端100。

请参照图3，其为本发明的一个实施例的实时影音流系统的服务器所 使用的系统方块示意图。服务器200以一流服务器(Stream Server)进行 说明，但并非以此为限制。服务器200至少包括上传器(Uploader)310 以及至少一个缓冲器。为方便说明，在此仅以图示所标示的缓冲器340～344 为例，但并非以此为限制。为达成本发明所提出实时影音流系统的服务器 200的功能，服务器200可以选择性地包括排程器(Scheduler)320以及/ 或是切换器(Switcher)330，此为根据客户端的需求而有不同的实施方式。 例如客户端为图2A的架构，则配合的服务器200可只包括排程器320。 例如客户端为图2C的架构，则配合的服务器200可须包括排程器320以 及切换器330。

上传器310用来将数据传送给下一阶段的影音接收者，例如图2所述 的客户端100。排程器320用来调整要传送给影音接收者的数据的传送顺 序。切换器330用来判断要从新流的哪个播放时间点开始提供数据，以及 提供那些数据。而缓冲器340～344中的每个缓冲器储存一种对应的比特传 输率的流数据。

请参照图4A～4C，其为本发明多个实施例的实时影音流系统的客户端 所使用的系统方块示意图。

请参照图4A，其为本发明的一个实施例的实时影音流系统的客户端 所使用的系统方块示意图。在此实施例中，为说明图1所示点对点(P2P) 架构下的一个点(Peer)的客户端(Client)300A系统方块示意图。客户 端(Client)300A包括播放器210、缓冲单元220、带宽评估器230以及 下载器240、以及帧请求模块260。为了扮演点对点(P2P)架构下的一个 影音提供者，此客户端300A还包括上传器(Uploader)310以及排程器 (Scheduler)320。本实施例中与图2A及图3相同元件以相同的标号表示， 在此不再冗述。缓冲器222将数据传送到上传器310，再经由上传器310 传送到点对点(P2P)架构下的下一个点(Peer)。

请参照图4B，其为本发明的一个实施例的实时影音流系统的客户端 所使用的系统方块示意图。在此实施例中，为说明点对点(P2P)架构下 的一个点(Peer)的客户端(Client)300A’系统方块示意图。客户端(Client) 300A’包括播放器210、缓冲单元220、带宽评估器230以及下载器240、 时戳调整模块250以及帧请求模块260。为了扮演点对点(P2P)架构下 的一个影音提供者，此客户端300A还包括上传器(Uploader)310以及排 程器320。本实施例中与图2B及图3相同元件以相同的标号表示，在此 不再冗述。在此实施例中，此客户端300A’还包括一时戳复位模块440， 连接到时戳调整模块250，用以将被时戳调整模块250所修改过的播放时 间信息修改回来或是修改为适合下一阶影音接收者所要使用的影音流信 息时间戳记，再经由上传器310传送到点对点(P2P)架构下的下一个点 (Peer)。

请参照图4C，其为本发明的一个实施例的实时影音流系统的客户端 所使用的系统方块示意图。在此实施例中，为说明图1所示点对点(P2P) 架构下的一个点(Peer)的客户端(Client)300A”系统方块示意图。客户 端(Client)300A”包括播放器210、缓冲单元220、带宽评估器230以及 下载器240、时戳调整模块250、帧请求模块260、以及流请求模块270。 为了扮演点对点(P2P)架构下的一个影音提供者，此客户端300A”还包 括上传器310、排程器320以及切换器(Switcher)330。本实施例中与图 2C及图3相同元件以相同的标号表示，在此不再冗述。在此实施例中， 此客户端300A”还包括一时戳复位模块(Timestamp Restorer)440，连接 到时戳调整模块250，用以将被时戳调整模块250所修改过的播放时间信 息修改回来或是修改为适合下一阶影音接收者所要使用的影音流信息时 间戳记，再经由上传器310传送到点对点(P2P)架构下的下一个点(Peer)。

在此必需注意的是，本发明内容的图式或上述实施例中，所述许多功 能单元标示为功能方块或模块，是为了具体地强调其实施独立性。例如， 可将功能方块或模块实施为硬件电路，其包含自订VLSI电路或门极阵列、 如逻辑芯片的现成半导体、晶体管、或其它离散元件。亦可在可编程硬设 备中实施模块，如可编程栅极阵列、可编程阵列逻辑、可编程逻辑设备、 或其类似物。亦可在利用各种类型的处理器执行的软件中实施模块。例如， 可执行码的识别模块包含计算机指令的一或多个物理或逻辑区块，例如， 可将这些区块组织为对象、程序、或功能。然而，识别模块的可执行文件 物理上不一定位于一起，而是可包含储存于不同位置的不同指令，这些指 令当逻辑结合一起时将包含模块并达成模块的指定目的。

可执行码模块可为单一指令或许多指令，并可分布于数个不同程序代 码片段上、不同程序中、及数个内存装置上。同样地，操作数据在此可识 别及说明于模块内，并可以任何合适形式体现及组织于任何合适类型的数 据结构内。可收集操作数据为单一数据集，或操作数据可分布于不同位置 (包括分布于不同的储存设备)，且操作数据可仅作为电子信号至少局部 地存在。

具体方法步骤

本发明所使用的方法，将以下面的实施例加以说明，但本发明并不仅 限于以下的实施例。所有与下列实施例类似的应用场合，皆可使用本发明 所提出的系统与方法。本发明使用主流视频压缩算法，例如MPEG系列、 H.263、H.264等等，所使用的I帧、P帧、B帧或是I、P、B片段(Slice) 都可用来解释本发明的方法。

重要性下载顺序方法

本发明所提出的方法，在一实施例中，提出一种重要性下载顺序的运 作方法，内容如下所述，并请参照图5进行说明。

首先，步骤S502，影音接收者的缓冲器监控模块可以周期性或随时地 监测缓冲器的存量，影音接收者的带宽评估器可以周期性或随时地监测网 络可用带宽。

步骤S510，缓冲器监控模块判断缓冲器的存量是否低于一阈值(以 Th1表示)，若否，则持续监控。若是，则影音接收者的帧请求模块可针 对未来某一段要下载的影音数据进行如以下的方式处理。步骤S512，影音 接收者取得影音数据相关信息，例如所接收影音内容的图像组(Group of  Picture，以下简称GOP)信息、影音提供者的数量、是否使用网络编码 (Network Coding)技术、该要被下载的编码数据的播出时间、预测数据 量大小、预测解碼时间、可用带宽等信息。

上述图像组(GOP)信息例如是在MPEG视频编码中，图像组(GOP) 即I帧和I帧之间的帧排列。图像组就是一组以MPEG编码的图片或视频 流内部的连续图像。每一个以MPEG编码的影片或视频流都由连续的图像 组组成。

取得上述的信息后，影音接收者可以决定处理方式，在一实施例中， 将这些影音数据自行根据重要性排序方法进行排序后，再将排序的结果传 送给单一或是多个影音提供者，例如步骤S514～S516。在步骤S514中， 影音接收者的帧请求模块(Frame Demander)会依据一类型-紧迫性准则 判断与指定取得的影音数据相关信息的重要性，并依据该重要性对未来要 接收的一段影音数据进行排序。而后在步骤S516，影音提供者收到影音接 收者送来的请求是“排序结果”时，除了根据此排序结果对后续传送的影 音数据更新传送排列顺序外，在另外一实施例中，影音提供者的排程器 (Scheduler)还可以再依据额外指定的策略，例如广告商要求一定要传送 有出现他们商标的画面、或是场景分析程序判断某灾难画面疑似出现人影 等等特定的策略，改变画面的重要性，以调整传送排列顺序。

在另一实施例中，影音接收者单纯地将取得的影音数据相关信息，例 如与排序相关的参考信息(网络可用带宽、目前播放进度、缓冲器的存量 现状等等)传给影音提供者请其代为决定未来某一段要传送的数据的传送 顺序，如步骤S518～S520。

如步骤S518，影音接收者的帧请求模块将取得的影音数据中与排序相 关的参考信息，例如：网络可用带宽、目前播放进度、缓冲器现状或上述 信息的处理结果，传送给影音提供者。步骤S520，影音提供者的排程器综 合此排序参考信息依据类型-紧迫性准则及/或根据一额外指定的策略，决 定未来某一段要传输的影音数据的顺序，也就是依照重要性进行排序。

步骤S522，影音提供者根据上述不同的处理方式决定的重要顺序依序 传送编码数据。每传送若干个画面、或每传送完一个排程、或每经过一固 定或非固定时间，影音接收者或影音提供者可根据最新的可用带宽信息以 上述方式微调目前排序。同时，影音接收者或影音提供者会检查目前排序 的这一段编码数据，是否会影响下一段要被排序的编码数据的传送。若不 会影响，则继续传送目前排序的编码数据。若产生影响，则中断传送目前 排序的编码数据。跳到步骤S502以对下一段影音数据传送顺序做排序。

步骤S524，若缓冲器监控模块发现缓冲器的存量已经超过另一阈值 (以下以Th2表示)，其中Th1＜Th2(以避免传输顺序于重要性顺序和编 码顺序两者之间频繁切换)，影音接收者告知影音提供者于下一段未排程 影音数据开始传送时，恢复原来的传输模式(即依照原有的编码顺序传 送)。

上述重要性下载顺序方法适用于许多情境，例如下面的情境，但并非 以此为限制。

场景1：单一影音提供者，每个图像组(GOP)的结构已知(如：某 些编码器采固定的图像组(GOP)结构)。

场景2：单一影音提供者，每个图像组(GOP)的结构未知(如：某 些编码器会依据场景变化增减I帧的出现频率)。

场景3：多个影音提供者，每个图像组(GOP)的结构已知，影音数 据无再经过网络编码(Network Coding)等编码技术编码。

场景4：多个影音提供者，每个图像组(GOP)的结构已知，影音数 据有再经过网络编码(Network Coding)等编码技术编码。

场景5：多个影音提供者，每个图像组(GOP)的结构未知，影音数 据无再经过网络编码(Network Coding)等编码技术编码。

场景6：多个影音提供者，每个图像组(GOP)的结构未知，影音数 据有再经过网络编码(Network Coding)等编码技术编码。

在上述场景1或4中，则不论是影音接收者或影音提供者都可以对某 段要被排序的影音数据进行排序。

在上述场景2或6中，由影音提供者对某段要被排序的影音数据进行 排序较为合适，因为提供者可较接收者更早得知要被排序的影音数据的图 像组(GOP)结构。

在上述场景3或5中，由影音接收者对某段要被排序的影音数据进行 排序较为合适，因为此场景下不同的影音提供者间不易合作。影音接收者 依据从各个影音提供者取得其所知的图像组(GOP)结构信息的联集，进 行排序。

不论上述哪一场景，皆须每隔一段时间便对某一段数据计算重要性。 在本发明的实施例中，所提到每隔一段时间便对某一段数据计算重要性， 系针对图像组(GOP)中所有画面，以及这些画面播放时间内的声音数据。 为方便说明，被评估重要性的视频与声音数据，称为评估对象集合。然而， 若GOP中的画面数目不多，为节省控制花费，本发明的方法可适用于连 续的数个GOP视为一个评估对象集合。若一个GOP的播放时间长度很长， 为了提升效率，本发明也可将此GOP分割为数个评估对象集合。

当需要执行重要性下载顺序方法时，目前下载中的GOP里的画面， 尚未下载者，以及这些画面的播放时间内的声音数据，即为第一个评估对 象集合。每次进行评估前，须先计算下一个评估对象集合的最重要数据(可 能为此GOP的I帧或声音数据)的最迟启动下载时间，才能知道目前的评 估对象集合可以使用多少时间来下载。

在上述的实施例中，此重要性下载顺序指的是根据一指标参数进行调 整，例如是根据数据所计算而得的重要性进行调整，但并非以此为限制， 只要能作为下载顺序调整的任何因素的组合都可以称为重要性参数，此须 视设计上的需要而变化。例如可以是接收影音内容的图像组(GOP)信息、 被评估的所述编码数据的播出时间、预测数据量大小、预测译码时间、可 用带宽、所述编码数据提供来源的数量或所述编码数据是否采用网络编码 (Network Coding)方式。在另外一实施例中，还可以再依据额外指定的 策略，例如广告商要求一定要传送有出现他们商标的画面、或是场景分析 程序判断某灾难画面疑似出现人影等等特定的策略，改变画面的重要性， 以调整传送排列顺序。

以图6为实施例，说明判断每个I帧的最迟启动下载时间的方法示意 图。对于其它的信息，例如声音的判断原理与此实施例相同，也就是也可 适用于此实施例所描述的方法，因此在此不再赘述。

首先，令影音接收者在数据不虞匮乏情况下，第Y个播放的画面的识 别码为Y，且播放的第一个画面的识别码为1(识别码即为图6中每个画 面内上方的数字，画面以菱形表示)。若某一I帧的识别码为n，且此流的 帧率(Frame Rate)固定为x帧/每秒(Frames per second，fps)，也就是每 张画面的呈现时间为1/x秒。除此之外，此影音接收者的播放器于时间t_start 时开始播放(缓冲器监控模块观察到已传送播放器认可的安全缓冲时间长 度t_safe的数据量给播放器的时间点即为t_start)，则识别码为n的I帧应该于 t_start+(n/x)秒时候播出。

若以下面的方式判断，在未来一段适宜时间内的可用带宽为w，识别 码为n的I帧的数据量大小预测值s和解碼花费时间预测值t_decode。如此便 可求得识别码为n的I帧由影音提供者送出的最迟启动下载时间 t_urgent＝(t_start+n/x)-t_decode-(s/w)。此法也可用来评估P帧、B帧和声音的最迟 启动下载时间。

在此假设目前时间加上影音接收者发送请求到影音提供者的花费时 间所得的时间点为t，且下一评估对象集合的I帧的最迟启动下载时间为t’， 则目前评估对象集合的可用下载时间即是t’-t。

开始排序前，还有一点须注意的是，当影音接收者来指定数据的重要 性时，声音数据的重要性可由例如影片类型(如：演讲节目则声音重要， 武打节目则声音不重要)决定、使用者手动指定、或是影音提供者周期性 地事先告知影音接收者接下来的评估对象的声音重要程度等方式来决定。

若声音为最重要，可先下载评估对象集合里的全部声音再开始下载画 面，令全部声音数据下载需花费T_{_sound}，则画面仅分配到t’-t-T_{_sound}的时 间来评估重要性。若声音最不重要，则可留到最后下载。若声音重要性介 于I帧与P帧之间，可以先下载完I帧，再下载声音，然后剩余时间留给 P帧与B帧。如果声音重要性介于P帧与B帧之间，可以先下载完I帧与 P帧后，再下载声音，然后剩余时间留给B帧。若声音重要性等同于P帧， 则每下载一个P帧，就把该下载P帧与其上一参考画面之间的声音下载下 来(可先P帧或先声音)。

本发明中的实施例中，重要性以数值为例表示，数值越大表示越重要。 重要性最大值为M+1，最小值为0。M值须比评估对象集合中的个数还多， 且建议为一正整数，也可以是实数或任何可用以程度差异的数值皆适用于 此实施例。

以上述场景1为例说明，也就是以单一影音提供者为例，每个图像组 (GOP)的结构已知。影音接收者先以数据类型(声音、I、P、B)和播 放时间的紧迫性来指定重要性，这种指定法称为类型-紧迫性。采用类型 来指定重要性的精神为若一画面译码失败时会造成越多的画面译码不正 确，则该画面越重要。采用紧迫性来指定重要性的精神为越是快要被播放 到的数据越容易错失播放时机，故越重要。

依数据类型配置重要性

关于指定I帧的重要性，可配置为M。

关于指定声音的重要性，则可根据以下的规则，包括(1)若声音比I 帧重要，则声音重要性为M+1。(2)若声音最不重要，则声音重要性为0。 (3)若声音重要性介于I、P帧之间，声音重要性为M-1。(4)如果声音 重要性介于P、B帧之间，则声音的重要性设为最后一个P帧的重要性减 1。之后此P帧的重要性若改变为d，声音的重要性就跟着改变为d-1。(5) 若声音重要性等同于P(或B)帧，则把每个P(或B)帧及其对应到的 声音的重要性设为相同，这里所谓的对应到的声音是指该P(或B)帧与 前一帧、或该P(或B)帧与后一帧的播放时间点之间的声音。之后此P (或B)帧的重要性若改变为d，对应声音的重要性就跟着改变为d。

关于指定P帧的重要性。把M～0中未配置的值，从大到小配置给播 放时间由最旧到最新的P帧。例如，评估对象集合中有3张P帧：P1、P2、 P3，且P1比P2早播出，P2比P3早播出。目前重要性M已配置给I帧， 重要性M-1已配置给声音，则可以将P1配置重要性M-2，P2配置重要性 M-3，则P3配置重要性M-4。

关于指定B帧重要性，可依照以下的规则，包括(1)播放时间上连 续的B帧视为一组B画面群，从播放时间最早的B画面群到播放时间最 晚的B画面群中，各挑出此画面群中数据量最大的B画面来。例如评估对 象若为I1、B3、B4、P2、B5、B6，则B3、B4是一个画面群，B5、B6 是一个画面群。假设数据量方面是B3＞B4，B6＞B5，则第一次会挑出B3 和B6。(2)把M～0中未配置的值，从大到小配置给上述挑出来的B画面 (从数据量大的往数据量小的配置。若有数个B画面的数据量一样大，则 再以播放时间最早的往最晚的配置)。假设目前M～M-2已配置，上例中 B3数据量比B6大，则B3会被配置为重要性M-3，B6会被配置为重要性 M-4。(3)若还有B画面未被指定重要性，跳到前述步骤(1)，直到全部 的B画面已被指定重要性。

目前只以数据类型来指定重要性。上述方法可以顾虑到数据译码的相 依性，B画面分布的均匀性(播放画面会较不均匀分布的平顺)，及信息 量较大的B画面较数据量小的B画面优先。

依播放时间紧迫性配置重要性

依据播放时间的紧迫性来调整影音数据的重要性的一个实施例中，采 用一类似气泡排序法的方式来调整，此法的计算量很小。

若所有比还未调整的B帧还重要的数据的下载时间总和，已经超过此 次评估对象集合的可用下载时间(先前提及的t’-t)，则无需再依据播放时 间的紧迫性来调整影音数据的重要性。

若所有比还未调整的B帧还重要的数据的下载时间总和，尚未超过此 次评估对象集合的可用下载时间(先前提及的t’-t)，则目前还未调整完毕 的B帧中重要性最大者，试着和符合下列条件者交换重要性：(1)重要性 比该B帧大1；(2)该交换数据不是该B帧解碼时所需直接或间接参照的 数据；(3)该交换数据是否可于其最迟启动下载时间之前启动下载的可能 性，不因交换而改变；(4)该交换数据下载完毕时间是否超过下一评估对 象中最重要数据的最迟启动下载时间的可能性，不因交换而改变。

当没有符合上述条件的交换数据时，若该调整中的B帧的下载时间没 有超过其最迟启动下载时间，且其下载完毕时间也不超过下一评估对象中 最重要数据的最迟启动下载时间的话，则此B帧调整完毕。反之，则恢复 该调整中的B帧所做过的所有调整，然后该B帧视为调整完毕。

以下实施例配合图7A～7C说明如何使用类型-紧迫性方法依据数据的 类型来调整影音数据的重要性的过程示意图。为简化说明，此例并不包括 声音数据。图7A显示一评估对象集合包括nI、n+3P、n+1B、n+2B、n+6P、 n+4B、n+5B、n+9P、n+7B、n+8B。在此I、P、B分别指的是I帧、P帧、 B帧，而前列数字代表播放顺序。依据上述所提出的依数据类型配置重要 性的方法后，上述数据分别得到重要性M、M-1、M-4、M-8、M-2、M-9、 M-5、M-3、M-6、M-7，这同时也是其暂定的传输顺序。图7B显示这些 画面数据的最迟启动下载时间及其参考信息。此实施例中的流每秒有10 张画面，比特传输率是2000Kbps，评估近期未来的可用带宽是1600Kbps。 图7C画出本发明的实施例中，目前的传输策略，其中时间轴上的标示表 示该画面的最迟启动下载时间，虚线表示下一评估对象的最重要数据的最 迟启动下载时间，在此例子中也就是10.5的时间。评估对象nI、n+3P、 n+6P、n+9P、n+1B、n+5B、n+7B、n+8B、n+2B、n+4B的预测传输时间 分别为t1、t2、t2、t2、t3、t3、t4、t4、t5、t5，其系对应传输数据的大小 除以评估近期未来的可用带宽。

图7C可以看出，本发明所提出的方法的实施例，对于目前所指定之 重要性的传输效果。目前可以确保nI、n+3P、n+6P、n+9P这4张画面及 时抵达影音接收者。

图8A、8B、8C为说明本发明的多个实施例之一，依据播放时间的紧 迫性来调整影音数据的重要性的过程示意图。图8A、8B、8C显示依据上 述方法的实施例中，执行依据播放时间的紧迫性来调整影音数据的重要性 的过程。

图8A显示n+1B、n+5B提升重要性的过程，n+1B先与n+9P互换。 n+1B再与n+6P互换。接着因为n+1B解碼需要n+3P，所以不可互换。又 n+1B此时的重要性不能使它在其最迟启动时间前开始下载，故n+1B所做 的调整全部复原(即n+1B和n+6P换回来，然后n+1B和n+9P再换回来)。

接着，n+5B先与n+1B互换。n+5B再与n+9P互换。接着因为n+5B 解碼需要n+6P，所以不可互换。又n+5B此时的重要性可使它在其最迟启 动时间前开始下载，且不影响被交换的n+9P下载完毕时间是否超过n+10I 的最迟启动下载时间的可能性，故n+5B调整完毕。

图8B显示n+7B、n+8B提升的过程，n+7B先与n+1B互换。接着因 为n+7B解碼需要n+9P，所以不可互换。又n+7B此时的重要性会延误n+10I 的下载，故n+7B所做的调整全部复原(即n+7B和n+1B再换回来)。

接着，n+8B先与n+7B互换。n+8B再与n+1B互换。接着因为n+8B 解碼需要n+9P，所以不可互换。又n+8B此时的重要性会延误n+10I的下 载，故n+8B所做的调整全部复原(即n+8B先和n+1B换回来，n+8B再 和n+7B换回来)。

图8C显示n+2B提升的过程，n+2B先与n+8B互换。n+2B再与n+7B 互换。n+2B再与n+1B互换。n+2B再与n+9P互换。n+2B再与n+5B互 换。n+2B再与n+6P互换。接着因为n+2B解碼需要n+3P，所以不可互换。 又n+2B此时的重要性可使它在其最迟启动时间前开始下载，且不影响被 交换的画面的下载完毕时间是否超过n+10I的最迟启动下载时间的可能 性，故n+2B调整完毕。此时该评估对象集合的可用传输时间已用罄，n+4B 可不用尝试提升。

在上述实施例中，本发明可以确保有6张正确解碼的画面及时抵达影 音接收者。

在上述场景1中，影音提供者若非收到影音接收者依类型-紧迫性方 法所指定的重要顺序，也就是上述由影音接收者自行运算后传来的“排序 结果”，而是收到类型-紧迫性方法所需的参考数据，例如与排序相关的参 考信息(网络可用带宽、目前播放进度、缓冲器的存量现状等等)，则影 音提供者会代替影音接收者执行类型-紧迫性方法来指定重要性。这样做 的好处是，若影音接收者的设备能力很差，可由设备能力较好的影音提供 者代劳。不论类型-紧迫性方法的工作由谁来做，其产出还会被影音提供 者调整一次。

一些额外的重要性指定策略会标示出某些画面或某段声音特别重要。 这些策略可能是广告商要求的，或是某程序解析影音数据后决定的。当影 音提供者发现这些额外的重要性指定策略所标示的数据，在类型-紧迫性 方法的产出排序中，是可以于这些数据的最迟译码时间之前送到影音接收 者，则排序结束，开始传送数据。否则，影音提供者的排程器(Scheduler) 会把这些标示数据的重要性，试着进行提升的操作。

本发明所提出额外的重要性指定策略方法，在一个实施例中，可以采 用额外标示法，详细步骤如下所述。

首先，若所有比还未调整的标示数据还重要的数据(不含B画面)的 下载时间总和，已经超过此次评估对象集合的可用下载时间(先前提及的 t’-t)。则无需再调整影音数据的重要性。若尚未超过，则目前尚未调整完 毕的标示数据中重要性最大者，将其重要性提高到仅小于其参考的画面数 据中重要性最小者。提升过程中，若导致原本可及时下载的I帧、P帧变 为来不及下载，则试着排除排程里播放时间较该调整中数据晚的B画面 (从播放时间最晚者逐一排除)。判断释放出来的排程时间能否容下此该 调整中数据，若可以则该标示数据调整完毕，若不行，则放弃提升此额外 标示的数据。此实施例可以参照图9，为说明本发明的实施例中，依据额 外的重要性指定策略，采用额外标示法调整影音数据的重要性的过程示意 图。如图9所示，以n+4B为例，因为额外的重要性指定策略，将n+4B 提升到n+6P与n+9P之间。

在上述场景2中(即单一影音提供者，每个GOP的结构未知)，影音 接收者无法确定目前评估对象集合的大小，故只能提供参考信息给影音提 供者请其代为指定重要性。要提供的信息至少包括t_start(影音接收者的播 放器开始播放的时间)、影音接收者第一个播出的画面的识别码、未来一 段适宜时间内的可用带宽为w、解碼花费时间预测值t_decode。

在上述场景2中，若影音提供者的缓冲器里已经出现下一评估对象集 合的I帧，则直接用上述场景一所述的类型-紧迫性法和额外标示法对目 前评估对象进行重要性配置与传送顺序排序。若尚未出现下一评估对象集 合的I帧，则以目前缓冲器里所有未传送给影音接收者的数据当作目前的 评估对象集合，且将目前的评估对象集合中最新的P帧的最迟传送完毕的 时间(即影音接收者来得及播放)减去目前时间t，当作此次评估对象集 合的可传输时间，然后再用上述场景1所述的类型-紧迫性法和额外标示 法对目前评估对象进行重要性配置与传送顺序排序。

在上述场景3中，也就是多个影音提供者，每个GOP的结构已知， 影音数据无再经过网络编码(Network Coding)等编码技术编码。由于影 音提供者彼此不知道对方的运作情况，所以要互相协调影音数据的传送顺 序的复杂度很高。因此，在此情境中，本发明只让影音接收者来决定数据 的传送顺序，而决定的方式跟场景1所述的类型-紧迫性法相同，唯一的 区别在于带宽评估器(Bandwidth Estimator)所评估的未来一段适宜时间 内的可用带宽为w，是所有影音提供者到影音接收者的可用带宽的总和。

决定好传送顺序后，影音接收者在一实施例中，可以采用以下两种方 式来告知影音提供者。在第一种方法中，先跟各个影音提供者请求一画面 或声音(越重要数据跟可用带宽越大者拿)，再看哪个提供者先传输完， 就向该影音提供者请求目前还没传输者中重要性最大者。举例来说，若有 两个影音提供者A、B，且影音提供者A的可用带宽大于影音提供者B。 目前排序好的数据顺序为I1、P1、声音1、P2、声音2、B1、B2、B3、 B4。所以影音接收者会先向影音提供者A要I1，向影音提供者B要P1。 假设影音提供者B比影音提供者A先传完，则影音接收者又继续跟影音 提供者B要声音1。当影音提供者B还在传声音1给影音接收者时，若影 音提供者A已经传完I1，则影音接收者就向影音提供者A请求P2。

第二种方法为，影音接收者先对各个影音提供者配置一画面或声音 (越重要数据配置给可用带宽越大者)，再依据配置画面的预测大小以及 评估的可用带宽计算该配置数据传完的时间，看哪个提供者先传输完，就 把目前还没传输者中重要性最大者配置给该影音提供者。待全部数据都配 置好后，将配置结果传给所有的影音提供者。

在上述场景4中，也就是有多个影音提供者，每个GOP的结构已知， 影音数据有再经过网络编码(Network Coding)等编码技术编码。由于网 络编码可以让不同的影音提供者之间，无须协调便可以将一份原始数据， 随意编码后传给影音接收者。故此场景下，不同的影音提供者可以视为一 个。也就是说，场景4中影音接收者和提供者指定重要性的方法，与场景 1相同。

在上述场景5中，也就是有多个影音提供者，每个GOP的结构未知， 影音数据无再经过网络编码(Network Coding)等编码技术编码。由于影 音提供者彼此不知道对方的运作情况，所以要互相协调影音数据的传送顺 序的复杂度很高。因此，在此情境中，本发明只让影音接收者来决定数据 的传送顺序。首先，影音接收者向各个影音提供者收集其缓冲器状态。然 后，从这些缓冲器状态中，挑出影音接收者未下载数据的联集。

根据该未下载内容的联集，在一实施例中，可以采用以下两种作法。

其一，若无包括I帧，则该内容为目前评估对象集合。且将目前的评 估对象集合中最新的P帧的最迟传送完毕时间减去目前时间，当作此次评 估对象集合的可传输时间，然后再用上述场景1所述的类型-紧迫性法对 目前评估对象进行重要性配置与传送顺序排序。

其二，若有包括I帧，则播放时间在联集中最旧的I帧之前且解碼时 不需直接或间接依赖该I帧的画面及其播放时间中的声音数据，为目前评 估对象集合。且将该最旧的I帧的最迟启动下载时间减去目前时间，当作 此次评估对象集合的可传输时间，然后再用上述场景1所述的类型-紧迫 性法对目前评估对象进行重要性配置与传送顺序排序。

在上述场景6中，也就是有多个影音提供者，每个GOP的结构未知， 影音数据有再经过网络编码(Network Coding)等编码技术编码。同场景 4的解释，这些影音提供者可视为1个。所以场景6的处理方式，等同场 景2(单一影音提供者，每个GOP的结构未知)。

快速播放方法

当播放进度追上下载的最新进度时(即缓冲区耗尽)，或是缓冲区暂 存的数据量低于一第一阈值，影音接收者的时戳调整模块(Timestamp  Regulator)会暂存n时间单位的重要编码数据，并修改这n时间单位的数 据的播放时间信息，例如RTMP消息标头中的时戳(Timestamp)字段， 使其在n时间单位期间的最后m时间单位，得以加速度(约n/m倍)播完， 以追上最新进度。如图10A所示，其显示了在n时间单位期间内的最后m 时间单位内将编码数据播放完毕。

在最后m时间单位期间，时戳调整模块依据修改过的时间信息，把修 改过的影音数据放到缓冲器内，以便让播放器读取。若是在P2P架构下， 此修改过的内容要分享给其它的影音接收者，则在分享前，时戳复位模块 (Timestamp Restorer)会把影音数据复制过来，把播放时间信息恢复后再 分享出去。

上述决定n与m值的方法详述如下。

决定n值时，n值至少要长到足以下载一重要编码数据(该定义等同 重要性下载顺序方法中所定义的重要数据。最大为网络已经恢复平顺时。 由于需暂停播放画面n-m时间单位，为避免使用者无法耐心等待，n值不 宜太大，在一实施例中，建议值可采用2～20秒之间。

决定m值时，可以采用固定比例。即m＝n/i，i为一大于1且小于等 于n的正整数，也可以是实数或任何可用以比较程度差异的数值皆适用于 此实施例。此法较易于实作。除此之外，m值也可采用依实际带宽调整的 方式。以上述重要性下载顺序方法求得n时间区间内可下载的帧张数为w， 加上该流于n时间区间内完整的帧张数为r，则m＝n×w/r。此法可以依据 带宽变化，尽可能让播放速度贴近正常速度。如：w＝r/2，以2倍速播放； 当w＝4r/5时，以1.25倍速播放。

而关于调整播放时间的信息，可考虑维持画面之间原本的距离比例。 如图10B所示，若原本一画面的播放时间为t_i，调整过的时间为t_j，则

$t_j=(t_1+n-m)+(t_i-t_1)\times \frac{m}{n}$

或画面之间的距离比例变为一样。如图10B所示，若前n-m时间单 位收到的画面个数为z，接着把剩余m时间单位切成两部分α、β，且 α∶β＝(n-m)∶m，然后把这z个画面的播放时间平均分布于[t₁+n-m，t₁+n-m+α] 中。然后，把剩余的m时间单位视为原本的n时间单位，原本的β时间视 为原本的m时间单位，递归执行上述步骤，直到切割出来的β时间长度小 于一个画面于正常速度下的播放时间长度。

在一实施例中，也可以采用如图10C所显示的二分法，将m控制在n 的一半，递归执行上述步骤，直到切割出来的时间长度小于一个画面于正 常速度下的播放时间长度，如图所示的n/2、n/4、n/8等等。

执行上述快速播放方法时，当缓冲区暂存的数据量高于一第二阈值 后，该第二阈值大于上述该第一阈值，恢复成正常播放速度。

可行立即切换方法

本发明在一实施例中，提出一种适应网络带宽的实时影音流方法。在 此方法中。原本以一第一比特传输率接收一第一流数据，而当网络已经稳 定后，可在一切换时间切换到以一第二比特传输率接收一第二流数据。此 切换时间是以目前播放时间、第一重要编码译码单元的播放时间、第二重 要编码译码单元的播放时间进行判断得到。此目前播放时间是此第一流数 据在判断时正在播放的时间。此第一重要编码译码单元的播放时间是要切 换的第二流数据中比目前播放时间还早的第二流数据中的多个影音数据 中最新的重要编码译码单元的播放时间。此第二重要编码译码单元的播放 时间是第二流数据中的影音数据中比目前播放时间还晚的第二流数据中 最旧的重要编码译码单元。此重要编码译码单元是根据影音数据的信息取 得对应每一影音数据内的多个编码译码单元所对应的重要性参数比较取 得。在一实施例中，此重要编码译码单元例如MPEG系列所使用的I帧， 或是在H.263、H.264、HEVC标准下所使用的I片段(Slice)都可用来解 释本实施例的方法。以下以MPEG系列所使用的I帧为实施例说明，但并 非以此为限。

请参照图11A，所示当网络状况已经稳定，可以从以一第一比特传输 率接收一第一流数据(如标号1110所示)，在一切换时间切换到以一第二 比特传输率接收一第二流数据(如标号1120所示)时，假设目前播放进 度为时间t_play，新流中比t_play旧的I帧中最新者(I_pre)的播放时间为t_pre， 新流中比t_play新的I帧中最旧者(I_next)的播放时间为t_next，可能的切换时 间为t_sw，则t_play＜t_sw≤t_next。

请参照图11B，所示当网络状况已经稳定，可以从以一第一比特传输 率接收一第一流数据(如标号1130所示)，在一切换时间切换到以一第二 比特传输率接收一第二流数据(如标号1140所示)时，假使再考虑播放 器认可的安全缓冲长度为t_safe时间单位，新流中[t_pre，t_sw)时间区间的I、P 画面数据及[t_sw，t_sw+t_safe]时间区间内全部数据及所需译码参数(如：H.264 的Sequence Parameter Sets and Picture Parameter Sets)的数据量总合为s， 目前新流中的影音提供者到影音接收者的可用带宽为w，则t_sw＜t_next的必要 条件为s/w≤t_sw-t_play＜t_next-t_play。在此“[]”表示包含，“()”表示不含，例如 时间区间采用“[t₁，t₂]”代表大于等于t₁且小于等于t₂的时间区间内，而 “[t₁，t₂)”代表大于等于t₁且小于t₂的时间区间内。

当判断结果为t_sw＜t_next时，影音接收者会边收看原流，边下载新流中[t_pre， t_sw)时间区间的I、P画面数据、[t_sw，t_sw+t_safe]时间区间内全部数据及所需译 码参数。当在原流中播放到t_sw处，就切换到新流的t_sw处，以上述修改时 戳(Timestamp)的技术，将新流中[t_pre，t_sw)时间区间的I、P画面数据的播 放时间，缩减到[t_sw处的上一个画面的播放时间，t_sw)时间区间内(如标号 1150所示)播完。如此就能在切换到另一流时直接从目前播放进度接续播 放。

若判断结果不可能为t_sw＜t_ne_xt时，则将原流播放到t_next时，再切换到新 流继续播放。并在切换前已下载该新流[t_next，t_next+t_safe]时间区间内的全部数 据及所需译码参数。

判断切换时间t_sw的方法，在多个实施例中，至少包括两种方法：

若t_next-t_play≤某一阈值时，可用暴力法直接尝试当t_sw为[t_play，t_next)的某 一画面的播放时间时，判断s/w≤t_sw-t_play＜t_next-t_play是否成立。满足此条件 的最小t_sw即为所求。

若t_next-t_play＞某一阈值时，可用二元搜索法来判断。即先将[t_play，t_next)取 中间点t_m，令t_sw-t_m，若s/w≤t_sw-t_play＜t_next-t_play，则将目前的t_m左半部分， 取代原本范围；若s/w＞t_sw-t_play，则将目前的t_m右半部分，取代原本范围。 然后递归执行上述的取中间点-判断程序。一直执行到连续两次取的中间 点的距离小于一阈值或小于一个画面的播放时间时，即停止尝试。此时最 后一次的判断结果，即为所求。上述的二元搜索法可参照图11C所示。取 中间点t_m，来得及下载则往左边再取左半部的一半，再进行判断是否来得 及下载，递归执行上述的取中间点-判断程序。

在上述重要性下载顺序方法适用的6个情境中，情境1和4中，上述 切换时间t_sw的判断与决定在影音提供者或接收者计算皆可。在情境3中， 为避免影音提供者互相沟通的复杂设计，本发明仅让影音接收者进行计 算。计算方式为利用上述重要性下载顺序方法评估是否能在时限内下载完 所需的快速播放数据。其它情境由于GOP结构未知，必须等到新流的影 音提供者已经发现I_next时，才能进行切换时间t_sw的计算。此时情境2和6 由影音提供者计算较快得到结果，而情境5下为避免影音提供者互相沟通 的复杂设计，本发明仅让影音接收者进行计算。

以上所述的具体实施例，对本发明的目的、技术方案和有益效果进行 了进一步详细说明，应理解的是，以上所述仅为本发明的具体实施例而已， 并不用于限制本发明，凡在本发明的精神和原则之内，所做的任何修改、 等同替换、改进等，均应包含在本发明的保护范围之内。