TW201427452A - 組合使用流媒體裁剪技術和顯性擁塞通知技術的方法 - Google Patents

組合使用流媒體裁剪技術和顯性擁塞通知技術的方法 Download PDF

Info

Publication number
TW201427452A
TW201427452A TW102135678A TW102135678A TW201427452A TW 201427452 A TW201427452 A TW 201427452A TW 102135678 A TW102135678 A TW 102135678A TW 102135678 A TW102135678 A TW 102135678A TW 201427452 A TW201427452 A TW 201427452A
Authority
TW
Taiwan
Prior art keywords
data packet
rtp
video service
congestion notification
explicit congestion
Prior art date
Application number
TW102135678A
Other languages
English (en)
Inventor
Hua Zhao
Original Assignee
Alcatel Lucent
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 Alcatel Lucent filed Critical Alcatel Lucent
Publication of TW201427452A publication Critical patent/TW201427452A/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/32—Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames

Landscapes

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

Abstract

本發明提供了一種用於為基於可分級的視頻業務實現組合使用流媒體裁剪技術和顯性擁塞通知技術的方法。藉由本發明提供的較佳的技術方案，能夠將ECN(顯性擁塞通知)技術和流裁剪技術結合地應用至基於可分級的視頻業務，並能夠產生可靠的顯性擁塞通知和/或周期性顯性擁塞通知總結報告。由此在收到顯性擁塞通知和/或周期性顯性擁塞通知總結報告之後，RTP(即時傳輸協定)接收端能夠實現良好的碼率適配或擁塞控制效果。並且依據本發明的ECN技術還考慮了無線網路中的時變性問題。此外，在本發明中，網路設備能夠根據需要為同一個基於可分級的視頻業務設置不同的擁塞事件，這對於RTP發送端實施準確的擁塞控制也是非常有利的。

Description

組合使用流媒體裁剪技術和顯性擁塞通知技術的方法
本發明涉及行動通信技術，尤其涉及一種用於為基於可分級的視頻業務實現組合使用流媒體裁剪技術和顯性擁塞通知技術的方法。
在文獻IETF RFC 3168(09/2001)“將顯性擁塞通知添加入IP網路(The Addition of Explicit Congestion Notification(ECN)to IP)”中提出了一種顯性擁塞通知(Explicit Congestion Notification，ECN)技術，即在發現即將發生擁塞時，將在IP資料封包中作出指示，而不是直接丟弃。具體地，在IP資料封包的包標頭中設置ECN域。如圖1所示，該ECN域包括兩位元，即顯性擁塞指示傳輸位元(ECN-Capable Transport，ECT)和擁塞預警位元(Congestion Experienced，CE)。當發送端將這兩個位元設置為00時，將指示各個路由器不使用ECN技術。當發送端將這兩個位元設置為01或10時，指示各個路由器使用ECN技術，當然在這之前，發送端與接收端之間還存在一個初始化過程，以確定兩者之間的傳輸路 徑是否支持ECN技術。而當兩者之間傳輸路徑中的路由器將01或10更改成11時，則表示網路存在擁塞，從而接收端在接收到帶有11的IP資料封包標頭的IP資料封包時，將產生顯性擁塞通知反饋報告，並向發送端發送該顯性擁塞通知反饋報告。
另一方面，應用可分級視頻編碼的視頻業務或應用多視角視頻編碼的視頻業務一般是基於由用戶數據報協定(User Datagram Protocol，UDP)承載的即時傳輸協定(real-time transport protocol，RTP)流進行傳輸的。
現今，傳輸控制協定(Transmission Control Protocol，TCP)、流控制傳輸協定(Stream Control Transmission Protocol，SCTP)和數據報擁塞控制協定(Datagram Congestion Control Protocol，DCCP)已經能夠支持ECN技術。然而，由於用戶數據報協定(User Datagram Protocol，UDP)缺少反饋機制，因此在如何將ECN技術應用至由UDP承載的RTP流方面存在問題。
針對上述問題，在文獻IETF RFC 6679(08/2012)“用於由UDP承載的RTP流的ECN技術(Explicit Congestion Notification(ECN)for RTP over UDP)中提出了一種新的由RTP控制協定(RTP Control Protocol，RTCP)承載的反饋消息，該消息的資料封包藉由特定域的取值，指示其包含顯性擁塞通知反饋報告，其用於當所接收的IP資料封包中的顯性擁塞通知欄位為11時，即時地產生並向RTP發送端發送RTCP承載的顯性擁塞通知反 饋報告。此外，還提出一種使用RTCP來傳輸的新的擴展報告塊(Extended Report Block)，其用於周期性地傳輸顯性擁塞通知總結報告。並且在上述文獻中提出了在這些報告中包括下述參數：擴展最高序列號(Extended Highest Sequence Number)，用於計數與該報告相關的最高的RTP序列號、ECT(0)計數(ECT(0)Counter)，用於計數帶有ECT(0)的RTP資料封包的數量、ECT(1)計數(ECT(1)Counter)，用於計數帶有ECT(1)的RTP資料封包的數量、ECN-CE計數(ECN-CE Counter)，用於計數帶有CE的RTP資料封包的數量、非ECT計數(not-ECT Counter)，用於計數帶有非ECT的RTP資料封包的數量、丟失封包計數(Lost Packets Counter)，用於計數丟失的RTP資料封包的數量，複製計數(Duplication Counter)，用於計數如下RTP資料封包的數量，即該RTP資料封包和已接收的RTP資料封包相同。在此僅簡要地給出了顯性擁塞通知反饋報告以及周期性顯性擁塞通知總結報告所應當包括的參數的定義，對於詳細內容，感興趣的讀者可以參考上述文獻。
而對於基於可分級的視頻業務，還可以應用流裁剪技術，即基於擁塞控制原理，媒體感知網路單元(media-aware network element，MANE)將對RTP資料封包進行流裁剪(stream thinning)。在圖2中示出了現有技術中的這種流裁剪的實施過程。該技術移除一個或多個完整的RTP資料封包或RTP資料封包的一部分，並根據具體情 况改寫RTP資料封包的標頭資訊。而在流裁剪過程中，傳輸路徑中的相關網路設備，例如路由器也會實施ECN技術來指示即將發生的擁塞。在這種情况下，由於RTP接收端沒有意識到MANE已經移除了一個或多個完整的RTP資料封包。因此，當在產生顯性擁塞通知反饋報告和/或周期性顯性擁塞通知總結報告時，在計算例如參數ECT(0)計數、ECT(1)計數和丟失封包計數(Lost Packets Counter)時，將不會計數被MANE移除的RTP資料封包。因此，反饋至RTP發送端的由RTCP承載的顯性擁塞通知反饋報告和/或周期性顯性擁塞通知總結報告將不再可靠。在此，由於計算這些被移除的RTP資料封包能夠非常有助於RTP發送端實現良好的碼率適配或擁塞控制效果，因此不計數這些RTP資料封包將會降低反饋報告的可靠性和準確性。綜上所述，在應用流裁剪技術的情况下，現有技術不能實現可靠的顯性擁塞通知反饋報告和/或周期性顯性擁塞通知總結報告。
此外，隨著視頻業務的不斷增加，尤其是基於可分級的視頻業務(例如應用可分級視頻編碼(scalable video coding)的視頻業務或應用多視角視頻編碼(multiview video coding)的視頻業務)的不斷增加對於ECN技術的設計提出更高的要求。如何在RTP傳輸路徑中的各網路設備中為基於可分級的視頻業務實現ECN技術，是有待解决的問題。特別的，在3GPP TS 36.300，va300，E-UTRAN中提出了將前文所述的ECN技術應用至基地台以 控制編解碼速率，但是却未對該建議給出詳細的實現方法。因此，例如如何在基地台中為基於可分級的視頻業務實現ECN技術，用戶終端如何向RTP發送端作出反饋也是有待解决的問題。
由此可見，先前技術中所提及的現有方案在應用流裁剪技術的情况下，不能為基於可分級的視頻業務確保顯性擁塞通知反饋報告和/或周期性顯性擁塞通知總結報告的可靠性。並且，在先前技術中，也沒有針對如何為基於由UDP承載RTP流的基於可分級的視頻業務實現ECN技術給出明確的方案。
為了解决背景技術中的問題，根據本發明的第一方面，提出了一種在網路單元中用於為基於可分級的視頻業務實現組合使用流媒體裁剪技術和顯性擁塞通知技術的方法，其中，媒體感知網路單元從RTP發送端接收基於由UDP承載的RTP流的所述基於可分級的視頻業務，並且所述基於可分級的視頻業務的位元流包括基層和一個或多個非基層，藉由所述基層和一個或多個非基層傳輸所述基於可分級的視頻業務的IP資料封包，所述方法包括如下步驟：A．確定是否需要對所述一個或多個非基層上的基於可分級的視頻業務的IP資料封包中的RTP資料封包進行流裁剪；B．當需要對所述一個或多個非基層上的基於可分級的視頻業務的RTP資料封包進行流裁剪時，判斷 是否需要移除一個或多個完整的RTP資料封包；以及C．當需要移除一個或多個完整的RTP資料封包時，則以虛擬RTP資料封包替換該RTP資料封包，其中所述RTP虛擬資料封包保留該RTP資料封包的RTP標頭資訊，並在所述RTP虛擬資料封包中以一個空的NAL單元來替換該RTP資料封包負載中的所有NAL單元。
較佳地，所述基於可分級的視頻業務包括應用可分級視頻編碼的視頻業務或應用多視角視頻編碼的視頻業務。
較佳地，當所述基於可分級的視頻業務為應用可分級視頻編碼的視頻業務時，所述基層為應用可分級視頻編碼的視頻業務的位元流的基本層，所述非基層為應用可分級視頻編碼的視頻業務的位元流的增强層。當所述基於可分級的視頻業務為應用多視角視頻編碼的視頻業務時，所述基層為應用多視角視頻編碼的視頻業務的基本視角，所述非基層為應用多視角視頻編碼的視頻業務的位元流的非基本視角。
較佳地，所述網路單元包括媒體感知網路單元和基地台，並且當所述網路單元為所述媒體感知網路單元時，所述方法還包括步驟D：將經流裁剪和/或未經流裁剪的基於可分級的視頻業務的IP資料封包經由網路發送至網路設備，所述網路設備包括基地台和路由器。
根據本發明的第二方面，提出了一種在網路設備中用於為基於可分級的視頻業務實現組合使用流媒體裁剪技術和顯性擁塞通知技術的方法，其中，所述基於可分級的視 頻業務是基於由UDP承載的RTP流的，並且所述基於可分級的視頻業務的位元流包括基層和一個或多個非基層，藉由所述基層和一個或多個非基層傳輸所述基於可分級的視頻業務的IP資料封包，所述方法包括如下步驟：b．根據預定條件確定是否需要將將IP資料封包的IP資料封包標頭中的顯性擁塞通知欄位設置為11，所述IP資料封包經過流裁剪或未經過流裁剪；c．當確定需要將IP資料封包標頭中的顯性擁塞通知欄位設置為11時，確定需要將IP資料封包標頭中的顯性擁塞通知欄位設置為11的非基層的數量，並且根據所述非基層的數量以降序的順序確定需要將IP資料封包標頭中的顯性擁塞通知欄位設置為11的非基層；以及d.對於需要將IP資料封包標頭中的顯性擁塞通知欄位設置為11的每個非基層，將該非基層中的至少一個IP資料封包的IP資料封包標頭中的顯性擁塞通知欄位設置為11，並產生更新後的IP資料封包。
較佳地，所述預定條件包括可用資源狀態、緩衝器狀態、通道品質和/或鏈路品質。
較佳地，所述網路設備包括基地台和路由器。
較佳地，在所述步驟b之前，所述方法還包括步驟a：a.從網路接收經媒體感知網路單元流裁剪和/或未經所述媒體感知網路單元流裁剪的基於可分級的視頻業務的IP資料封包。
較佳地，所述步驟d進一步包括：對於需要將IP資料封包標頭中的顯性擁塞通知欄位設置為11的每個非基 層，將該非基層中的時間上連續的兩個或三個IP資料封包的IP資料封包標頭中的顯性擁塞通知欄位設置為11，並產生更新後的IP資料封包。
由此，可以避免由於例如無線通道的時變性引起的IP資料封包的丟失，從而進一步確保了帶有顯性擁塞通知欄位設置為11的IP資料封包標頭的IP資料封包能夠被可靠地發送至RTP接收端。
較佳地，所述方法還包括步驟e：e.將經更新和/或未更新的基於可分級的視頻業務的IP資料封包發送至RTP接收端。
根據本發明的第三方面，提出了一種在RTP接收端中用於為基於可分級的視頻業務實現組合使用流媒體裁剪技術和顯性擁塞通知技術的方法，其中，所述基於可分級的視頻業務是基於由UDP承載的RTP流的，並且所述基於可分級的視頻業務的位元流包括基層和一個或多個非基層，藉由所述基層和一個或多個非基層傳輸所述基於可分級的視頻業務的IP資料封包，所述方法包括如下步驟：X1.從網路設備接收經所述網路設備更新和/或未經所述網路設備更新的基於可分級的視頻業務的IP資料封包；X2.根據IP資料封包標頭中的顯性擁塞通知欄位的取值，針對不同的取值來分類地計數IP資料封包中的RTP資料封包的數量，並且當從所述網路設備接收的IP資料封包中的RTP資料封包為虛擬RTP資料封包時，則不將該RTP資料封包用於視頻解碼，並且計數虛擬RTP資料 封包的數量；以及X3.當所接收的IP資料封包中的顯性擁塞通知欄位為11時，產生並向RTP發送端發送由RTCP承載的顯性擁塞通知反饋報告。
較佳地，當所接收的IP資料封包中的顯性擁塞通知欄位為11時，所述步驟X3進一步包括：X31.如果該IP資料封包是第一個顯性擁塞通知欄位為11的IP資料封包時，則記錄該IP資料封包的接收時間，產生並向RTP發送端發送由RTCP承載的顯性擁塞通知反饋報告；以及X32.如果該IP資料封包不是第一個顯性擁塞通知欄位為11的IP資料封包時，則判斷該IP資料封包是否與先前接收的顯性擁塞通知欄位為11的IP資料封包屬於相同的非基層，當不屬於相同的非基層時，則記錄該IP資料封包的接收時間，產生並向RTP發送端發送由RTCP承載的顯性擁塞通知反饋報告，當屬於相同的非基層時，則判斷接收該IP資料封包的接收時間是否小於先前接收的屬於相同的非基層的顯性擁塞通知欄位為11的IP資料封包的接收時間和RTP發送端與所述RTP接收端之間的回程時間的和，如果不小於，則記錄並更新所述接收時間，產生並向所述RTP發送端發送由RTCP承載的顯性擁塞通知反饋報告，如果小於，則僅記錄並更新所述接收時間。
由此，在收到帶有顯性擁塞通知欄位設置為11的IP資料封包標頭的IP資料封包時，RTP接收端可以確定該IP資料封包屬於現有的擁塞事件(congestion event)或還是屬於新的擁塞事件，並僅在屬於新的擁塞事件時候發送 顯性擁塞通知反饋報告。由此可以避免不需要的顯性擁塞通知反饋報告。
較佳地，所述步驟X3還包括：向所述RTP發送端發送由RTCP承載的周期性顯性擁塞通知總結報告，並且當顯性擁塞通知反饋報告及其處理時間大於發送周期性顯性擁塞通知總結報告的預定時間時，不再發送該顯性擁塞通知反饋報告。
藉由本發明提供的較佳的技術方案，能夠將ECN技術和流裁剪技術結合地應用至基於可分級的視頻業務，並能夠產生可靠的顯性擁塞通知和/或周期性顯性擁塞通知總結報告。由此在收到顯性擁塞通知和/或周期性顯性擁塞通知總結報告之後，RTP接收端能夠實現良好的碼率適配或擁塞控制效果。並且依據本發明的ECN技術還考慮了無線網路中的時變性問題。此外，在本發明中，網路設備(例如路由器和基地台)能夠根據需要為同一個基於可分級的視頻業務設置不同的擁塞事件，這對於RTP發送端實施準確的擁塞控制也是非常有利的。
本發明的各個方面將藉由下文中的具體實施例的說明而更加清晰。
藉由閱讀參照以下圖式所作的對非限制性實施例所作的詳細描述，本發明的其它特徵、目的和優點將會變得更加明顯： 圖1示出了IP資料封包標頭中的ECN域的四種設置示意圖；圖2示出了現有技術中實施流裁剪的方法流程圖；圖3示出了根據本發明的一個實施例的用於為基於可分級的視頻業務實現顯性擁塞通知的系統示意圖；圖4示出了根據本發明的一個實施例的在MANE中實施流裁剪的方法流程圖；圖5示出了根據本發明的一個實施例的在網路設備中實施用於為基於可分級的視頻業務實現顯性擁塞通知的方法的流程圖；圖6示出了根據本發明的一個實施例的在RTP接收端中實施用於為基於可分級的視頻業務實現顯性擁塞通知的方法的流程圖；圖7示出了根據本發明的另一個實施例的圖6中的步驟S603的實施方法的流程圖；圖8示出了一個IP資料封包的示例性結構示意圖；圖9示出了根據本發明的一個實施例的RTP虛擬資料封包的結構示意圖；以及圖10示出了根據本發明的一個實施例的確定擁塞事件的示意圖。
在圖中，貫穿不同的示圖，相同或類似的圖式標記表示相同或相對應的部件或特徵。
圖3示出了根據本發明的一個實施例的用於為基於可分級的視頻業務實現顯性擁塞通知的系統示意圖。圖4示出了根據本發明的一個實施例的在MANE中實施流裁剪的方法流程圖。圖5示出了根據本發明的一個實施例的在網路設備中實施用於為基於可分級的視頻業務實現顯性擁塞通知的方法的流程圖。圖6示出了根據本發明的一個實施例的在RTP接收端中實施用於為基於可分級的視頻業務實現顯性擁塞通知的方法的流程圖。
以下將結合圖4至圖6對圖3中的系統進行描述。如圖3所示，該系統包括RTP發送端、網路單元、網路設備以及RTP接收端。
RTP發送端例如可以是視頻服務器。網路單元例如可以是媒體感知網路單元MANE和基地台。網路設備例如可以是基地台和路由器。RTP接收端例如可以是行動終端。在圖3中以網路單元為MANE、網路設備為基地台為例對本發明進行闡述。
而在本發明的另一些實施例中，MANE的功能也可以完全在基地台側實現。因此，在這種情况下，系統將僅包括RTP發送端、網路設備(例如基地台)和RTP接收端。
並且，雖然在圖3中簡要地示出了MANE與網路設備直接連接，但是本領域的技術人員應當理解在其他情形中，MANE可以經過多個網元與網路設備連接。同理，雖然RTP發送端和MANE直接連接，但是本領域的技術人 員應當理解在其他情形中，RTP發送端可以經過多個網元與MANE連接。
在此，我們假定RTP發送端與網格中的各個元件已經完成初始化過程，即已經協商確定將使用ECN技術。
在運行中，RTP發送端首先將向MANE發送基於由UDP承載的RTP流的基於可分級的視頻業務。在圖8中示出了一個IP資料封包的示例性結構示意圖。如圖8所示，該IP資料封包包括IP資料封包標頭、UDP資料封包標頭和一個或多個RTP資料封包。在此，在IP資料封包標頭中包括兩位元的顯性擁塞通知欄位(未示出)。
在本發明中，該基於可分級的視頻業務的位元流包括基層和一個或多個非基層，將藉由基層和一個或多個非基層傳輸基於可分級的視頻業務的IP資料封包。
在此，基於可分級的視頻業務可以包括但不限於應用可分級視頻編碼的視頻業務和應用多視角視頻編碼的視頻業務。
當基於可分級的視頻業務為應用可分級視頻編碼的視頻業務時，基層指的是應用可分級視頻編碼的視頻業務的位元流的基本層，而非基層指得是應用可分級視頻編碼的視頻業務的位元流的增强層。
當基於可分級的視頻業務為應用多視角視頻編碼的視頻業務時，基層指得是應用多視角視頻編碼的視頻業務的基本視角，非基層指得是應用多視角視頻編碼的視頻業務的位元流的非基本視角。
現在參照圖4對在MANE中實施的流裁剪的方法進行描述。而在本發明的另一個實施例中，該方法也可以在基地台側實施。
在步驟S401中，MANE確定是否需要對一個或多個非基層上的基於可分級的視頻業務的IP資料封包中的RTP資料封包進行流裁剪。
如果不需要進行流裁剪，則進入步驟S407。在步驟S407中，MANE將未經流裁剪的基於可分級的視頻業務的IP資料封包經由網路發送至網路設備。
如果需要對所述一個或多個非基層上的基於可分級的視頻業務的RTP資料封包進行流裁剪，則進入步驟S402。在步驟S402中判斷是否需要移除一個或多個完整的RTP資料封包。
當不需要移除一個或多個完整的RTP資料封包時，即僅需要移除RTP資料封包中的一個或多個NAL單元時，則進入步驟S405。在步驟405中有選擇性地移除RTP資料封包中的一個或多個NAL單元並更新RTP資料封包的RTP標頭資訊。在文獻IETF RFC 6190(05、2011)“用於可分級的視頻編碼的RTP負載格式(RTP Payload Format for Scalable Video Coding)”中對該更新過程進行了具體描述，對於詳細內容，感興趣的讀者可以參考上述文獻。
當需要移除一個或多個完整的RTP資料封包時，則進入步驟S406。在步驟S406中，以虛擬RTP資料封包替 換這些本應該被移除的RTP資料封包。在此，圖9示出了根據本發明的一個實施例的RTP虛擬資料封包的結構示意圖。如圖9所示，RTP虛擬資料封包保留了本應該被移除的RTP資料封包的RTP標頭資訊，並且在RTP虛擬資料封包中以一個空的NAL單元來替換本應該被移除的RTP資料封包負載中的所有NAL單元。
在此，該空的NAL單元中的欄位可以被設置為：F=0、NRI=3、Type=31、Subtype=1、J=0、K=0以及L=0。
藉由使用RTP虛擬資料封包，基於可分級的視頻業務的RTP資料封包的序列號將保持流裁剪前的連續狀態，從而有助於RTP接收端不會再不計數原本遭移除的RTP資料封包，因此可以實現準確的顯性擁塞通知反饋報告和/或周期性顯性擁塞通知總結報告。另一方面，這仍保持了流裁剪的初衷和效果，因為原有的所有NAL單元已經被一個空的NAL單元替換了。
然後，步驟S405和步驟S406都進入步驟S407中，在步驟S407中，MANE將經流裁剪和/或未經流裁剪的基於可分級的視頻業務的IP資料封包經由網路發送至網路設備。需要指出的是，在MANE的功能也可以完全在基地台側實現的情况下，方法將不包括步驟S407。
接著，參考圖5對在網路設備中實施的為基於可分級的視頻業務實現顯性擁塞通知的方法進行描述。如圖5所示，在步驟S501中，網路設備從網路接收經MANE流裁 剪和/或未經MANE流裁剪的基於可分級的視頻業務的IP資料封包。需要指出的是，在MANE的功能也可以完全在基地台側實現的情况下，方法將不包括步驟S501。即，基地台可以在實施流裁剪技術之後，直接將ECN技術應用至基於可分級的視頻業務。
在步驟S502中，網路設備可以根據預定條件確定是否需要將IP資料封包的IP資料封包標頭中的顯性擁塞通知欄位設置為11，即指示即將發生的擁塞。
在此，預定條件可以包括可用資源狀態、緩衝器狀態、通道品質和/或鏈路品質。
當確定不需要將IP資料封包標頭中的顯性擁塞通知欄位設置為11時，則不需要對基於可分級的視頻業務的IP資料封包進行更新，方法進入步驟S505。在步驟S505中將未更新的基於可分級的視頻業務的IP資料封包發送至RTP接收端。
當確定需要將IP資料封包標頭中的顯性擁塞通知欄位設置為11時，則方法進入步驟S503。
在步驟S503中，網路設備確定需要將IP資料封包標頭中的顯性擁塞通知欄位設置為11的非基層的數量。在此，例如可以取决於網路設備想告知RTP發送端即將發生的擁塞程度來確定需要將IP資料封包標頭中的顯性擁塞通知欄位設置為11的非基層的數量。多個非基層意味著多個擁塞事件，而這將引起後續的RTP接收端的相對應的多個顯性擁塞通知反饋報告。進而，對於同一個基於 可分級的視頻業務，將產生多個顯性擁塞通知反饋報告。由此，RTP發送端將更精確地施行快速擁塞控制。
此外，在步驟S503中，還將根據非基層的數量以降序的順序確定需要將IP資料封包標頭中的顯性擁塞通知欄位設置為11的非基層。
具體地，對於應用可分級視頻編碼的視頻業務，由於應用可分級視頻編碼的視頻業務的基層和增强層是藉由{dependency_id，quality_id，temporal_id}來確定的，{dependency_id，quality_id，temporal_id}位於NAL單元的標頭資訊中。其中，{0,0,x}表示基層，x意味著temporal_id的任意取值，而其他組合則表示增强層。具有較高數值的dependency_id增强層的層數較高。對於具有相同數值的dependency_id增强層，具有較高數值的quality_id的增强層的層數較高。而對於具有相同數值的dependency_id，quality_id，具有較高數值的temporal_id的增强層的層數較高。因而，對於應用可分級視頻編碼的視頻業務，網路設備可以根據上述原則從高到低確定出需要將IP資料封包標頭中的顯性擁塞通知欄位設置為11的增强層。
而對於應用多視角視頻編碼的視頻業務，由於應用多視角視頻編碼的視頻業務的非基本視角是藉由{view_id}來區分的，{view_id}位於NAL單元的標頭資訊中。其中，具有較高數值的view_id的增强層的層數較高。因而，對於應用多視角視頻編碼的視頻業務，網路設備可以 根據上述原則從高到低確定出需要將IP資料封包標頭中的顯性擁塞通知欄位設置為11的非基本視角。
在步驟504中，對於需要將IP資料封包標頭中的顯性擁塞通知欄位設置為11的每個非基層，將該非基層中的至少一個IP資料封包標頭中的顯性擁塞通知欄位設置為11，並產生更新後的IP資料封包。
具體地，對於應用可分級視頻編碼的視頻業務，將需要將IP資料封包標頭中的顯性擁塞通知欄位設置為11的增强層中的至少一個IP資料封包的IP資料封包標頭中的顯性擁塞通知欄位設置為11，並產生更新後的IP資料封包。
對於應用多視角視頻編碼的視頻業務，將需要將IP資料封包標頭中的顯性擁塞通知欄位設置為11的非基本視角中的至少一個IP資料封包的IP資料封包標頭中的顯性擁塞通知欄位設置為11，並產生更新後的IP資料封包。
較佳地，在該步驟中，對於需要將IP資料封包標頭中的顯性擁塞通知欄位設置為11的每個非基層，將該非基層中的時間上連續的兩個或三個IP資料封包的IP資料封包標頭中的顯性擁塞通知欄位設置為11，並產生更新後的IP資料封包。由此可以避免由於例如無線通道的時變性引起的不利影響。
隨後，在步驟S505中，網路設備將經更新的基於可分級的視頻業務的IP資料封包發送至RTP接收端。
接著，參考圖6對在RTP接收端中實施的為基於可分級的視頻業務實現顯性擁塞通知的方法進行描述。如圖6所示，在步驟S601中，RTP接收端從網路設備接收經網路設備更新和/或未經所述網路設備更新的基於可分級的視頻業務的IP資料封包。
在步驟S602中，RTP接收端根據IP資料封包標頭中的顯性擁塞通知欄位的取值，針對不同的取值來分類地計數IP資料封包中的RTP資料封包的數量。在此，每收到一個IP資料封包都要對其中的RTP包進行計數。即對於圖1中所示的IP資料封包標頭中的顯性擁塞通知欄位為00、01、10和11四種情况下的RTP資料封包，無論該RTP資料封包是虛擬RTP資料封包還是非虛擬RTP資料封包，都將進行累積計數，以便用於可能將要發送的顯性擁塞通知反饋報告和/或周期性顯性擁塞通知總結報告。具體地，將對ECT(0)、ECT(1)、ECN-CE、not-ECT這四個參數計數RTP資料封包的數量。
並且，在該步驟中，當從網路設備接收的IP資料封包中的RTP資料封包為虛擬RTP資料封包時，則不將該RTP資料封包用於視頻解碼，並且計數虛擬RTP資料封包的數量。在此，將虛擬RTP資料封包的數量計數入參數丟失封包計數(Lost Packets Counter)和複製計數(Duplication Counter)。
在步驟S603中，當所接收的IP資料封包中的顯性擁塞通知欄位為11時，RTP接收端產生並向RTP發送端發 送由RTCP承載的顯性擁塞通知反饋報告。
在此，圖7示出了根據本發明的另一個實施例的圖6中的步驟S603的實施方法的流程圖。如圖7所示，當所接收的IP資料封包中的顯性擁塞通知欄位為11時，在步驟S1中RTP接收端判斷該IP資料封包是否是第一個顯性擁塞通知欄位為11的IP資料封包。
如果是，則觸發擁塞事件，方法進入步驟S3，在步驟S3中RTP接收端記錄該IP資料封包的接收時間，產生並向RTP發送端發送由RTCP承載的顯性擁塞通知反饋報告。
如果不是，則方法進入步驟S2。在步驟S2中RTP接收端判斷該IP資料封包是否與先前接收的顯性擁塞通知欄位為11的IP資料封包屬於相同的非基層。對於應用可分級視頻編碼的視頻業務，可以藉由NAL單元的標頭中的{dependency_id，quality_id，temporal_id}來進行判斷。而對於應用多視角視頻編碼的視頻業務，可以藉由NAL單元的標頭中的{view_id}來進行判斷。
如果不屬於相同的非基層，則觸發擁塞事件，方法又進入步驟S3。在步驟S3中RTP接收端記錄該IP資料封包的接收時間，產生並向RTP發送端發送由RTCP承載的顯性擁塞通知反饋報告。
如果屬於相同的非基層，則方法進入步驟S4。在步驟S4中，RTP接收端判斷接收該IP資料封包的接收時間是否小於先前接收的屬於相同的非基層的顯性擁塞通知欄 位為11的IP資料封包的接收時間和RTP發送端與RTP接收端之間的回程時間(Round Trip Time，RTT)的和。
如果不小於，則觸發擁塞事件，方法進入步驟S5。在步驟S5中，RTP接收端記錄並更新接收時間，產生並向RTP發送端發送由RTCP承載的顯性擁塞通知反饋報告。
如果小於，則方法進入步驟S6。在步驟S6中，RTP接收端記錄並更新接收時間。
現在參照圖10對上述過程在進行示例性描述。圖10示出了根據本發明的一個實施例的確定擁塞事件的示意圖。如圖10所示，當RTP接收端接收到第一個顯性擁塞通知欄位為11的IP資料封包(序列號SN=N)時，將觸發擁塞事件，即RTP接收端將產生並向RTP發送端發送由RTCP承載的顯性擁塞通知反饋報告。並且，在此還記錄該IP資料封包的接收時間，作為與非基層x相關聯的接收時間T_old。
而此後，當RTP接收端接收到下一個新的顯性擁塞通知欄位為11的IP資料封包SN=N+1時，並且判斷出這個新的顯性擁塞通知欄位為11的IP資料封包SN=N+1與IP資料封包SN=N屬於相同的非基層x時，將判斷這個IP資料封包SN=N+1的接收時間T_new<T_old+RTT是否成立。在該實施例中，上述關係成立。因而僅記錄T_new，並以T_new的取值替代T_old的取值，作為新的與非基層x的相關聯的接收時間T_old。並且在此不觸發 擁塞事件，即不向RTP發送端發送由RTCP承載的顯性擁塞通知反饋報告。
接著，如圖10所示，RTP又收到了非基層x-1的一個新的顯性擁塞通知欄位為11的IP資料封包SN=M，並判斷出這個新的顯性擁塞通知欄位為11的IP資料封包SN=M與IP資料封包SN=N和SN=N+1不屬於相同的非基層。在這種情况下，將觸發擁塞事件，即RTP接收端將產生並向RTP發送端發送由RTCP承載的顯性擁塞通知反饋報告。在此，還記錄該IP資料封包SN=M的接收時間，作為與非基層x-1相關聯的接收時間T_old。
然後，當RTP接收端接收到下一個新的顯性擁塞通知欄位為11的IP資料封包SN=M+1時，並且判斷出這個新的顯性擁塞通知欄位為11的IP資料封包SN=M+1與IP資料封包SN=M屬於相同的非基層x時，將判斷這個IP資料封包SN=M+1的接收時間T_new<T_old+RTT是否成立。在該實施例中，上述關係成立。因而僅記錄T_new，並以T_new的取值替代T_old的取值，作為新的與非基層x-1的相關聯的接收時間T_old。並且在此不觸發擁塞事件，不向RTP發送端發送由RTCP承載的顯性擁塞通知反饋報告。
較佳地，在此，RTP接收端還向RTP發送端發送由RTCP承載的周期性顯性擁塞通知總結報告，並且當顯性擁塞通知反饋報告及其處理時間大於發送周期性顯性擁塞通知總結報告的預定時間時，不再發送該顯性擁塞通知反 饋報告。在此，處理時間時指RTP接收端處理反饋報告中的各種參數的時間以及時延等。
在此，在產生顯性擁塞通知和/或周期性顯性擁塞通知總結報告時，將處理ECT(0)計數、ECT(1)計數、ECN-CE計數、非ECT計數、丟失封包計數、擴展最高序列號、複製計數這些參數，並在報告中包括這些參數。
最後，如圖3所示，當RTP接收端接收到顯性擁塞通知和/或周期性顯性擁塞通知總結報告之後，RTP發送端將藉由擁塞控制算法等進行準確的擁塞控制。
需要說明的是，上述實施例僅是示範性的，而非對本發明的限制。任何不背離本發明精神的技術方案均應落入本發明的保護範圍之內，這包括使用在不同實施例中出現的不同技術特徵，裝置方法可以進行組合，以取得有益效果。此外，不應將申請專利範圍中的任何圖式標記視為限制所涉及的申請專利範圍；“包括”一詞不排除其他權利要求或說明書中未列出的裝置或步驟。

Claims (15)

  1. 一種在網路單元中用於為基於可分級的視頻業務實現組合使用流媒體裁剪技術和顯性擁塞通知技術的方法，其中，媒體感知網路單元從RTP發送端接收基於由UDP承載的RTP流的所述基於可分級的視頻業務，並且所述基於可分級的視頻業務的位元流包括基層和一個或多個非基層，藉由所述基層和一個或多個非基層傳輸所述基於可分級的視頻業務的IP資料封包，所述方法包括如下步驟：A．確定是否需要對所述一個或多個非基層上的基於可分級的視頻業務的IP資料封包中的RTP資料封包進行流裁剪；B．當需要對所述一個或多個非基層上的基於可分級的視頻業務的RTP資料封包進行流裁剪時，判斷是否需要移除一個或多個完整的RTP資料封包；以及C．當需要移除一個或多個完整的RTP資料封包時，則以虛擬RTP資料封包替換該RTP資料封包，其中所述RTP虛擬資料封包保留該RTP資料封包的RTP標頭資訊，並在所述RTP虛擬資料封包中以一個空的NAL單元來替換該RTP資料封包負載中的所有NAL單元。
  2. 根據申請專利範圍第1項的方法，其中，所述基於可分級的視頻業務包括應用可分級視頻編碼的視頻業務或應用多視角視頻編碼的視頻業務。
  3. 根據申請專利範圍第2項的方法，其中，當所述 基於可分級的視頻業務為應用可分級視頻編碼的視頻業務時，所述基層為應用可分級視頻編碼的視頻業務的位元流的基本層，所述非基層為應用可分級視頻編碼的視頻業務的位元流的增强層；當所述基於可分級的視頻業務為應用多視角視頻編碼的視頻業務時，所述基層為應用多視角視頻編碼的視頻業務的基本視角，所述非基層為應用多視角視頻編碼的視頻業務的位元流的非基本視角。
  4. 根據申請專利範圍第1至3項中任一項的方法，其中，所述網路單元包括媒體感知網路單元和基地台，並且當所述網路單元為所述媒體感知網路單元時，所述方法還包括步驟D：將經流裁剪和/或未經流裁剪的基於可分級的視頻業務的IP資料封包經由網路發送至網路設備，所述網路設備包括基地台和路由器。
  5. 一種在網路設備中用於為基於可分級的視頻業務實現組合使用流媒體裁剪技術和顯性擁塞通知技術的方法，其中，所述基於可分級的視頻業務是基於由UDP承載的RTP流的，並且所述基於可分級的視頻業務的位元流包括基層和一個或多個非基層，藉由所述基層和一個或多個非基層傳輸所述基於可分級的視頻業務的IP資料封包，所述方法包括如下步驟：b．根據預定條件確定是否需要將IP資料封包的IP資料封包標頭中的顯性擁塞通知欄位設置為11，所述IP 資料封包經過流裁剪或未經過流裁剪；c．當確定需要將IP資料封包標頭中的顯性擁塞通知欄位設置為11時，確定需要將IP資料封包標頭中的顯性擁塞通知欄位設置為11的非基層的數量，並且根據所述非基層的數量以降序的順序確定需要將IP資料封包標頭中的顯性擁塞通知欄位設置為11的非基層；以及d.對於需要將IP資料封包標頭中的顯性擁塞通知欄位設置為11的每個非基層，將該非基層中的至少一個Ip資料封包的IP資料封包標頭中的顯性擁塞通知欄位設置為11，並產生更新後的IP資料封包。
  6. 根據申請專利範圍第5項的方法，其中，所述預定條件包括可用資源狀態、緩衝器狀態、通道品質和/或鏈路品質。
  7. 根據申請專利範圍第5項的方法，其中，所述網路設備包括基地台和路由器。
  8. 根據申請專利範圍第5項的方法，其中，在所述步驟b之前，所述方法還包括步驟a：a.從網路接收經媒體感知網路單元流裁剪和/或未經所述媒體感知網路單元流裁剪的基於可分級的視頻業務的IP資料封包。
  9. 根據申請專利範圍第5項的方法，其中，所述步驟d進一步包括：對於需要將IP資料封包標頭中的顯性擁塞通知欄位設置為11的每個非基層，將該非基層中的時間上連續的 兩個或三個IP資料封包的IP資料封包標頭中的顯性擁塞通知欄位設置為11，並產生更新後的IP資料封包。
  10. 根據申請專利範圍第5項的方法，其中，所述方法還包括步驟e：e.將經更新和/或未更新的基於可分級的視頻業務的IP資料封包發送至RTP接收端。
  11. 根據申請專利範圍第5至10項中任一項的方法，其中，所述基於可分級的視頻業務包括應用可分級視頻編碼的視頻業務或應用多視角視頻編碼的視頻業務。
  12. 根據申請專利範圍第11項的方法，其中，當所述基於可分級的視頻業務為應用可分級視頻編碼的視頻業務時，所述基層為應用可分級視頻編碼的視頻業務的位元流的基本層，所述非基層為應用可分級視頻編碼的視頻業務的位元流的增强層；當所述基於可分級的視頻業務為應用多視角視頻編碼的視頻業務時，所述基層為應用多視角視頻編碼的視頻業務的基本視角，所述非基層為應用多視角視頻編碼的視頻業務的位元流的非基本視角。
  13. 一種在RTP接收端中用於為基於可分級的視頻業務實現組合使用流媒體裁剪技術和顯性擁塞通知技術的方法，其中，所述基於可分級的視頻業務是基於由UDP承載的RTP流的，並且所述基於可分級的視頻業務的位元流包括基層和一個或多個非基層，藉由所述基層和一個或多個非基層傳輸所述基於可分級的視頻業務的IP資料封 包，所述方法包括如下步驟：X1.從網路設備接收經所述網路設備更新和/或未經所述網路設備更新的基於可分級的視頻業務的IP資料封包；X2.根據IP資料封包標頭中的顯性擁塞通知欄位的取值，針對不同的取值來分類地計數IP資料封包中的RTP資料封包的數量，並且當從所述網路設備接收的IP資料封包中的RTP資料封包為虛擬RTP資料封包時，則不將該RTP資料封包用於視頻解碼，並且計數虛擬RTP資料封包的數量；以及X3.當所接收的IP資料封包中的顯性擁塞通知欄位為11時，產生並向RTP發送端發送由RTCP承載的顯性擁塞通知反饋報告。
  14. 根據申請專利範圍第13項的方法，其中，當所接收的IP資料封包中的顯性擁塞通知欄位為11時，所述步驟X3進一步包括：X31.如果該IP資料封包是第一個顯性擁塞通知欄位為11的IP資料封包時，則記錄該IP資料封包的接收時間，產生並向RTP發送端發送由RTCP承載的顯性擁塞通知反饋報告；以及X32.如果該IP資料封包不是第一個顯性擁塞通知欄位為11的IP資料封包時，則判斷該IP資料封包是否與先前接收的顯性擁塞通知欄位為11的IP資料封包屬於相同的非基層，當不屬於相同的非基層時，則記錄該IP資 料封包的接收時間，產生並向RTP發送端發送由RTCP承載的顯性擁塞通知反饋報告，當屬於相同的非基層時，則判斷接收該IP資料封包的接收時間是否小於先前接收的屬於相同的非基層的顯性擁塞通知欄位為11的IP資料封包的接收時間和RTP發送端與所述RTP接收端之間的回程時間的和，如果不小於，則記錄並更新所述接收時間，產生並向所述RTP發送端發送由RTCP承載的顯性擁塞通知反饋報告，如果小於，則僅記錄並更新所述接收時間。
  15. 根據申請專利範圍第13或14項的方法，其中，所述步驟X3還包括：向所述RTP發送端發送由RTCP承載的周期性顯性擁塞通知總結報告，並且當顯性擁塞通知反饋報告及其處理時間大於發送周期性顯性擁塞通知總結報告的預定時間時，不再發送該顯性擁塞通知反饋報告。
TW102135678A 2012-10-22 2013-10-02 組合使用流媒體裁剪技術和顯性擁塞通知技術的方法 TW201427452A (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201210406296.8A CN103780954B (zh) 2012-10-22 2012-10-22 一种组合使用流媒体裁剪技术和显性拥塞通知技术的方法

Publications (1)

Publication Number Publication Date
TW201427452A true TW201427452A (zh) 2014-07-01

Family

ID=49886987

Family Applications (1)

Application Number Title Priority Date Filing Date
TW102135678A TW201427452A (zh) 2012-10-22 2013-10-02 組合使用流媒體裁剪技術和顯性擁塞通知技術的方法

Country Status (3)

Country Link
CN (1) CN103780954B (zh)
TW (1) TW201427452A (zh)
WO (1) WO2014064496A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103997434B (zh) * 2014-05-21 2017-12-05 华为技术有限公司 网络传输状况的探测方法和相关设备
CN110022264B (zh) * 2018-01-08 2020-09-08 华为技术有限公司 控制网络拥塞的方法、接入设备和计算机可读存储介质
GB201817781D0 (en) * 2018-10-31 2018-12-19 V Nova Int Ltd Mehods, apparatuses, computer programs and computer-readable media

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6091709A (en) * 1997-11-25 2000-07-18 International Business Machines Corporation Quality of service management for packet switched networks
US7933294B2 (en) * 2005-07-20 2011-04-26 Vidyo, Inc. System and method for low-delay, interactive communication using multiple TCP connections and scalable coding
US20070168955A1 (en) * 2005-10-27 2007-07-19 Microsoft Corporation Scalable networked build automation
CN101123606A (zh) * 2007-07-13 2008-02-13 上海广电（集团）有限公司中央研究院 基于实时传输协议或实时控制协议的avs传输控制方法
GB0809014D0 (en) * 2008-05-17 2008-06-25 Slever Solutions Ltd Improvements in and relating to the management of data congestion in a data network
JP5155449B2 (ja) * 2008-07-26 2013-03-06 トムソン ライセンシング スケーラブルビデオコーディング（ｓｖｃ）を使用する高速チャネル変更アプリケーションのためのリアルタイムトランスポートプロトコル（ｒｔｐ）パケット化方法

Also Published As

Publication number Publication date
CN103780954A (zh) 2014-05-07
WO2014064496A1 (en) 2014-05-01
CN103780954B (zh) 2017-05-10

Similar Documents

Publication Publication Date Title
JP6754810B2 (ja) マルチメディアシステムにおけるデータ送信方法
US10541770B2 (en) Efficient recovery of lost packets using double parity forward error correction
JP6606240B2 (ja) 放送システムにおけるマルチメディアデータの転送装置及び方法
US8023419B2 (en) Remote monitoring of real-time internet protocol media streams
US8867385B2 (en) Tunneling reports for real-time Internet Protocol media streams
US9282133B2 (en) Communicating control information within a real-time stream
EP3080915B1 (en) Redundant encoding
KR101206415B1 (ko) 근거리 네트워크에서 다중점 스트림을 전송하는 방법 및이러한 방법을 실행하는 연결 디바이스
KR20150083428A (ko) Mmt 서비스의 패킷 재전송 방법 및 장치, 재전송 요청 방법 및 장치
CN104661112A (zh) 基于可伸缩选择窗口的视频流文件传输方法及装置
JP4600513B2 (ja) データ送信装置、送信レート制御方法およびプログラム
TW201427452A (zh) 組合使用流媒體裁剪技術和顯性擁塞通知技術的方法
JP2014509113A (ja) 相互階層最適化を用いた、マルチメディアデータパケットを送信する方法及び装置
EP3095230B1 (en) Processing of data files
JP2011211390A (ja) 送信装置、送信方法、プログラム
WO2023133364A2 (en) Flow correlation and http media classification
WO2021144139A1 (en) Method, apparatus and computer program product providing for signaling of viewport orientation timing in panoramic video delivery
Singh et al. IETF RMCAT Working Group Z. Sarker Internet-Draft Ericsson AB Intended status: Standards Track C. Perkins Expires: May 3, 2018 University of Glasgow
Asís López-Fuentes de et al. Video Transmission Using Network Coding
JP2012195864A (ja) 伝送システム及び伝送装置、並びに伝送方法
de As et al. Video transmission using network coding
JP2019524011A (ja) Ｍｍｔｐパケットを送受信する方法及びその装置