[go: up one dir, main page]

TW201316814A - 用於傳送及接收數位訊號之方法、傳送器、以及接收器 - Google Patents

用於傳送及接收數位訊號之方法、傳送器、以及接收器 Download PDF

Info

Publication number
TW201316814A
TW201316814A TW101118714A TW101118714A TW201316814A TW 201316814 A TW201316814 A TW 201316814A TW 101118714 A TW101118714 A TW 101118714A TW 101118714 A TW101118714 A TW 101118714A TW 201316814 A TW201316814 A TW 201316814A
Authority
TW
Taiwan
Prior art keywords
data
data block
message
digital signal
block
Prior art date
Application number
TW101118714A
Other languages
English (en)
Inventor
Xiaoming Bao
Rongshan Yu
Susanto Rahardja
Original Assignee
Agency Science Tech & Res
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 Agency Science Tech & Res filed Critical Agency Science Tech & Res
Publication of TW201316814A publication Critical patent/TW201316814A/zh

Links

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/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2662—Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities
    • 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/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • 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/233—Processing of audio elementary streams
    • 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/2402—Monitoring of the downstream path of the transmission network, e.g. bandwidth available
    • 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP

Landscapes

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

Abstract

根據一實施例，本發明提供一種傳送數位訊號的方法，其包含：將代表該數位訊號的資料分割成複數個資料區塊；根據資料區塊中包含的所需資料量來處理每一個資料區塊；針對每一個已處理資料區塊來決定該已處理資料區塊的大小；產生一訊息，在該訊息的訊息本體中包含該等已處理資料區塊，及每一個資料區塊包含一用以指定該已處理資料區塊之大小的訊息欄位；以及傳送該訊息。

Description

用於傳送及接收數位訊號之方法、傳送器、以及接收器
本發明的實施例大體上關於一種傳送數位訊號的方法、一種接收數位訊號的方法、一種傳送器、以及一種接收器。
利用「HTTP現場串流協定」和最近努力於標準化的「MPEG媒體之HTTP串流」以及HTML5在HTTP上串流多媒體預期會是未來的趨勢。在業界中越來越需要在HTTP上有效的傳遞串流多媒體。目前用於HTTP串流的「漸進式下載」技術可能需要更新以滿足新的需求，例如，依據網路條件和資源能力(也就是，適應串流)在傳遞期間在品質/保真域中對媒體內容進行動態適應調整。明確地說，由於無線網路的嚴苛資源限制和頻寬變動的關係，此種更新對串流至行動裝置來說可能非常重要。
適應串流的概念已存在於數種商用串流系統之中。於此等系統中，通常係將相同的媒體內容預編碼成具有不同串流品質的多個檔案來施行適應串流。在串流交談(streaming session)期間，最匹配目前網路條件的檔案會被選為串流檔案。當主控大量媒體內容時，此方式不僅耗費額外的儲存空間，還複雜化伺服器側的資料庫管理。除此之外，此種「多重來源(multiple sources)」 方法通常僅提供可被視為「粗粒度(coarse granularity)」的少量不同串流品質，例如，低、中、高，用以避免一則相同的媒體內容保有太多的來源檔。又，串流品質的選擇通常係在開始傳送串流時完成，因為在伺服器側通常沒有任何連續頻寬監視可採用。
於一實施例中，本發明提供一種傳送數位訊號的方法，其包含：將代表該數位訊號的資料分割成複數個資料區塊；根據資料區塊中包含的所需資料量來處理每一個資料區塊；針對每一個已處理資料區塊來決定該已處理資料區塊的大小；產生一訊息，在該訊息的訊息本體中包含該等已處理資料區塊，及每一個資料區塊包含一用以指定該已處理資料區塊之大小的訊息欄位；以及傳送該訊息。
根據各實施例，本發明提供一種對應於上述傳送方法的接收方法，一種對應的傳送器，以及一種對應的接收器。
根據各實施例，本發明提出一種系統，其針對可精緻伸縮(Fine Granular Scalable，FGS)音頻的HTTP適應串流(例如，IP網路上的MPEG-4 SLS)提供一種以「單一來源」為基礎的方法。「單一來源」可被理解成針對 一媒體(舉例來說，音頻)內容(舉例來說，一段音樂)並不需要用到被儲存在一伺服器上的多個檔案，而僅需要用到一已儲存的檔案。此外，根據一實施例，提供該媒體內容的伺服器可在行進中調整串流品質(舉例來說，音頻串流品質)，用以避免在串流應用(例如，線上無線電服務)中通常可能會遇到並且可能會困擾使用者的再緩衝(re-buffering)。
根據一實施例，本發明提供一種如圖1中所示之傳送資料的方法。
圖1為根據一實施例的流程圖100。
流程圖100圖解一種用於傳送數位訊號的方法。
在101中，代表該數位訊號的資料會分割成複數個資料區塊。
在102中，每一個資料區塊會根據資料區塊中包含的資料量被處理。
在103中會針對每一個已處理資料區塊來決定該已處理資料區塊的大小。
在104中會產生一訊息，在該訊息的訊息本體中包含該等已處理資料區塊，及每一個資料區塊包含一用以指定該已處理資料區塊之大小的訊息欄位。
在105中，該訊息會被傳送。
於一實施例中，換言之，代表一數位訊號的資料(舉例來說，該數位訊號的經編碼形式，例如，代表該數位訊號的經編碼位元串)會分離成複數個區塊(舉例來說， 對應於該數位訊號中多個連續部分(例如，連續的訊框)的一連串區塊)，若必要的話，每一個區塊的大小會根據資料區塊中包含的所需資料量(舉例來說，其對應於從該資料處進行重建時該數位訊號所需的品質水平)被調整，而且該等已處理資料區塊會被併入成為整個訊息本體中的多個部分，其中，每一個已處理資料區塊皆有自己的大小表示符。每一個資料區塊可能對應於該數位訊號的一特定時間週期，因此，每一個資料量皆對應於該已重建數位訊號的資料速率(data rate)。舉例來說，每一個資料區塊對應於一或多個訊框，因此，每一個資料量對應於每一個訊框的一特定資料料並且因而對應於從該已傳送資料處重建的數位訊號的一特定資料速率。
於一實施例中，每一個資料區塊的大小會根據代表該數位訊號的資料的資料速率調適進行調整(或設定)。根據一實施例，一資料區塊(舉例來說，亦稱為資料塊(chunk))的大小表示符僅在已於此資料塊裡面完成資料(舉例來說，FGS編碼的音頻資料)之速率調適之後才會被設定。根據一實施例，這會被用來達成經由HTTP資料塊編碼資料傳送來攜載FGS編碼音頻的目的。舉例來說，該數位訊號係一數位音頻訊號或數位視訊訊號。一般來說，該數位訊號可能係一要即時傳送的數位訊號，也就是，一具有相關聯重播速度並且希望被傳送俾便能夠在一接收器處以該相關聯重播速度來播放(舉例來說，沒有再緩衝)的數位訊號。
於一實施例中，針對每一個資料區塊，若該資料區塊中所包含的資料量高於該資料區塊中所包含的所需資料量，則資料區塊的處理包含減少該資料區塊中所包含的資料量，使得該資料區塊包含所需的資料量。
根據一實施例，該數位訊號會根據可調式編碼法(例如，MPEG-4 SLS)進行編碼，用以產生代表該數位訊號的資料。應該注意的係，要被傳送的(舉例來說，被串流)資料，也就是，代表該數位訊號的資料，可能係一已儲存的可調式編碼數位訊號，舉例來說，代表整首音樂或整個視訊片段(舉例來說，通常為整個媒體資料檔案)的預儲存可調式編碼數位訊號。換言之，舉例來說，代表該數位訊號的資料並非由以頻寬資訊為基礎在行進中進行編碼速率調適的即時編碼器產生的資料，而是代表該數位訊號的預產生資料，舉例來說，在接收該數位訊號之傳送之前預產生的資料(舉例來說，由一通訊終端提出之用以傳送該數位訊號的要求)，或是在傳送過程開始之前(舉例來說，在資料的第一部分被傳送之前)預產生的資料(舉例來說，針對整首音樂或是完整的媒體資料檔案)。
於一實施例中，針對每一個資料區塊，若該資料區塊包含的資料多過該資料區塊中所包含的所需資料量，則資料區塊的處理包含根據該可調式編碼法提供的可調性來減少該資料區塊中所包含的資料量，使得該資料區塊包含所需的資料量。
舉例來說，每一個資料區塊包含一根據該可調式編碼法的編碼位元串作為代表該數位訊號的資料，且其中，針對每一個資料區塊，若該資料區塊包含的資料量高於該資料區塊中所包含的所需資料量，則資料區塊的處理包含將該編碼位元串截短成該資料區塊中所包含的所需資料量。
舉例來說，該訊息係根據一應用層協定來產生。舉例來說，該訊息係根據HTTP(超文字傳輸協定)來產生。
根據一實施例，該訊息係根據分塊式傳輸編碼(chunked transfer encoding)來產生，其中，每一個已處理的資料區塊對應於一資料塊。
舉例來說，該訊息包含一訊息標頭。舉例來說，指定該等資料區塊之大小的訊息欄位並不包含在該訊息的(整個)訊息標頭之中，但是，針對每一個資料區塊，該等資料區塊之大小的詳細描述會包含在該訊息本體中和該資料區塊相關聯的一訊息欄位中，舉例來說，在該訊息本體中該資料區塊前面的一訊息欄位中。
舉例來說，每一個資料區塊包含代表該數位訊號中一或多個訊框的資料。
根據一實施例，將代表該數位訊號的資料分割成複數個資料區塊包括將代表該數位訊號的資料分割成一連串的資料區塊。
根據一實施例，將代表該數位訊號的資料分割成複數個資料區塊包括將代表該數位訊號的資料分割成代 表該數位訊號中多個連續部分的複數個資料區塊。
該方法可能進一步包括針對每一個資料區塊來決定用於傳送該資料區塊的可用資料傳送速率並且以該可用資料速率為基礎來決定該資料區塊中所包含的所需資料量。
舉例來說，該訊息係由一傳送器傳送，且舉例來說，決定該可用資料傳送速率包括決定介於該傳送器與該等資料區塊的一接收器之間的一通訊通道的傳送頻寬。
根據一實施例，每一個資料區塊中包含的資料皆代表該數位訊號中的一或多個訊框，該數位訊號具有一相關聯的訊框速率，且針對每一個資料區塊，該資料區塊中所包含的所需資料量會經過決定俾使得該已處理的資料區塊可以利用該經決定的可用資料傳送速率來傳送，俾便該等訊框會以該相關聯的訊框速率被傳送。
舉例來說，流程圖100中所示的流程係由一如圖2中所示的傳送器(舉例來說，一伺服器電腦)來實行。
圖2為根據一實施例用以傳送一數位訊號的傳送器200。
該傳送器包含：一分割器201，其被配置成用以將代表該數位訊號的資料分割成複數個資料區塊；以及一處理器202，其被配置成用以根據資料區塊中包含的所需資料量來處理每一個資料區塊。
該傳送器進一步包括：一決定器203，其被配置成 用以針對每一個已處理資料區塊來決定該已處理資料區塊的大小；以及一產生器204，其被配置成用以產生一訊息，在該訊息的訊息本體中包含該等已處理資料區塊，及每一個資料區塊包含一用以指定該已處理資料區塊之大小的訊息欄位。
另外，該傳送器包括一發送器205，其被配置成用以傳送該訊息。
舉例來說，該訊息會根如圖3中所示的接收方法被接收。
圖3為根據一實施例的流程圖300。
流程圖300圖解一種接收數位訊號的方法。
在301中，一訊息會被接收，在該訊息的訊息本體中包含複數個資料區塊，該等資料區塊包含代表該數位訊號的資料及每一個資料區塊包含一用以指定該資料區塊之大小的訊息欄位，其係用以考慮該等資料區塊的大小。
在302中，該數位訊號會從該等複數個資料區塊中包含的資料中被重建。
舉例來說，圖3中所示的流程係由圖4中所示的接收器(舉例來說，一用戶站(client station))來實行。
圖4為根據一實施例用以接收一數位訊號的接收器400。
接收器400包含一接收模組401，其被配置成用以接收一訊息，在該訊息的訊息本體中包含複數個資料區 塊，該等資料區塊包含代表該數位訊號的資料及每一個資料區塊包含一用以指定該資料區塊之大小的訊息欄位，其係用以考慮該等資料區塊的大小。
接收器400進一步包含一處理器402，其被配置成用以從該等複數個資料區塊中包含的資料處來重建該數位訊號。
應該注意的係，根據各實施例，本發明提供多個電腦程式元件，當被電腦(舉例來說，其包含智慧型電話)執行時，它們會讓電腦實施上面參考圖1與3所述之傳送數位訊號的方法以及接收數位訊號的方法。
下文中會更詳細說明多個實施例。
本發明的各實施例網路適應音頻串流(Network Adaptive Audio Streaming，NAAS)提供一種實用的系統解決方案。其可能包含：一以TCP為基礎的頻寬預估器；一連接至一HTTP網路伺服器(其可被視為一標準的HTTP伺服器)的動態NAAS連結常式；一FGS音頻資料區塊處理器；以及一客製串流用戶。此架構圖解在圖5中。
圖5為根據一實施例的通訊配置500。
通訊配置500包括一伺服器站501(舉例來說，一伺服器電腦)以及一用戶站502(舉例來說，一行動電話，例如，智慧型電話)。
伺服器站501及用戶站502會藉由一通訊網路503(舉例來說，有線或無線IP(Internet Protocol)網路) 相連。
伺服器站501包括一頻寬預估器504、一媒體源505(於本範例中，其係一FGS(可精緻伸縮)音頻資料源，也就是，一可調式編碼音頻資料)、一連結器件506(於本範例中，其係一動態NAAS連結常式)、一媒體資料處理器507(於本範例中，其係一FGS音頻資料區塊處理器)、以及一HTTP網路伺服器508。
伺服器站501可被視為用以施行一種適應串流系統。
根據一實施例，該適應串流系統會配合一標準的HTTP網路伺服器508來運作，而不會影響該HTTP網路伺服器508的任何其它功能。於一實施例中，藉由提供頻寬預估器504與FGS音頻資料區塊處理器507(舉例來說，藉由附加至HTTP網路伺服器軟體的兩個軟體模組來施行)可達成此目的。
頻寬預估器504會即時預估伺服器站501及用戶站502之間的可用串流頻寬，而FGS音頻資料區塊處理器507會根據該經預估的可用串流頻寬來截短媒體源505所提供的FGS音頻資料，用以確保從伺服器站501被串流至用戶站502的音頻資料的資料速率會接近(舉例來說，盡可能接近，也就是，理想上接近)該可用串流頻寬。舉例來說，施行頻寬預估器504與FGS音頻資料區塊處理器507的軟體模組會透過軟體外掛(也就是，特定的軟體介面連接技術)被動態連結至HTTP網 路伺服器508。
應該注意的係，在習知以HTTP為基礎的串流系統中，被串流的媒體資料通常可能係以HTTP訊息的形式被傳送，其中，訊息本體的長度會藉由該訊息本體前面的一固定、預設的資料元件來發信通知。根據一實施例，因為FGS音頻資料的長度會因為截短運算的關係而動態改變，所以，本發明提供一種解決方式，允許藉由HTTP訊息來有效傳送具有變動長度資訊的FGS音頻資料。明確地說，根據一實施例，FGS音頻資料(舉例來說，對應於一首音樂的音頻訊號)會被切成一系列(或一連串)的資料區塊，而且每一個資料區塊會根據HTTP分塊式傳輸編碼在一HTTP訊息的一不同的資料塊中被傳送。
根據一實施例，一資料塊的長度資訊僅在已於此資料塊訊息裡面完成FGS音頻資料之速率調適之後才會被設定，使得該資料塊含有正確的長度資訊。
HTTP網路伺服器508可能係一(本身)不提供適應串流特徵的標準HTTP網路伺服器(舉例來說，設計成一Apache伺服器)。根據一實施例，適應串流的功能會藉由修正HTTP伺服器508的程式碼並且直接併入新功能於HTTP伺服器508的程式碼(若可行的話)以及重建伺服器軟體而被附加至該HTTP網路伺服器508。根據另一實施例，可能使用一更實用的方式：舉例來說，於一Apache伺服器中，在特定階段的處理中，客製的軟 體模組會運轉時間中「被外掛至」該伺服器，用以實施特定的客製功能。此等客製模組會獨立開發並且內建在一類DLL(動態連結程式庫)二元檔案中並且會在運轉時間中由伺服器軟體載入。依此方式，伺服器能力會因適應串流的功能而擴展，但卻不會觸及HTTP伺服器508的任何部分，並且因而大幅簡化系統佈署。
圖6中所示的係用以提供適應串流的一客製模組(下文中亦稱為客製NAAS模組)的動態連結。
圖6為根據一實施例的處理流程600。
處理流程600係由一伺服器601(舉例來說，對應於HTTP網路伺服器508)、一客製NAAS模組603、以及介於該伺服器601與該(客製)NAAS模組603之間的多個連結點602來實行。
在604中會開始一工作執行緒。
在605中會實行一處理連接，舉例來說，伺服器601會連接至通訊網路503，以便能夠接收媒體資料(舉例來說，音頻檔案)的要求。
在606中會收到一讀取要求，舉例來說，來自用戶站502針對媒體資料的要求。
在607中會處理該要求。這可能涉及在608中處理該要求中指定的URL(全球資源定位器)以及在609中處理該要求中的一或多個標頭。又，在610中會檢查被要求資料的類型。為達此目的，可能會在連結點602處檢查一被登錄為類型檢查常式611的連結常式函數清 單。對一被支援的(也就是，其連結常式函數被登錄為處理常式(handler))特定資料類型(舉例來說，MIME(多用途網際網路延伸)類型)來說，用以處理該特定資料類型的連結常式函數612係由該客製NAAS模組603來提供。
在613中，在類型檢查之後會召喚該被要求資料的處理常式。為達此目的，該等連結點602會提供一被登錄為處理常式614的連結常式函數清單。該客製NAAS模組603會提供被登錄為該資料之處理常式的連結常式函數615。
在616中，伺服器601會與通訊網路503中斷連接，並且在617中停止該工作緒。
為在處理FGS音頻資料的一(HTTP)要求的過程中的不同階段處動態連結至該伺服器，首先，一連結常式函數會被登錄為類型檢查常式，用以將MPEG-4 SLS位元串的一特定MIME類型「application/x-sls-audio」加至該要求記錄結構，也就是，加至被登錄為類型檢查常式611的連結常式函數清單。其次，另一連結常式函數會被登錄為處理常式，用以處理具有MIME類型「application/x-sls-audio」的資料的用戶要求，也就是，加至被登錄為處理常式614的連結常式函數清單。
當伺服器在606中接收FGS音頻的一用戶要求時，其會經過上面所述的已圖解方法步驟，其中，當伺服器運行至610中檢視被登錄為類型檢查常式的所有 連結常式函數的連結點時，被登錄為用以加入一特定MIME類型「application/x-sls-audio」之類型檢查常式的連結常式函數便會被呼叫。最後，當伺服器運行至613中的處理常式連接點時，被登錄為用以處理具有MIME類型「application/x-sls-audio」之資料的用戶要求的處理常式的連結常式函數便會領先其它已登錄處理常式來接管處理該FGS音頻要求的工作。
在客製NAAS模組603動態連結至HTTP伺服器601之後，其便延伸該伺服器601的能力，使其成為依用於FGS音頻的適應串流伺服器，並且該伺服器中的所有其它標準功能都完整保留。舉例來說，伺服器601仍能利用網路瀏覽器提供網頁給用戶站502。
根據一實施例，頻寬預估器504會提供一以TCP為基礎的網路頻寬預估給媒體資料處理器。舉例來說，網路頻寬預估可以用於流量規劃中的路由演算法以及壅塞控制機制。用於的網路頻寬預估的技術與工具通常會使用主動式探測來測量和頻寬有關的度量值。另外，舉例來說，無線鏈路的閒置率(idle rate)亦可能會被計算以預估可用的頻寬。然而，這需要加入一模組至該網路中每一個節點的MAC(媒體存取控制)層，以便取得該閒置率。
根據一實施例，不必存取MAC層，更實用的方式係預估傳輸層的可用頻寬。一以UDP(使用者數據協定)為基礎的視訊傳輸協定(Video Transport Protocol，VTP) 會使用經特殊設計之控制封包中所含的時間戳記資訊來計算可用頻寬。於各實施例中，會使用TCP中的確認機制來取得用以預估該可用頻寬的必要資訊，而非提出新的傳輸協定，這對系統施行與佈署來說更為實用。
TCP回應中的序號係接收器所確認的已接收位元組的數量。假設si為在時間ti處所確認的序號，si-1為在時間ti-1處所確認的序號，那麼，在時間ti處可用的頻寬bi便可預估如下：
根據一實施例，為減少預估頻寬中的雜訊並且防止串流品質快速變動，其會藉由對平滑化該預估頻寬而套用一低通濾波器： 其中，αi為介於0與1之間加權係數，其相依於△i=ti-ti-1。
根據一實施例，NAAS的頻寬預估演算法會根據公式(1)與(2)來實行。該頻寬預估演算法的表現如圖7中所示。
圖7為一頻寬-時間圖700。
時間(以秒為單位)係在時間軸701中，而頻寬(以kbps為單位)係在頻寬軸702中。
本範例中的實際頻寬為虛線704，而頻寬預估演算法所預估的頻寬為實線703。
如圖中所見，圖7於24秒處從64kbps至256kbps以及於64秒處從256kbps回到64kbps中圖解出在一串流過程期間該頻寬預估演算法對實際頻寬變化的步階響應。
應該注意的係，此處所述之上面的頻寬預估演算法僅係為達解釋的目的，根據各實施例，亦可以使用其它頻寬預估演算法。
根據一實施例，FGS音頻係根據MPEG-4可伸縮無損(SLS)編碼法來編碼。MPEG-4可伸縮無損(SLS)編碼法係ISO/IEC的MPEG-4音頻編碼工具家族中其中一種最新的新增方法。其允許將感知編碼代表符(MPEG-4 AAC)擴增為具有廣範圍中等位元速率(bit rate)代表符的無損代表符。其還有一種無核心模式，在該模式中並沒有MPEG-4 AAC核心，而且品質實際上係從0kbps處擴增。
MPEG-4 SLS的其中一項主要優點係，從編碼器處所產生的位元串藉由略去每一個訊框末端的位元便能夠輕易地進一步截短成更低的資料速率。此情形圖解在圖8中。
圖8為根據一實施例的音頻資料。
在第一格式801中，音頻資料包含一無損編碼音頻訊號(或者，更一般的說法係，最高品質的音頻訊號)， 並且舉例來說，會被音源505儲存。根據第一格式801，該音頻資料包含複數個訊框(本範例中為N個訊框)中每一個訊框802的音頻資料。該音頻資料的形式為MPEG-4 SLS音頻串，因此，每一個訊框802的音頻資料會被連續排列在該音頻串之中。
每一個訊框802的音頻資料皆包含第一通道的第一標頭803、第一通道的第一資料804、第二通道的第二標頭805、以及第二通道的第二資料806。
每一個訊框802的音頻資料還構成一序列，舉例來說，一位元串，因此，全部音頻資料便構成完整的位元串。
在每一個訊框802的音頻資料中，第一資料804與第二資料806還構成一位元串並且可能在末端被截短，俾使得訊框802的資料可能減少。此截短如箭頭807所示，並且舉例來說，係由資料處理器507來實行。
截短的結果會變成第二格式808，其中，如圖所示，每一個訊框802的兩條通道的第一資料804與第二資料806會縮減，其會導致編碼音頻訊號的品質低於原始品質。
換言之，具有較低資料速率的編碼音頻訊號可藉由略去每一個通道資料位元串末端的位元而從(具有最高品質)原始編碼音頻訊號處產生。
此處，資料速率和媒體速率都係用來表示由伺服器站501所提供之要被傳送並且最後要由用戶站502之解 碼器來處理的每一個音頻訊框持續長度中的位元或位元組數量。音頻串品質越高，媒體速率(資料速率)便越高。根據一實施例，HTTP適應串流包含根據經預估的可用網路頻寬來決定媒體速率，因此，媒體速率必定等於或小於(可用於傳送編碼音頻訊號的)網路頻寬，以確保在用戶側平順的重播該音頻串。
舉例來說，根據一實施例，被登錄為用以處理具有MIME類型「application/x-sls-audio」之資料的用戶要求的處理常式(亦稱為NAAS處理常式)的連結常式函數捕捉到FGS音頻的用戶要求，其便會開始一不同的執行緒，用以利用如上面參考公式(1)與(2)所述之頻寬預估方法來預估該鏈路的可用頻寬。同時，其會構成回應訊息標頭和回應訊息本體。回應訊息本體含有讀取自由媒體(本範例中為音頻)源505所提供之來源音頻資料檔案的被要求的FGS音頻資料。
於非適應(固定位元速率)的情況中，例如，於非適應串流應用中，訊息本體的長度會事先被算出並且併入「Content-Length」回應訊息標頭中。一般來說，用戶站必須在開始接收後續的訊息本體之前先被發信告知此數值。否則，便可能會發生HTTP連接提早結束或是逾時，於兩種情況中，用戶站都無法正確取得回應訊息本體。
然而，因為NAAS處理常式可能會由於可用的網路頻寬不夠具有最高編碼品質的音頻資料使用的關係而 截短音頻資料串中要被併入該回應訊息之中的至少某些訊框的FGS音頻資料，所以，其可能無法事先決定該回應訊息中的資料料。
據此，於一實施例中，為克服根據HTTP協定發信通知一固定且事先決定之Content-Length訊息標頭的需求，NAAS模組603會使用根據HTTP/1.1的分塊式傳輸編碼機制來支援NAAS的適應串流功能。
為達此目的，根據一實施例，整個訊息本體(其含有最高品質(也就是，未被截短)之經壓縮的可調式編碼音頻資料)會被切成數個較小的資料區塊(資料塊)，每一個區塊皆含有由整數個FGS音頻訊框所組成的資料。在每一個資料區塊被傳送之前會先對音頻串的媒體速率實施調整(也就是，截短)。之後，該資料區塊的大小會被重新計算並且插入該資料區塊的開頭部分中。此經插入的資料區塊大小會利用HTTP/1.1傳輸編碼：分塊式訊息標頭來發信通知，因此，不會干擾和HTTP/1.1相容的用戶之正常的漸進式下載功能。
依此方式，根據一實施例，所有資料區塊會以獨立且漸進的方式逐一被發送至用戶站502，而不必事先告知用戶整個訊息的大小。此情形圖解在圖9中。
圖9為一第一回應訊息901與一第二回應訊息902。
第一回應訊息901可被視為對應於開始傳送之前已知到整個訊息的大小的情況，或者，換言之，對應於固定長度音頻串。據此，該訊息的大小(本範例中為 65536個位元組)會被插入該第一回應訊息901的標頭之中。第一回應訊息的訊息本體904包含該音頻資料。
第二回應訊息902可被視為對應於適應串流。原始音頻串(也就是，對應於最高品質的音頻串)會被切成多個資料區塊，每一個資料區塊會先經過處理，相依於目前可用於傳送該資料區塊的網路頻寬來截短該資料區塊中所包含的音頻資料；而且，該經過處理之資料區塊的資料908的數量指示符會被併入該資料區塊的資料區塊標頭907之中。
第二訊息902的標頭905包含表示該訊息已經根據HTTP分塊式傳輸編碼被產生的表示符；而該第二訊息的本體906則包含該等資料區塊。
該等經過處理的區塊會藉由多個TCP(傳輸控制協定)PDU(封包資料單元)以漸進的方式，也就是，依序被傳送至用戶站502。根據一實施例，媒體速率會由FGS音頻資料區塊處理器507根據時間ti處的預估可用網路頻寬bi來調整，以便在用戶側保持該音頻串的平順播放。
舉例來說，媒體速率可以下面的計算為基礎進行調整：
1)決定要從ti至ti+1被送出的平均訊框大小。
其中，f0為取樣頻率(也就是，編碼音頻訊號每秒的訊框數)，而為經平滑的可用網路頻寬。
2)決定ti與ti+1之間每一個訊框的截短率λij。
假設在ti與ti+1之間有J個訊框，而dij為第j個訊框(jJ)的訊框大小，那麼，設定
其中，η係一介於0.9與1之間的恆定係數，用以確保被送出的媒體速率不會超過可用頻寬，以便保持用戶側的重播非常平順。可對λij套用一上限與一下限，俾便確保：
3)調整媒體速率
針對ti與ti+1之間的第j個訊框(jJ)，d ij =h+d ij0+d ij1
其中，h為一代表標頭大小的常數，dij0為通道0的資料大小，而dij1為通道1的資料大小。該訊框的新通道0資料大小和新通道1資料大小(截短之後)可計算如下：
最後，以可用頻寬bi為基礎的經調整訊框大小可以計算如下
應該注意的係，本文中包含的上面媒體速率調整方法僅為達解釋之目的，在根據各種實施例的適應串流系統中亦可以使用其它媒體速率調整演算法。
舉例來說，用戶站502的結構可能如圖10中所示。
圖10為根據一實施例的用戶站1000。
根據一實施例，用戶站1000的作用如同上面參考圖5所述之適應串流系統的媒體播放器，並且對應於用戶站502。根據一實施例，用戶站1000可被視為一典型以HTTP為基礎的串流用戶。
根據一實施例，為當作適應串流系統的用戶，用戶站1000會實行三項處理：接收處理、解碼處理、以及音頻輸出處理(參考圖10中的執行緒1至3)。
為達此目的，用戶站1000包含一HTTP用戶1001，舉例來說，其可能會藉由發送一針對FGS音頻資料的HTTP要求而開使該串流處理。
圖中分派兩個FIFO(先入先出)記憶體，分別當作串 流緩衝器與音頻緩衝器。
如圖9中所示，在回應訊息902的標頭905中，NAAS HTTP串流伺服器901會發信通知該外來訊息主體被分塊式傳輸編碼。
該HTTP用戶1001會接收已被插入資料區塊標頭907之中的資料區塊大小(在每一個資料區塊的開頭部分)，並且使用它以逐個區塊的方式從該等資料區塊處正確讀取該資料，直到收到EOF(檔案結束)語法為止。
一串流接收器1002會擷取該等資料區塊中所含的FGS音頻訊框，並且將它們逐個推入一串流緩衝器1003之中。一FGS音頻解碼器1004處理會從該串流緩衝器1003處取回該等FGS音頻訊框，解碼每一個訊框的音頻資料，並且將已解碼的音頻資料(此情況中為PCM(脈衝碼調變)音頻取樣)推入一音頻緩衝器1005之中。一音頻輸出1006會藉由從該音頻緩衝器1005處讀取該等PCM音頻取樣並且將它們送往一聲音輸出裝置來播放該經解碼的FGS音頻。
如上面所述之根據各實施例的適應音頻(或是一般所謂的媒體，例如，視訊)串流系統可以利用不同的通訊網路環境來施行，例如，有專屬無線路由器的區域WiFi網路、共用的辦公室或建物WiFi網路、或是由區域服務供應商所操作的3G無線網路。在辦公室WiFi網路中，舉例來說，當頻寬很高時，伺服器站501會藉由將位元串調整至最高品質(λ=1)來回應該可用的高 TCP總流量。舉例來說，當頻寬降為64kbps時(如圖7中所示)，伺服器站501則可能會藉由降低串流品質而降低發送位元速率。在頻寬回復之後，伺服器站501會將位元串再次調整至最高品質。於另一範例中，在3G無線網路的情況中，舉例來說，頻寬可能會保持在160kbps附近變動，而伺服器站501則會保持調整該被串流MPEG-4 SLS位元串的位元速率，以便和該可用頻寬一致。於兩種情況中，在用戶站502上的重播都很平順，而且使用者不會碰到再緩衝。
101-105‧‧‧步驟
200‧‧‧傳送器
201‧‧‧分割器
202‧‧‧處理器
203‧‧‧決定器
204‧‧‧產生器
205‧‧‧發送器
400‧‧‧接收器
401‧‧‧接收模組
402‧‧‧處理器
500‧‧‧通訊配置
501‧‧‧伺服器站
502‧‧‧用戶站
503‧‧‧通訊網路
504‧‧‧頻寬預估器
505‧‧‧媒體源
506‧‧‧連結器件
507‧‧‧媒體資料處理器
508‧‧‧HTTP網路伺服器
1000‧‧‧用戶站
1001‧‧‧HTTP用戶
1002‧‧‧串流接收器
1003‧‧‧串流緩衝器
1004‧‧‧FGS音頻解碼器
1005‧‧‧音頻緩衝器
1006‧‧‧音頻輸出
前面已參考圖式解釋過本發明的圖解實施例。
圖1為根據一實施例的流程圖。
圖2為根據一實施例用以傳送一數位訊號的傳送器。
圖3為根據一實施例的流程圖。
圖4為根據一實施例用以接收一數位訊號的接收器。
圖5為根據一實施例的通訊排列。
圖6為根據一實施例的處理流程。
圖7為一頻寬-時間圖。
圖8為根據一實施例的音頻資料。
圖9為一第一回應訊息與一第二回應訊息。
圖10為根據一實施例的用戶站。
101-105‧‧‧步驟

Claims (19)

  1. 一種用以傳送一數位訊號的方法，其包括：將代表該數位訊號的資料分割成複數個資料區塊；根據資料區塊中包含的所需資料量來處理每一個資料區塊；針對每一個已處理資料區塊來決定該已處理資料區塊的大小；產生一訊息，在該訊息的訊息本體中包含該等已處理資料區塊，及每一個資料區塊包含一用以指定該已處理資料區塊之大小的訊息欄位；以及傳送該訊息。
  2. 如申請專利範圍第1項的方法，其中，該數位訊號係一數位音頻訊號或是一數位視訊訊號。
  3. 如申請專利範圍第1或2項的方法，其中，針對每一個資料區塊，若該資料區塊中所包含的資料量高於該資料區塊中所包含的所需資料量，則資料區塊的處理包含減少該資料區塊中所包含的資料量，使得該資料區塊包含所需的資料量。
  4. 如申請專利範圍第1至3項中任一項的方法，其中，該數位訊號會根據可調式編碼法進行編碼，用以產生代表該數位訊號的資料。
  5. 如申請專利範圍第4項的方法，其中，針對每一個資料區塊，若該資料區塊包含的資料高於該資料區塊中 所包含的所需資料量，則資料區塊的處理包含根據該可調式編碼法提供的可調性來減少該資料區塊中所包含的資料量，使得該資料區塊包含所需的資料量。
  6. 如申請專利範圍第4項的方法，其中，每一個資料區塊包含一根據該可調式編碼法的編碼位元串作為代表該數位訊號的資料，且其中，針對每一個資料區塊，若該資料區塊包含的資料量高於該資料區塊中所包含的所需資料量，則資料區塊的處理包含將該編碼位元串截短成該資料區塊中所包含的所需資料量。
  7. 如申請專利範圍第1至6項中任一項的方法，其中，該訊息係根據一應用層協定來產生。
  8. 如申請專利範圍第1至7項中任一項的方法，其中，該訊息係根據HTTP來產生。
  9. 如申請專利範圍第1至8項中任一項的方法，其中，該訊息係根據分塊式傳輸編碼來產生，其中，每一個已處理的資料區塊對應於一資料塊。
  10. 如申請專利範圍第1至9項中任一項的方法，其中，該訊息包含一訊息標頭。
  11. 如申請專利範圍第1至10項中任一項的方法，其中，每一個資料區塊包含代表該數位訊號中一或多個訊框的資料。
  12. 如申請專利範圍第1至11項中任一項的方法，其中，將代表該數位訊號的資料分割成複數個資料區塊包括將代表該數位訊號的資料分割成一連串的資料區 塊。
  13. 如申請專利範圍第1至12項中任一項的方法，其中，將代表該數位訊號的資料分割成複數個資料區塊包括將代表該數位訊號的資料分割成代表該數位訊號中多個連續部分的複數個資料區塊。
  14. 如申請專利範圍第1至13項中任一項的方法，其進一步包括針對每一個資料區塊來決定用於傳送該資料區塊的可用資料傳送速率並且以該可用資料速率為基礎來決定該資料區塊中所包含的所需資料量。
  15. 如申請專利範圍第14項的方法，其中，該訊息係由一傳送器傳送，且其中，決定該可用資料傳送速率包括決定介於該傳送器與該等資料區塊的一接收器之間的一通訊通道的傳送頻寬。
  16. 如申請專利範圍第14或15項的方法，其中，每一個資料區塊中包含的資料皆代表該數位訊號中的一或多個訊框，該數位訊號具有一相關聯的訊框速率，且針對每一個資料區塊，該資料區塊中所包含的所需資料量會經過決定使得該已處理的資料區塊可以利用該經決定的可用資料傳送速率來傳送，使得該等訊框會以該相關聯的訊框速率被傳送。
  17. 一種傳送一數位訊號的傳送器，其包括：一分割器，其被配置成用以將代表該數位訊號的資料分割成複數個資料區塊；一處理器，其被配置成用以根據資料區塊中包含的 所需資料量來處理每一個資料區塊；一決定器，其被配置成用以針對每一個已處理資料區塊來決定該已處理資料區塊的大小；一產生器，其被配置成用以產生一訊息，在該訊息的訊息本體中包含該等已處理資料區塊，及每一個資料區塊包含一用以指定該已處理資料區塊之大小的訊息欄位；以及一發送器，其被配置成用以傳送該訊息。
  18. 一種接收一數位訊號的方法，其包括：接收一訊息，在該訊息的訊息本體中包含複數個資料區塊，該等資料區塊包含代表該數位訊號的資料及每一個資料區塊包含一用以指定該資料區塊之大小的訊息欄位，其係用以考慮該等資料區塊的大小；以及從該等複數個資料區塊中包含的資料中重建該數位訊號。
  19. 一種接收一數位訊號的接收器，其包括：一接收模組，其被配置成用以接收一訊息，在該訊息的訊息本體中包含複數個資料區塊，該等資料區塊包含代表該數位訊號的資料及每一個資料區塊包含一用以指定該資料區塊之大小的訊息欄位，其係用以考慮該等資料區塊的大小；以及一處理器，其被配置成用以從該等複數個資料區塊中包含的資料處來重建該數位訊號。
TW101118714A 2011-05-26 2012-05-25 用於傳送及接收數位訊號之方法、傳送器、以及接收器 TW201316814A (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US201161490125P 2011-05-26 2011-05-26

Publications (1)

Publication Number Publication Date
TW201316814A true TW201316814A (zh) 2013-04-16

Family

ID=45768276

Family Applications (1)

Application Number Title Priority Date Filing Date
TW101118714A TW201316814A (zh) 2011-05-26 2012-05-25 用於傳送及接收數位訊號之方法、傳送器、以及接收器

Country Status (3)

Country Link
US (1) US20120303833A1 (zh)
TW (1) TW201316814A (zh)
WO (1) WO2012161652A1 (zh)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8924581B1 (en) * 2012-03-14 2014-12-30 Amazon Technologies, Inc. Managing data transfer using streaming protocols
US9402114B2 (en) 2012-07-18 2016-07-26 Cisco Technology, Inc. System and method for providing randomization in adaptive bitrate streaming environments
US9516078B2 (en) 2012-10-26 2016-12-06 Cisco Technology, Inc. System and method for providing intelligent chunk duration
US20140215085A1 (en) * 2013-01-25 2014-07-31 Cisco Technology, Inc. System and method for robust adaptation in adaptive streaming
GB2513344B (en) * 2013-04-23 2017-03-15 Gurulogic Microsystems Oy Communication system utilizing HTTP
US20140347376A1 (en) * 2013-05-24 2014-11-27 Nvidia Corporation Graphics server and method for managing streaming parameters
CN107579920B (zh) * 2017-09-25 2021-06-01 盛科网络（苏州）有限公司 数据流的传输方法、装置、存储介质及处理器
CN109787856B (zh) * 2018-12-19 2021-03-02 西安交通大学 一种基于lte网络链路状态的has带宽预测方法
US12407651B2 (en) * 2023-02-16 2025-09-02 Palo Alto Networks, Inc. Inline inspection cybersecurity enforcement of multipart file transmissions

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6633609B1 (en) * 1996-12-24 2003-10-14 Intel Corporation Method and apparatus for bit rate control in a digital video environment for arbitrary bandwidth
US6996173B2 (en) * 2002-01-25 2006-02-07 Microsoft Corporation Seamless switching of scalable video bitstreams
US8219711B2 (en) * 2008-11-24 2012-07-10 Juniper Networks, Inc. Dynamic variable rate media delivery system
WO2010111261A1 (en) * 2009-03-23 2010-09-30 Azuki Systems, Inc. Method and system for efficient streaming video dynamic rate adaptation

Also Published As

Publication number Publication date
US20120303833A1 (en) 2012-11-29
WO2012161652A1 (en) 2012-11-29

Similar Documents

Publication Publication Date Title
US12170712B2 (en) Method and system for providing media content to a client
TW201316814A (zh) 用於傳送及接收數位訊號之方法、傳送器、以及接收器
CN106537855B (zh) 减少视频电话中的延迟
US10034048B2 (en) Multipath delivery for adaptive streaming
US10911506B2 (en) Methods for quality-aware adaptive streaming over hypertext transfer protocol and reporting quality of experience
US8489758B2 (en) Method of transmitting data in a communication system
KR100971715B1 (ko) 다이내믹한 네트워크 손실 조건에 대해 간단하게 적응하는 멀티미디어 서버
CN101951331B (zh) 数字家庭网络多媒体共享系统及其共享方法
RU2598805C2 (ru) Способ для динамической адаптации частоты следования битов при приеме и соответствующий приемник
CN103828324A (zh) 用于分组网络上的流媒体的按需自适应比特率管理
EP3033887A1 (en) Apparatus and method for constant quality optimization for adaptive streaming
CN102550038A (zh) 播放媒体文件的方法、终端、服务器和系统
AU2017207978A1 (en) Real-time transport protocol congestion control techniques in video telephony
JP2009296164A (ja) データ送信装置、その制御方法及びプログラム
CN110881018B (zh) 媒体流的实时接收方法及客户端
CN116866676A (zh) 一种跨网投屏方法及系统
WO2018021950A1 (en) Device and method for controlling media streaming from a server to a client
US20150063103A1 (en) Bandwidth-dependent compressor for robust header compression and method of use thereof
CN118044208A (zh) 用于多源传递的数据速率和缓冲区估计的方法
TW202123720A (zh) 伺服器端自適性媒體串流