TWI520590B - 影音串流傳輸方法、影音裝置以及影音提供裝置 - Google Patents

影音串流傳輸方法、影音裝置以及影音提供裝置 Download PDF

Info

Publication number
TWI520590B
TWI520590B TW101147905A TW101147905A TWI520590B TW I520590 B TWI520590 B TW I520590B TW 101147905 A TW101147905 A TW 101147905A TW 101147905 A TW101147905 A TW 101147905A TW I520590 B TWI520590 B TW I520590B
Authority
TW
Taiwan
Prior art keywords
data
time
video
encoded data
audio
Prior art date
Application number
TW101147905A
Other languages
English (en)
Other versions
TW201427391A (zh
Inventor
游允帥
Original Assignee
財團法人工業技術研究院
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 財團法人工業技術研究院 filed Critical 財團法人工業技術研究院
Priority to TW101147905A priority Critical patent/TWI520590B/zh
Priority to CN201310050054.4A priority patent/CN103873889B/zh
Priority to US13/938,245 priority patent/US9680902B2/en
Publication of TW201427391A publication Critical patent/TW201427391A/zh
Application granted granted Critical
Publication of TWI520590B publication Critical patent/TWI520590B/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/762—Media network packet handling at the source 

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

影音串流傳輸方法、影音裝置以及影音提供裝置
本揭露提出一種影音串流傳輸方法、影音裝置以及影音提供裝置。
現今人們非常習慣使用網路來收看即時的(live)影音串流，例如大型比賽或表演的直播、道路或大樓的監控、游戲畫面擷取直播、遠距教學、線上即時新聞、災難現場畫面直播等。因為網路有多變的特性，所以影音接收者會使用一個資料緩衝器來儲存幾百毫秒至幾秒不等的影音資料，來減緩網路延遲抖動所造成的播放不連續性。然而，這個簡單的做法，並不能使即時影音串流的傳輸適應網路的變動。當網路壅塞時間長到令緩衝器的資料耗盡，影音接收者的傳統播放器有底下兩種反應。一種反應為不放棄任何未播資料，暫停播放一段時間直到緩衝區又有一定量資料再繼續播放，但如此會造成收看進度與即時進度落差變大。另一種反應為丟棄任何超過播放時間的資料，但這很可能會造成之後的畫面不能正確呈現。
為了解決上述問題，這十幾年來有許多方法被提出。其中有個叫做位元串流切換(Bitstream Switch)的做法有逐漸變為趨勢的傾向。此做法是把一個節目串流同時做出不同傳輸位元率(Bit Rate)的串流。影音接收者在適當時間點依據自身的網路環境，從上述串流中選擇不超過可用頻寬 的最高傳輸位元率的串流來觀賞。這個做法的好處是影音提供者僅需就大多數使用者感興趣或有辦法接收的幾種傳輸位元率(通常為3~5種)進行壓縮即可，故不會對影音提供者造成巨大負擔。另外，影音接收者得到的收看品質，大多情況下也很接近該網路環境下所能達到的最佳品質。
目前市面上至少已有兩種免費軟體產品可以提供即時產生不同傳輸位元率串流的功能。一種是Adobe®公司的“Flash Media Live Encoder”(簡稱FMLE)軟體，此軟體可以把網路攝影機傳過來的資料，同時壓縮出3種傳輸位元率的即時訊息通訊協議(Real-Time Messaging Protocol，簡稱RTMP)的影音串流，影像壓縮格式為VP6或H.264，聲音壓縮格式為mp3或NellyMoser。另一種軟體是開放源碼的“FFMpeg”，此軟體可以將原始的一條影音串流轉換出出眾多數目(取決於硬體能力)的影音串流(支援格式至少有：RTP、LiveFLV、RTMP)，且幾乎所有的壓縮格式都支援。另外，許多知名的影音分享平台，例如Youtube®、優酷®等，上面的影片大多都有幾種不同品質可供選擇。目前這些平台上的節目都是預先錄製的，而非即時產生，但大眾已經很習慣這種使用模式，所以很自然地會期望以後的即時影音分享平台也可以有不同品質的影音串流可供選擇。
然而，使用者並不能隨時切換串流，主要原因如下所述。一是網路的變化可能是短期的，使用者若太積極地因應網路變化來切換串流，會加劇網路的動盪。所以，使用者必須利用習知技藝中的頻寬評估技術，確認網路已經達 到另外一種穩定狀況再行切換。另外，由於主流影像壓縮演算法(H.264和Mpeg 2、4)採用I、P、B三種不同的畫框(Frame)來表示資料，其中P畫框或B畫框必須直接或間接參照先前最新的I畫框才可以正確解出畫面，故使用者切換至另一串流的時間點，會受限於I畫框出現的時間點。這會衍伸出兩個功能需求：一是在還未能切換前，要有辦法維持住可接受的觀賞品質，一是必須幫助使用者盡快進行切換。
最後，從目前的技術可以觀察到幾個使用者使用習慣的趨勢：(一)越來越多使用者改採平板電腦或智慧型手機來收看影音串流，這類設備的計算能力和電力有限；(二)熱門的節目通常會有幾千或幾百個以上使用者在收看；(三)P2P(Peer-to-peer)的架構風行，在P2P系統中，每個使用者同時也要把影音串流分享給別人。這些使用習慣的趨勢，會延伸出兩個效能需求：不可有太大計算量，以及不可太耗費網路頻寬。
本揭露提出一種適應網路頻寬的即時影音串流系統以及方法。
在多個實施範例其中之一，提出一種影音串流傳輸方法，包括接收串流資料，並監控從所述串流資料取得並暫存的多筆編碼資料，每一暫存的編碼資料包括多個編碼解碼單元，而所述編碼解碼單元以一傳送順序進行傳送，其 中此編碼資料在一實施例中可包括影音資料或可僅包括影像資料。
在此影音串流傳輸方法中，當需要調整傳輸品質時，取得編碼資料之資訊，並根據所述編碼資料之資訊取得對應每一編碼資料內所包括的編碼解碼單元對應的重要性參數，以及對應於所述之重要性參數，調整從影音串流傳輸通道所傳送的後續編碼資料的多個編碼解碼單元的傳送順序。
上述根據所述編碼資料調整編碼解碼單元的傳送順序方法在一實施例中包括判斷所述編碼資料之存量是否低於第一門檻值或高於第二門檻值，其中第二門檻值大於第一門檻值。當所述編碼資料之存量低於第一門檻值時，取得編碼資料之資訊，並根據所述編碼資料之資訊取得對應每一編碼資料內所包括的編碼解碼單元對應的重要性參數，以及對應於所述之重要性參數，調整從影音串流傳輸通道所傳送的後續編碼資料的多個編碼解碼單元的傳送順序。當編碼資料之存量高於第二門檻值時，停止調整此傳送順序。
在多個實施範例其中之一，提出一種影音串流傳輸方法，包括接收一串流資料，並將從串流資料取得的多筆編碼資料。輸出暫存的編碼資料以進行播放，並判斷當編碼資料之存量是否低於第一門檻值，當編碼資料之存量低於第一門檻值或已經用盡時，暫停輸出一第一時間區間，並暫存在第一時間區間內所收到的編碼資料。將在第一時間 區間內所收到的編碼資料調整為在一第二時間區間內加速播放完畢，其中第二時間區間小於第一時間區間，當該些影音資料之存量高於一第二門檻值時，恢復正常播放速度。此編碼資料在一實施例中可包括影音資料或可僅包括影像資料。
在多個實施範例其中之一，提出一種影音串流傳輸方法，包括以一第一位元傳輸率接收一第一串流資料。在一切換時間切換到以一第二位元傳輸率接收一第二串流資料，其中此切換時間是以目前播放時間、第一重要編碼解碼單元的播放時間、第二重要編碼解碼單元的播放時間進行判斷。此目前播放時間是第一串流資料在判斷時正在播放的時間，第一重要編碼解碼單元的播放時間是第二串流資料中比目前播放時間還早的第二串流資料中的多個編碼資料中最新的重要編碼解碼單元的播放時間，此第二重要編碼解碼單元的播放時間是第二串流資料中的編碼資料中比目前播放時間還晚的第二串流資料中最舊的重要編碼解碼單元，其中編碼資料的重要性判斷是根據編碼資料之資訊取得對應每一編碼資料內的多個編碼解碼單元所對應的重要性參數比較取得。此編碼資料在一實施例中可包括影音資料或可僅包括影像資料。
在多個實施範例其中之一，提出一種影音裝置，適用於從一串流資料接收多筆編碼資料，每一編碼資料包括多個編碼解碼單元，而所述編碼解碼單元以一編碼順序為傳送順序，其中此編碼資料包括影音資料或僅包括影像資料。 此影音裝置包括一緩衝器、一緩衝器監控模組以及一畫框要求模組。此緩衝器監控模組用以監控暫存於此緩衝器的編碼資料的存量，當編碼資料的存量低於第一門檻值時，發出一調整信號，當編碼資料的存量高於第二門檻值時，發出一停止調整信號。畫框要求模組響應於所述調整信號，輸出一畫框要求信號，以調整串流資料中，編碼資料內的編碼解碼單元的傳送順序。
在多個實施範例其中之一，上述影音裝置更包括一時戳調整模組，用以接收下載的編碼資料，並將編碼資料暫存到該緩衝器，其中時戳調整模組可將部分編碼資料的播放時間進行修改。
在多個實施範例其中之一，上述影音裝置更包括一串流要求模組，響應於調整信號與頻寬評估器之信號，輸出一位元率要求信號，用以提供編碼資料之資訊，以切換接收不同位元傳輸率的另一串流資料。
在多個實施範例其中之一，上述影音裝置更包括一上傳器與一排程器。所述上傳器用來將從該串流資料接收到的編碼資料傳出。排程器用來接收來自外部的另一畫框要求信號，此另一畫框要求信號包括由上傳器傳出的編碼資料中，每一編碼資料內所包括的編碼解碼單元對應的重要性參數，其中此重要性參數是根據這些編碼資料之資訊計算取得，排程器則根據重要性參數調整上傳器傳出的編碼資料內的編碼解碼單元的傳送順序。
上述影音裝置更包括一時戳調整模組與一時戳重整模 組。所述時戳調整模組用以接收下載的編碼資料，並將編碼資料暫存到緩衝器，其中時戳調整模組可將部分編碼資料的播放時間進行修改。時戳重整模組連接到時戳調整模組，用以將修改過的播放時間進行重整，以適合下一階影音接收者所要使用的影音串流資訊時間戳記。
另一實施例中，上述影音裝置更包括串流要求模組與一切換器。所述串流要求模組響應於調整信號與一頻寬評估器之信號，輸出一位元率要求信號，用以提供編碼資料之資訊，以切換接收不同位元傳輸率的另一串流資料。切換器用來接收來自外部的另一位元率要求信號，用來切換由上傳器所輸出的具有一第一位元傳輸率的一第一串流資料切換到具有一第二位元傳輸率的一第二串流資料，並判斷從第二串流資料的合適播放時間點開始傳送。
在多個實施範例其中之一，上述影音裝置更包括一時戳調整模組、一時戳重整模組、一上傳器與一排程器。此時戳調整模組用以接收下載的編碼資料，並將編碼資料暫存到緩衝器，其中此時戳調整模組可將部分編碼資料的播放時間進行修改。時戳重整模組連接到所述時戳調整模組，用以將修改過的播放時間進行重整，以適合下一階影音接收者所要使用的影音串流資訊時間戳記。上傳器連接到所述時戳重整模組，用來將從串流資料接收到的編碼資料傳出。排程器用來接收來自外部的另一畫框要求信號，此另一畫框要求信號包括由上傳器傳出的編碼資料中，每一編碼資料內所包括的編碼解碼單元對應的重要性參數，其中 此重要性參數是根據編碼資料之資訊計算取得，而此排程器根據重要性參數調整上傳器傳出的編碼資料內的編碼解碼單元的傳送順序。
在多個實施範例其中之一，提出一種影音裝置，適用於從一串流資料接收多筆編碼資料，每一編碼資料包括多個編碼解碼單元，而這些編碼解碼單元以一編碼順序為傳送順序，其中編碼資料包括影音資料或僅包括影像資料。此影音裝置包括一緩衝器、一緩衝器監控模組、一時戳調整模組、一畫框要求模組、串流要求模組、一時戳重整模組、一上傳器、一排程器以及一切換器。此緩衝器監控模組用以監控暫存於緩衝器的編碼資料的存量，當編碼資料的存量低於第一門檻值時，發出一調整信號，當編碼資料的存量高於第二門檻值時，發出一停止調整信號。時戳調整模組用以接收下載的編碼資料，並將編碼資料暫存到緩衝器，其中時戳調整模組可將部分編碼資料的播放時間進行修改。畫框要求模組響應於調整信號，輸出一畫框要求信號，以調整串流資料中，該些編碼資料內的編碼解碼單元的傳送順序。串流要求模組，響應於調整信號與頻寬評估結果，輸出位元率要求信號，用以提供編碼資料之資訊，以切換接收不同位元傳輸率的另一串流資料。時戳重整模組連接到時戳調整模組，用以將修改過的播放時間進行重整，以適合下一階影音接收者所要使用的影音串流資訊時間戳記。上傳器連接到時戳重整模組，用來將從串流資料接收到的編碼資料傳出。排程器用來接收來自外部的另一 畫框要求信號，此另一畫框要求信號包括由上傳器傳出的編碼資料中，每一編碼資料內所包括的編碼解碼單元對應的重要性參數，其中重要性參數是根據編碼資料之資訊計算取得，而此排程器根據重要性參數調整上傳器傳出的編碼資料內的編碼解碼單元的傳送順序。切換器用來接收來自外部的另一位元率要求信號，用來切換由該上傳器所輸出的具有一第一位元傳輸率的一第一串流資料切換到具有一第二位元傳輸率的一第二串流資料，並判斷從第二串流資料的合適播放時間點開始傳送。
在多個實施範例其中之一，提出一種影音提供裝置，包括一上傳器、一排程器以及一切換器。此上傳器用來傳送具有一第一位元傳輸率的一第一串流資料，其中此第一串流資料包括多筆編碼資料，每一編碼資料包括多個編碼解碼單元，而這些編碼解碼單元以一傳送順序排列，其中編碼資料包括影音資料或僅包括影像資料。排程器用來接收一畫框要求信號，並根據畫框要求信號調整上傳器傳出的編碼資料內的該些編碼解碼單元的傳送順序。此切換器用來接收來自外部的另一位元率要求信號，用來切換由上傳器所輸出的具有一第一位元傳輸率的一第一串流資料切換到具有一第二位元傳輸率的一第二串流資料，並判斷從第二串流資料的合適播放時間點開始傳送。
為讓本發明之上述和其他目的、特徵和優點能更明顯易懂，下文特舉較佳實施例，並配合所附圖式，作詳細說明如下。
本揭露提出一個適應網路頻寬的即時影音串流系統以及方法。
在多個實施例其中之一，本揭露所提出的適應網路頻寬的即時影音串流系統以及方法，當網路發生壅塞的一段時間中，影音接收者可以平順且正確地播放出此段時間內盡可能多的影音資料、或是對影音提供者/接收者有意義的影音資料，且播放進度跟影音提供者提供的最新進度之差距須維持在一固定範圍內。
在多個實施例其中之一，本揭露所提出的適應網路頻寬的即時影音串流系統以及方法，當影音串流存在其他不同傳輸位元率之串流時，影音接收者可以依據自身網路狀況，切換到不高於可用頻寬的最高傳輸位元率之串流收看。
在多個實施例其中之一，本揭露提出一個適應網路頻寬的即時影音串流系統以及方法，在效能上，可以達到不增加影音提供者/接收者太多的計算負擔，不增加冗餘影音資料以節省頻寬。某些相關研究採用增加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/IEC 14496-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秒。除此之外，此影音接收者的播放器於時間tstart時開始播放(緩衝器監控模組觀察到已傳送播放器認可的安全緩衝時間長度tsafe之資料量給播放器之時間點即為tstart)，則識別碼為n的I畫框應該於tstart+(n/x)秒時候播出。
若以底下方式判斷，在未來一段適宜時間內的可用頻寬為w，識別碼為n的I畫框的資料量大小預測值s和解碼花費時間預測值tdecode。如此便可求得識別碼為n的I畫框由影音提供者送出的最遲啟動下載時間turgent=(tstart+n/x)-tdecode-(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可以看出，本揭露所提出的方法的實施例，對於目前的傳輸效果和傳統的畫框忽略(Frame Skipping)的傳輸效果。目前兩者都可以確保nI、n+3P、n+6P、n+9P這4張畫面及時抵達影音接收者。然若傳輸中可用頻寬變小，相對於傳統的方式，本揭露所提出的方法有較高的機率可以確保n+6P和n+9P可以及時抵達影音接收者，因為本揭露不會在P畫框未傳完前浪費寶貴的頻寬來傳會錯失播放時間的n+1B。
圖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張正確解碼的畫面及時抵達影音接收者，比相關前案多2張。
在上述場景1中，影音提供者若非收到影音接收者依類型-緊迫性方法所指定的重要順序，也就是上述由影音接收者自行運算後傳來的「排序結果」，而是收到類型-緊迫性方法所需的參考資料，例如與排序相關的參考資訊(網路可用頻寬、目前播放進度、緩衝器之存量現狀等等)，則影音提供者會代替影音接收者執行類型-緊迫性方法來指定重要性。這樣做的好處是，若影音接收者的設備能力很差，可由設備能力較好的影音提供者代勞。不論類型-緊迫性方法的工作由誰來做，其產出還會被影音提供者調整一次。
一些額外的重要性指定策略會標示出某些畫面或某段聲音特別重要。這些策略可能是廣告商要求的，或是某程式解析影音資料後決定的。當影音提供者發現這些額外的重要性指定策略所標示的資料，在類型-緊迫性方法的產出排序中，是可以於這些資料的最遲解碼時間之前送到影音接收者，則排序結束，開始傳送資料。否則，影音提供者的排程器(Scheduler)會把這些標示資料的重要性，試著進 行提升的操作。
本揭露所提出額外的重要性指定策略方法，在多個實施例其中之一，可以採用額外標示法，詳細步驟如下所述。
首先，若所有比還未調整之標示資料還重要的資料(不含B畫面)的下載時間總和，已經超過此次評估對象集合的可用下載時間(先前提及的t’-t)。則無需再調整影音資料的重要性。若尚未超過，則目前尚未調整完畢的標示資料中重要性最大者，將其重要性提高到僅小於其參考的畫面資料中重要性最小者。提升過程中，若導致原本可及時下載的I畫框、P畫框變為來不及下載，則試著排除排程裡播放時間較該調整中資料晚的B畫面(從播放時間最晚者逐一排除)。判斷釋放出來的排程時間能否容下此該調整中資料，若可以則該標示資料調整完畢，若不行，則放棄提升此額外標示的資料。此實施例可以參照圖9，為說明本揭露的實施例中，依據額外的重要性指定策略，採用額外標示法調整影音資料的重要性之過程示意圖。如圖9所示，以n+4B為例，因為額外的重要性指定策略，將n+4B提升到n+6P與n+9P之間。
在上述場景2中(即單一影音提供者，每個GOP的結構未知)，影音接收者無法確定目前評估對象集合的大小，故只能提供參考資訊給影音提供者請其代為指定重要性。要提供的資訊至少包括tstart(影音接收者的播放器開始播放的時間)、影音接收者第一個播出的畫面的識別碼、未來一段適宜時間內的可用頻寬為w、解碼花費時間預測值 tdecode。
在上述場景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所示，若原本一畫面的播放時間為ti，調整過的時間為tj，則
或畫面之間的距離比例變為一樣。如圖10B所示，若前n-m時間單位收到的畫面個數為z，接著把剩餘m時間單位切成兩部分α、β，且α：β=(n-m)：m，然後把這z個畫面的播放時間平均分布於[t1+n-m,t1+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所示)時，假設目前播放進度為時間tplay，新串流中比tplay舊的I畫框中最新者(Ipre)的播放時間為tpre，新串流中比tplay新的I畫框中最舊者(Inext)的播放時間為tnext，可能的切換時間為tsw，則tplay<tsw≦tnext。
請參照圖11B，所示當網路狀況已經穩定，可以從以一第一位元傳輸率接收一第一串流資料(如標號1130所示),在一切換時間切換到以一第二位元傳輸率接收一第二串流資料(如標號1140所示)時，假使再考慮播放器認可的安全緩衝長度為tsafe時間單位，新串流中[tpre,tsw)時間區間的I、P畫面資料及[tsw,tsw+tsafe]時間區間內全部資料及所需解碼參數(如：H.264的Sequence Parameter Sets and Picture Parameter Sets)之資料量總合為S，目前新串流中的影音提供者到影音接收者的可用頻寬為w，則tsw<tnext的必要條件為s/w≦tsw-tplay<tnext-tplay。在此[]表示包含，()表示不含，例如時間區間採用“[t1,t2]”代表大於等於t1且小於等於t2的時間區間內，而“[t1,t2)”代表大於等於t1且小於t2的時間區間內。
當判斷結果為tsw<tnext時，影音接收者會邊收看原串流，邊下載新串流中[tpre,tsw)時間區間的I、P畫面資料、[tsw,tsw+tsafe]時間區間內全部資料及所需解碼參數。當在 原串流中播放到tsw處，就切換到新串流的tsw處，以上述修改時戳(Timestamp)之技術，將新串流中[tpre,tsw)時間區間的I、P畫面資料的播放時間，縮減到[tsw處的上一個畫面的播放時間，tsw)時間區間內(如標號1150所示)播完。如此就能在切換到另一串流時直接從目前播放進度接續播放。
若判斷結果不可能為tsw<tnext時，則將原串流播放到tnext時，再切換到新串流繼續播放。並在切換前已下載該新串流[tnext,tnext+tsafe]時間區間內之全部資料及所需解碼參數。
判斷切換時間tsw的方法，在多個實施例中，至少包括兩種方法：
若tnext-tplay≦某一門檻值時，可用暴力法直接嘗試當tsw為[tplay,tnext)的某一畫面的播放時間時，判斷s/w≦tsw-tplay<tnext-tplay是否成立。滿足此條件的最小tsw即為所求。
若tnext-tplay>某一門檻值時，可用二元搜索法來判斷。即先將[tplay,tnext)取中間點tm，令tsw=tm，若s/w≦tsw-tplay<tnext-tplay，則將目前的tm左半部分，取代原本範圍；若s/w>tsw-tplay，則將目前的tm右半部分，取代原本範圍。然後遞迴執行上述的取中間點-判斷程序。一直執行到連續兩次取的中間點的距離小於一門檻值或小於一個畫面的播放時間時，即停止嘗試。此時最後一次的判斷結果，即為所求。上述的二元搜索法可參照圖11C所示。取中間點tm，來得及下載則往左邊再取左半部的一半，再進行判 斷是否來得及下載，遞迴執行上述的取中間點-判斷程序。
在上述重要性下載順序方法適用的6個情境中，情境1和4中，上述切換時間tsw的判斷與決定在影音提供者或接收者計算皆可。在情境3中，為避免影音提供者互相溝通的複雜設計，本揭露僅讓影音接收者進行計算。計算方式為利用上述重要性下載順序方法評估是否能在時限內下載完所需的快速播放資料。其他情境由於GOP結構未知，必須等到新串流的影音提供者已經發現Inext時，才能進行切換時間tsw的計算。此時情境2和6由影音提供者計算較快得到結果，而情境5下為避免影音提供者互相溝通的複雜設計，本揭露僅讓影音接收者進行計算。
雖然本發明已以較佳實施例揭露如上，然其並非用以限定本發明，任何熟習此技藝者，在不脫離本發明之精神和範圍內，當可作些許之更動與潤飾，因此本發明之保護範圍當視後附之申請專利範圍所界定者為準。
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‧‧‧快速播放的時間區間
圖1A與1B為分別說明本揭露所提出適應網路頻寬的即時影音串流系統的不同實施例的架構示意圖。
圖2A~2C為繪示本揭露多個實施例其中之一的即時影音串流系統的客戶端所使用之系統方塊示意圖。
圖3為繪示本揭露多個實施例其中之一的即時影音串流系統的主機端所使用之系統方塊示意圖。
圖4A~4C為繪示本揭露多個實施例其中之一的即時影 音串流系統的客戶端所使用之系統方塊示意圖。
圖5為繪示本揭露多個實施例其中之一的重要性下載順序的運作方法流程示意圖。
圖6為繪示說明本揭露的實施例中判斷畫框最遲啟動下載時間的方法示意圖。
圖7A、7B、7C為說明本揭露的實施例中，使用資料類型配置重要性的示意圖。
圖8A、8B、8C為說明本揭露的實施例中，依據播放時間的緊迫性來調整影音資料的重要性之過程示意圖。
圖9為說明本揭露的實施例中，依據額外的重要性指定策略，採用額外標示法調整影音資料的重要性之過程示意圖。
圖10A、10B、10C為繪示說明本揭露多個實施例中，採用快速播放方法以適應網路頻寬過程之示意圖。
圖11A、11B、11C為繪示說明本揭露多個實施例中，採用可行立即切換方法進行切換到不同傳輸位元率之串流過程之示意圖。
100‧‧‧客戶端(Client)
210‧‧‧播放器(Player)
220‧‧‧緩衝單元(Buffer Unit)
222‧‧‧緩衝器
224‧‧‧緩衝器監控模組
230‧‧‧頻寬評估器(Bandwidth Estimator)
240‧‧‧下載器(Downloader)
250‧‧‧時戳調整模組(Timestamp Regulator)
260‧‧‧畫框要求模組(Frame Demander)
270‧‧‧串流要求模組(Stream demander)

Claims (44)

  1. 一種影音串流傳輸方法，包括：接收串流資料，並監控從該串流資料取得並暫存的多筆編碼資料，每一暫存的該編碼資料包括多個編碼解碼單元，其中該編碼資料包括影音資料或僅包括影像資料；以及當一調整傳輸事件啟動時，取得該些編碼資料之資訊，並根據該些編碼資料之資訊取得對應每一影音串流傳輸通道所傳送的後續編碼資料的多個編碼解碼單元對應的重要性參數，以及對應於該些重要性參數，調整該後續編碼資料的多個編碼解碼單元的傳送順序。
  2. 如專利申請範圍第1項所述之影音串流傳輸方法，其中調整該後續編碼資料的該些編碼解碼單元的傳送順序包括：判斷當該些編碼資料之存量是否低於一第一門檻值或高於一第二門檻值，其中該第二門檻值大於該第一門檻值，其中當該些編碼資料之存量低於該第一門檻值時，取得該些編碼資料之資訊，並根據該些編碼資料之資訊取得對應每一影音串流傳輸通道所傳送的後續編碼資料的多個編碼解碼單元對應的重要性參數，以及對應於該些重要性參數，調整該後續編碼資料的多個編碼解碼單元的傳送順序；以及當該些編碼資料之存量高於該第二門檻值時，停止調整 該傳送順序。
  3. 如專利申請範圍第1項所述之影音串流傳輸方法，其中該些編碼資料之資訊包括該些編碼資料之圖像群組(GOP)資訊、被評估的該些編碼資料之播出時間、預測資料量大小、預測解碼時間、可用頻寬、該些編碼資料提供來源的數量或該些編碼資料是否採用網路編碼(Network Coding)方式。
  4. 如專利申請範圍第1項所述之影音串流傳輸方法，其中該些編碼解碼單元彼此包括交互參照關聯特性。
  5. 如專利申請範圍第1項所述之影音串流傳輸方法，其中該些編碼解碼單元包括符合動畫專家小組(MPEG)標準的I畫框、P畫框以及B畫框。
  6. 如專利申請範圍第1項所述之影音串流傳輸方法，其中該些編碼解碼單元包括符合H.263、H.264、或HEVC標準的I、P、B片段(Slice)。
  7. 如專利申請範圍第1項所述之影音串流傳輸方法，其中每一該影音資料內所包括的該些編碼解碼單元對應的該些重要性參數，是根據該些編碼解碼單元的類型判斷而指定該些編碼解碼單元對應的該些重要性參數。
  8. 如專利申請範圍第7項所述之影音串流傳輸方法，其中每一該影音資料內所包括的該些編碼解碼單元對應的該些重要性參數，更包括該些編碼解碼單元的播放時間急迫性而指定該些編碼解碼單元對應的該些重要性參數。
  9. 如專利申請範圍第7項所述之影音串流傳輸方法，其 中每一該影音資料內所包括的該些編碼解碼單元對應的重要性參數更包括根據額外指定的要求而調整該些編碼解碼單元對應的該些重要性參數。
  10. 如專利申請範圍第7項所述之影音串流傳輸方法，其中每一該影音資料內所包括的該些編碼解碼單元對應的該些重要性參數，更包括該些編碼解碼單元的播放時間急迫性以及額外指定的要求而指定該些編碼解碼單元對應的該些重要性參數。
  11. 如專利申請範圍第1項所述之影音串流傳輸方法，其中每一該編碼資料內所包括的該些編碼解碼單元對應的該些重要性參數，是採用該些編碼資料之多個或一個圖像群組(GOP)、或該圖像群組(GOP)之全部或是一部份做為評估對象集合，評估該些重要性參數。
  12. 如專利申請範圍第11項所述之影音串流傳輸方法，其中對該評估對象集合進行評估前，先取得下一個評估對象集合的最遲啟動下載時間，以取得該評估對象集合可使用的時間。
  13. 一種影音串流傳輸方法，包括：接收一串流資料，並將從該串流資料取得的多筆編碼資料暫存，其中該編碼資料包括影音資料或僅包括影像資料；輸出暫存的該些編碼資料以一第一速度進行播放；當一調整傳輸事件啟動時，暫停輸出一第一時間區間，並暫存在該第一時間區間內所收到的該些編碼資料；以及將在該第一時間區間內所收到的該些編碼資料中播放 時間落於該第一時間區間內者調整為在一第二時間區間內以一第二速度播放完畢，其中該第二時間區間小於該第一時間區間，而該第二速度快於該第一速度。
  14. 如專利申請範圍第13項所述之影音串流傳輸方法，其中判斷調整傳輸事件發生的步驟包括：判斷當該些編碼資料之存量是否低於一第一門檻值，當該些編碼資料之存量低於該第一門檻值或已經用盡時，啟動該傳輸方法，當該些編碼資料之存量高於一第二門檻值時，恢復以該第一速度進行播放。
  15. 如專利申請範圍第13項所述之影音串流傳輸方法，其中該將在該第一時間區間內所收到的該些編碼資料中播放時間落於該第一時間區間內者，調整為在該第二時間區間內播放完畢的步驟包括將該些編碼資料的播放時間資訊，修改為落在該第二時間區間內播放。
  16. 如專利申請範圍第15項所述之影音串流傳輸方法，其中在該第二時間區間內所收到的該些編碼資料中播放時間落於該第二時間區間內者，也採用該第二速度播放。
  17. 如專利申請範圍第13項所述之影音串流傳輸方法，其中每一暫存的該編碼資料包括多個編碼解碼單元，該第一時間區間至少要長到足以下載該些編碼資料中的一或多個重要編碼解碼單元，其中該或該些重要編碼解碼單元是根據該些編碼資料之資訊取得對應每一該編碼資料內的該些編碼解碼單元所對應的重要性參數比較取得。
  18. 如專利申請範圍第17項所述之影音串流傳輸方法， 其中該些編碼解碼單元包括符合動畫專家小組(MPEG)標準的I畫框、P畫框以及B畫框。
  19. 如專利申請範圍第17項所述之影音串流傳輸方法，其中該些編碼解碼單元包括符合H.263、H.264、或HEVC標準的I、P、B片段(Slice)。
  20. 如專利申請範圍第13項所述之影音串流傳輸方法，其中該第一時間區間介於2到20秒。
  21. 如專利申請範圍第13項所述之影音串流傳輸方法，其中該第二時間區間等於該第一時間區間除以一大於1之數值。
  22. 如專利申請範圍第13項所述之影音串流傳輸方法，其中該第二時間區間依照實際頻寬調整。
  23. 如專利申請範圍第22項所述之影音串流傳輸方法，其中在該第一時間區間內可下載畫框數量為w，在該串流資料中該第一時間區間內完整畫框數量為r，則該第二時間區間為該第一時間區間乘以w/r之值，其中w與r為正整數。
  24. 如專利申請範圍第13項所述之影音串流傳輸方法，其中該第二時間區間等於該第一時間區間的一半。
  25. 一種影音串流傳輸方法，包括：以一第一位元傳輸率接收一第一串流資料；以及在一切換時間切換到以一第二位元傳輸率接收一第二串流資料，其中該切換時間是以目前播放時間、第一重要編碼解碼單元的播放時間、第二重要編碼解碼單元的播放 時間進行判斷，其中該目前播放時間是該第一串流資料在判斷時正在播放的時間，該第一重要編碼解碼單元的播放時間是該第二串流資料中比該目前播放時間還早的該第二串流資料中的多個編碼資料中最新的重要編碼解碼單元的播放時間，該第二重要編碼解碼單元的播放時間是該第二串流資料中的該些編碼資料中比該目前播放時間還晚的該第二串流資料中最舊的重要編碼解碼單元，其中該重要編碼資料是根據該些編碼資料之資訊取得對應每一該編碼資料內的多個編碼解碼單元所對應的重要性參數比較取得。
  26. 如專利申請範圍第25項所述之影音串流傳輸方法，其中，若判斷可以於第二重要編碼解碼單元的播放時間前切換，則維持播放該第一串流資料到該切換時間前，並同時接收該第二串流資料中之該些重要編碼解碼單元；到了該切換時間的前一畫面之播放時間後切換到該第二串流資料，並修改接收的該第二串流資料中之該些重要編碼解碼單元的播放時間資訊，以便在從該切換時間的前一畫面之播放時間到該切換時間播放完畢。
  27. 如專利申請範圍第25項所述之影音串流傳輸方法，其中，若判斷為不能於第二重要編碼解碼單元的播放時間前切換，則在該第二重要編碼解碼單元的播放時間切換到該第二串流資料。
  28. 如專利申請範圍第25項所述之影音串流傳輸方法， 其中，該些編碼解碼單元包括符合動畫專家小組(MPEG)標準的I畫框、P畫框以及B畫框。
  29. 如專利申請範圍第25項所述之影音串流傳輸方法，其中該些編碼解碼單元包括符合H.263、H.264、或HEVC標準的I、P、B片段(Slice)。
  30. 如專利申請範圍第25項所述之影音串流傳輸方法，其中，該切換時間更進一步考慮額外可用的網路頻寬。
  31. 如專利申請範圍第30項所述之影音串流傳輸方法，其中，該切換時間以一暴力法進行判斷，也就是該目前播放時間到該第二重要編碼解碼單元的播放時間小於一門檻值時，直接將該切換時間指定為從該目前播放時間到該第二重要編碼解碼單元的播放時間之間的一播放時間來進行判斷。
  32. 如專利申請範圍第30項所述之影音串流傳輸方法，其中，該切換時間以二元搜索法進行判斷，也就是以一可能範圍的中間點作判斷，遞迴測試直到兩次測試的中間點的時間距離小於一門檻值或小於一個畫面的播放時間。
  33. 一影音裝置，適用於從一串流資料接收多筆編碼資料，每一該編碼資料包括多個編碼解碼單元，而該些編碼解碼單元以一編碼順序為傳送順序，其中該編碼資料包括影音資料或僅包括影像資料，該影音裝置包括：一緩衝器；一緩衝器監控模組，用以監控暫存於該緩衝器的該些編碼資料的存量，當該些編碼資料的存量低於第一門檻值 時，發出一調整信號，當該些編碼資料的存量高於第二門檻值時，發出一停止調整信號；以及畫框要求模組，響應於該調整信號，輸出一畫框要求信號，以調整該串流資料中，該些編碼資料內的該些編碼解碼單元的傳送順序。
  34. 如專利申請範圍第33項所述之影音裝置，其中該畫框要求信號包括該些編碼解碼單元對應的重要性參數，其中該些編碼解碼單元對應的重要性參數是根據該些編碼資料之圖像群組(GOP)資訊、該些編碼資料提供來源的數量、該些編碼資料是否使用網路編碼(Network Coding)、該些編碼資料之播出時間、預測資料量大小、預測解碼時間以及可用頻寬之部分或是組合計算取得。
  35. 如專利申請範圍第33項所述之影音裝置，其中該畫框要求信號包括網路可用頻寬、目前播放進度、緩衝器現狀三者全部或部分之組合。
  36. 如專利申請範圍第33項所述之影音裝置，更包括一時戳調整模組，用以接收下載的該些編碼資料，並將該些編碼資料暫存到該緩衝器，其中該時戳調整模組可將部分該些編碼資料的播放時間進行修改。
  37. 如專利申請範圍第36項所述之影音裝置，更包括一串流要求模組，響應於該調整信號與頻寬評估結果，輸出一位元率要求信號，用以提供該些編碼資料之資訊，以切換接收不同位元傳輸率的另一串流資料。
  38. 如專利申請範圍第33項所述之影音裝置，更包括 一上傳器，用來將從該串流資料接收到的該些編碼資料傳出；以及一排程器，用來接收來自外部的另一畫框要求信號，該另一畫框要求信號包括由該上傳器傳出的該些編碼資料中，每一該編碼資料內所包括的該些編碼解碼單元對應的重要性參數或用以計算每一該編碼資料所包括的該些編碼解碼單元對應的重要性參數之資訊，其中該排程器根據該些重要性參數調整該上傳器傳出的該些編碼資料內的該些編碼解碼單元的傳送順序。
  39. 如專利申請範圍第38項所述之影音裝置，其中每一該編碼資料所包括的該些編碼解碼單元對應的重要性參數之資訊包括根據該些編碼資料之圖像群組(GOP)資訊、該些編碼資料提供來源的數量、該些編碼資料是否使用網路編碼(Network Coding)、該些編碼資料之播出時間、預測資料量大小、預測解碼時間以及可用頻寬之部分或其組合計算取得。
  40. 如專利申請範圍第38項所述之影音裝置，更包括一時戳調整模組，用以接收下載的該些編碼資料，並將該些編碼資料暫存到該緩衝器，其中該時戳調整模組可將部分該些編碼資料的播放時間進行修改；以及一時戳重整模組，連接到該時戳調整模組，用以將修改過的播放時間進行重整，以適合下一階影音接收者所要使用的影音串流資訊時間戳記。
  41. 如專利申請範圍第40項所述之影音裝置，更包括一串流要求模組，響應於該調整信號與一頻寬評估器之信號，輸出一位元率要求信號，用以提供該些編碼資料之資訊，以切換接收不同位元傳輸率的另一串流資料；以及一切換器，用來接收來自外部的另一位元率要求信號，用來切換由該上傳器所輸出的具有一第一位元傳輸率的一第一串流資料切換到具有一第二位元傳輸率的一第二串流資料，並判斷從該第二串流資料的合適播放時間點開始傳送。
  42. 一種影音提供裝置，包括：一上傳器，用來傳送具有一第一位元傳輸率的一第一串流資料，其中該第一串流資料包括多筆編碼資料，每一該編碼資料包括多個編碼解碼單元，而該些編碼解碼單元以一傳送順序排列，其中該編碼資料包括影音資料或僅包括影像資料；以及一排程器，用來接收來自外部的一畫框要求信號，該畫框要求信號包括由該上傳器傳出的該些編碼資料中，每一該編碼資料內所包括的該些編碼解碼單元對應的重要性參數或用以計算每一該編碼資料所包括的該些編碼解碼單元對應的重要性參數之資訊，其中該排程器根據該些重要性參數調整該上傳器傳出的該些編碼資料內的該些編碼解碼單元的傳送順序。
  43. 如專利申請範圍第42項所述之影音提供裝置，其中 每一該編碼資料所包括的該些編碼解碼單元對應的重要性參數之資訊包括根據該些編碼資料之圖像群組(GOP)資訊、該些編碼資料提供來源的數量、該些編碼資料是否使用網路編碼(Network Coding)、該些編碼資料之播出時間、預測資料量大小、預測解碼時間以及可用頻寬之部分或其組合計算取得。
  44. 如專利申請範圍第42項所述之影音提供裝置，更包括一切換器，用來接收來自外部的一位元率要求信號，用來控制該上傳器將具有該第一位元傳輸率的該第一串流資料切換輸出具有一第二位元傳輸率的一第二串流資料，並判斷從該第二串流資料的合適播放時間點開始傳送。
TW101147905A 2012-12-17 2012-12-17 影音串流傳輸方法、影音裝置以及影音提供裝置 TWI520590B (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
TW101147905A TWI520590B (zh) 2012-12-17 2012-12-17 影音串流傳輸方法、影音裝置以及影音提供裝置
CN201310050054.4A CN103873889B (zh) 2012-12-17 2013-02-08 影音流传输方法、影音装置以及影音提供装置
US13/938,245 US9680902B2 (en) 2012-12-17 2013-07-10 Media streaming method and device using the same

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
TW101147905A TWI520590B (zh) 2012-12-17 2012-12-17 影音串流傳輸方法、影音裝置以及影音提供裝置

Publications (2)

Publication Number Publication Date
TW201427391A TW201427391A (zh) 2014-07-01
TWI520590B true TWI520590B (zh) 2016-02-01

Family

ID=50911961

Family Applications (1)

Application Number Title Priority Date Filing Date
TW101147905A TWI520590B (zh) 2012-12-17 2012-12-17 影音串流傳輸方法、影音裝置以及影音提供裝置

Country Status (3)

Country Link
US (1) US9680902B2 (zh)
CN (1) CN103873889B (zh)
TW (1) TWI520590B (zh)

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104244033B (zh) * 2014-09-03 2017-12-08 乐视致新电子科技（天津）有限公司 视频播放方法和装置、智能终端
JP2015153252A (ja) * 2014-02-17 2015-08-24 株式会社リコー 通信システム、通信装置及びプログラム
CN106528278B (zh) 2015-09-14 2019-06-25 纬创资通（上海）有限公司 硬件负载调整方法及电子装置
KR102547320B1 (ko) 2016-02-01 2023-06-23 삼성전자주식회사 전자 장치 및 전자 장치의 제어 방법
CN106899863B (zh) * 2016-06-28 2019-10-25 阿里巴巴集团控股有限公司 一种数据处理方法及装置
USD804532S1 (en) * 2016-10-04 2017-12-05 Google Llc Media streaming device
USD802627S1 (en) * 2016-10-04 2017-11-14 Google Llc Media streaming device
USD804533S1 (en) * 2016-10-04 2017-12-05 Google Llc Media streaming device
IT201600130103A1 (it) * 2016-12-22 2018-06-22 St Microelectronics Srl Procedimento di compensazione dello skew di orologio e relativo sistema
US10341225B2 (en) * 2016-12-30 2019-07-02 Hughes Network Systems, Llc Bonding of satellite terminals
US10667016B2 (en) * 2017-06-19 2020-05-26 Electronics And Telecommunications Research Institute Peer and method for adjusting starting point of the peer
US10652166B2 (en) * 2017-06-27 2020-05-12 Cisco Technology, Inc. Non-real time adaptive bitrate recording scheduler
CN108280406A (zh) * 2017-12-30 2018-07-13 广州海昇计算机科技有限公司 一种基于分段双流模型的行为识别方法、***及装置
CN108391168B (zh) * 2018-02-02 2020-10-02 浙江吉博教育科技有限公司 一种基于互联网的教育视频控制装置
CN108712675B (zh) * 2018-05-29 2019-11-26 广州梦映动漫网络科技有限公司 一种动态漫画中动画元素的回放控制方法以及电子设备
CN109218759A (zh) * 2018-09-27 2019-01-15 广州酷狗计算机科技有限公司 推送媒体流的方法、装置、服务器及存储介质
TWI683572B (zh) * 2018-11-30 2020-01-21 國立虎尾科技大學 基於畫面動態資訊的視訊位元率傳輸控制方法
CN111385642A (zh) * 2018-12-29 2020-07-07 阿里巴巴集团控股有限公司 媒体信息的处理方法、装置、服务器、设备及存储介质
EP3687176A1 (en) * 2019-01-22 2020-07-29 InterDigital CE Patent Holdings A client and a method for managing, at the client, a streaming session of a multimedia content
US10951902B2 (en) * 2019-06-12 2021-03-16 Rovi Guides, Inc. Systems and methods for multiple bit rate content encoding
CN112752109B (zh) * 2019-10-30 2022-05-17 上海哔哩哔哩科技有限公司 视频播放控制方法和***
CN112804579B (zh) * 2019-11-14 2023-02-28 上海哔哩哔哩科技有限公司 视频播放方法、装置、计算机设备和可读存储介质
CN113497669B (zh) * 2020-03-20 2023-07-11 华为技术有限公司 编码数据包的传输方法、装置、电子设备和存储介质
CN111478915B (zh) * 2020-04-14 2022-10-14 广州酷狗计算机科技有限公司 直播数据的推流方法、装置、终端及存储介质
CN112423061A (zh) * 2020-10-28 2021-02-26 卡莱特（深圳）云科技有限公司 一种节目播放***
US11470380B1 (en) * 2021-03-26 2022-10-11 Meta Platforms, Inc. Systems and methods for adaptively managing live video streaming
US20220394073A1 (en) * 2021-06-08 2022-12-08 Comcast Cable Communications, Llc Method and apparatus for determining bitrate switch points
CN115002086B (zh) * 2022-05-23 2024-04-02 阿里巴巴（中国）有限公司 实时流媒体的传输方法及电子设备
CN115802074B (zh) * 2022-11-10 2024-03-29 中国联合网络通信集团有限公司 一种多路视频传输方法、装置、设备及介质

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6526097B1 (en) 1999-02-03 2003-02-25 Sarnoff Corporation Frame-level rate control for plug-in video codecs
US6747991B1 (en) 2000-04-26 2004-06-08 Carnegie Mellon University Filter and method for adaptively modifying the bit rate of synchronized video and audio streams to meet packet-switched network bandwidth constraints
US7260826B2 (en) 2000-05-31 2007-08-21 Microsoft Corporation Resource allocation in multi-stream IP network for optimized quality of service
US7542435B2 (en) * 2004-05-12 2009-06-02 Nokia Corporation Buffer level signaling for rate adaptation in multimedia streaming
US8099755B2 (en) 2004-06-07 2012-01-17 Sling Media Pvt. Ltd. Systems and methods for controlling the encoding of a media stream
US7543073B2 (en) * 2004-12-10 2009-06-02 Microsoft Corporation System and process for performing an exponentially weighted moving average on streaming data to establish a moving average bit rate
CN1941681B (zh) * 2005-09-30 2012-01-25 财团法人工业技术研究院 网络带宽分配方法
US8214516B2 (en) * 2006-01-06 2012-07-03 Google Inc. Dynamic media serving infrastructure
US7965771B2 (en) 2006-02-27 2011-06-21 Cisco Technology, Inc. Method and apparatus for immediate display of multicast IPTV over a bandwidth constrained network
US7962637B2 (en) 2006-11-03 2011-06-14 Apple Computer, Inc. Dynamic adjustments of video streams
JP4753204B2 (ja) * 2006-11-17 2011-08-24 株式会社ソニー・コンピュータエンタテインメント 符号化処理装置および符号化処理方法
US7996872B2 (en) 2006-12-20 2011-08-09 Intel Corporation Method and apparatus for switching program streams using a variable speed program stream buffer coupled to a variable speed decoder
US7668170B2 (en) * 2007-05-02 2010-02-23 Sharp Laboratories Of America, Inc. Adaptive packet transmission with explicit deadline adjustment
CN101436955B (zh) * 2007-11-12 2012-04-04 华为技术有限公司 以太网物理层oam开销的发送、接收方法及发送、接收装置
TWI378718B (en) 2009-06-05 2012-12-01 Univ Nat Taiwan Method for scaling video content according to bandwidth rate
JP2011009904A (ja) * 2009-06-24 2011-01-13 Hitachi Ltd 無線映像配信システム、コンテンツビットレート制御方法及びコンテンツビットレート制御プログラムを記憶したコンピュータ読み取り可能な記録媒体
US8340126B2 (en) 2010-06-07 2012-12-25 Lockheed Martin Corporation Method and apparatus for congestion control
US8675577B2 (en) 2010-12-20 2014-03-18 Intel Corporation Signaling techniques for a multimedia-aware radio and network adaptation
CN102780935B (zh) * 2012-08-03 2014-12-10 上海交通大学 一种支持多流流媒体动态传输的***

Also Published As

Publication number Publication date
CN103873889B (zh) 2018-01-23
US20140173055A1 (en) 2014-06-19
US9680902B2 (en) 2017-06-13
CN103873889A (zh) 2014-06-18
TW201427391A (zh) 2014-07-01

Similar Documents

Publication Publication Date Title
TWI520590B (zh) 影音串流傳輸方法、影音裝置以及影音提供裝置
US11470405B2 (en) Network video streaming with trick play based on separate trick play files
US10547850B2 (en) Audio splitting with codec-enforced frame sizes
US9832534B2 (en) Content transmission device and content playback device
KR102110627B1 (ko) 적응적 비트레이트 스트리밍에서 대역폭 할당을 위한 방법들 및 디바이스들
US20140359678A1 (en) Device video streaming with trick play based on separate trick play files
US10148990B2 (en) Video streaming resource optimization
CN109792546B (zh) 从服务器向客户端设备传送视频内容的方法
US10277911B2 (en) Video processing workload management
US20170142029A1 (en) Method for data rate adaption in online media services, electronic device, and non-transitory computer-readable storage medium
US10091265B2 (en) Catching up to the live playhead in live streaming
EP3466081A1 (en) Catching up to the live playhead in live streaming
WO2009103351A1 (en) Method and apparatus for obtaining media over a communications network
US10721284B2 (en) Encoding and decoding of live-streamed video using common video data shared between a transmitter and a receiver
JP2014192565A (ja) 映像処理装置、映像処理方法及びコンピュータプログラム
US10356159B1 (en) Enabling playback and request of partial media fragments
US9667885B2 (en) Systems and methods to achieve interactive special effects
US10313759B1 (en) Enabling playback and request of partial media fragments
US11303940B2 (en) Transmission apparatus, transmission method, and non-transitory computer-readable storage medium
EP4195626A1 (en) Streaming media content as media stream to a client system
CA3214167A1 (en) Methods, systems, and apparatuses for improved transmission of content
Onifade et al. Guaranteed QoS for Selective Video Retransmission