??????????????????????
前言
交互協作應用，或者包含許多個獨立多媒體程序的分佈式遊戲，運行時會同步生成和/或播放多路的音頻和視頻流。隨着單個流的變化和流/應用被啓動或最後終止對資源的需求，可用的資源總量會隨之動態的改變。網絡多媒體應用程序（NetMM）必須準備去適應這些變化，利用他們可以提供給用戶可接受的不同級別的服務的這一事實。本文着重指出了添加網絡和主機適應能力到基於組件的Directshow RTP的所出現的問題。
Directshow 是微軟的一套針對視頻數據採集和顯示的系統架構。Directshow RTP 是一套拓展了Directshow系統架構的框架，添加了對採用RTP協議通過網絡傳輸多媒體應用數據的支持。Directshow RTP 框架被設計用來支持高擴展性的廣闊領域的多媒體流任務。Directshow RTP 做爲 Windwos NT5.0一部分會隨同操作系統發行。我們已經擴展了這套架構，添加了對流應用的支持，對本地主機和計算機網絡因分發和接收多媒體數據而引起的可用資源的變化，能夠動態補償。
我們的擴展包括採集可做出適配選擇的相關信息，基於這些信息做出決策的組件，和可以利用基礎體系結構中早已具有的能力來執行策略的方法。本文對於應用開發和用於開發這些應用的架構的設計都是有益的。
1．?介紹
NetMM是運行在客戶計算機和單用戶工作站的執行程序中資源需求最強烈的一類。這些應用對主機處理能力和網路帶寬的耗用都有很高的要求。這些應用也經常需要底層操作系統和計算機網絡接近實時處理的所提供能夠執行的必要資源。以上任何資源訪問的延遲都會導致明顯的可覺察的展現給用戶的質量的下降。隨着單個NetMM程序的資源需求的變化，和流和程序的啓停，本地主機和網絡可用資源會顯著變化。因爲可用資源和需求資源都會在運行期間顯著變化，NetMM必須準備流暢的適配這些變化。
在這篇論文中，我們主要針對兩種類型的適配－網絡適配和主機適配。網絡適配是指在網絡可用帶寬，網絡抖動，數據丟失等條件下，流程序能夠通過各種方法充分利用網絡資源的能力。主機適配可被定義爲應用程序基於本地主機的情況，包括CPU利用率、可用內存，來改變自己的行爲。 下面列舉的例子的情形對網絡和主機適配都是有用的：
多流對資源的競爭。假定某個應用有一個音頻流，一個高比特率的視頻流，和一個突發的幻燈片流，其中音頻流對用戶來講是最高優先級的。如果音頻流的質量受到影響，爲滿足用戶的優先權，程序可以適配幻燈放映和視頻流以降低系統資源佔用。應用也必須可以檢測對網絡資源的競爭，相應調節它發送和接收各個流的行爲。
允許體驗對不同的網絡和處理器資源的用戶都可承受。在一次包括不同帶寬和處理能力的異質用戶的視頻會議或交互會議中，所有節點將不可能接收所有的流。在這種條件下，如果採用分級編碼，所有會議人員都可參與。這種適配形式，相較一個不採用分級編碼流的展現，允許擁有很少資源需求的異質參與者獲得到極大的滿足。
補償不同重要程度應用程序角色的變化。在單用戶環境，一個程序相對其他程序的重要程度會隨着時間變化。比如，當一個用戶從看新聞廣播切換到編譯或一個設計任務，像Windows 95這樣的操作系統一般會調度多媒體程序至後臺以較低的優先級運行。當用戶切換到新聞廣播，去看感興趣的事件（比如，最新的棒球運動消息），操作系統會相應提升此程序的執行優先級。NetMM也應該對被放置於後臺或前臺做出響應。這樣，NetMM 程序切換到後臺後應該減少網絡和CPU佔用率，回到前臺後要全速運行。上面的附加的響應和超出操作系統所執行的優先級調度策略的是給那些急需資源的任務分配最多資源。
研究人員已經爲NetMM程序的適配準備了幾套方法。這些方法包括不同形式的源碼流控制，採用分層視頻的接受驅動，和主機資源的適配。儘管像RSVP和ATM提供QoS保障的協議和機制已能夠滿足NetMM程序，研究人員已在研究在資源約束和資源變化的條件下適配的應用。
假定適配對應用質量的影響是正面的，我們決定研究應用開發人員可以怎樣不擔心適配的複雜性，把適配添加到應用中。在這篇論文中，詳細研究了的NetMM程序如何基於多媒體流組件架構適配網絡和主機條件的變化。論文討論了我們在該領域的成果，包括針對資源限制的適配的新的研究，創建用於NetMM支持網絡主機適配的的中間件，和一些對採用適配的應用開發人員或架構設計人員有益的教訓。
我們把微軟的DirectShow做爲我們架構的基礎。Directshow提供了一個模塊化，可擴展的實現多媒體應用的系統。在DirectShow架構中，我們添加了一套實現RTP協議的框架，我們稱爲DirectShow RTP，用來創建NetMM應用，
本論文的剩餘部分組織如下。第2部分講述了DirectShow 架構和DirectShow RTP。第3部分對此進行了討論，分析了一些添加適配功能到 像DirectShow RTP這些基於組件的架構的幾種方法。第4部分給出了基於數據源的適配實現，第5部分，介紹了採用層多播的接收驅動的適配實現。第6部分提供了一個總體針對基於組件的流框架網絡、主機適配實現的經驗分析。第7部分討論了可能進一步提高適配在NetMM中應用的下一步的工作領域。最後以在基於組件架構中實現適配的好處的討論結束本文。
? 2．?DirectShow 架構
2．1 微軟的DirectShow
DirectShow 架構被用來爲許多應用提供基本的多媒體流處理功能。它被用於全方位的多媒體處理，包括採集，編解碼，回放，音視頻數據的存儲。DirectShow 採用4種主要抽象來操作多媒體數據。這些抽象術語爲過濾器（filter），管腳（pin），媒體樣本（media sample）和媒體類型（media types）。
DirectShow filters 被用來封裝一個或多個與多媒體流有關的任務。DirectShow filters例子中包含視頻採集filter,被用來控制視頻攝像設備，輸出原始RGB視頻幀；H.261編解碼filter,被用來壓縮原始RGB視頻數據至H.261幀和解壓。存在類似的用於音頻流的Filters, 音頻採集filter和G.711編解碼filter。Filter還被用來在本地設備回放音視頻。爲允許程序綜合幾種功能來處理音頻或視頻，DirectShow採用filter graphs。Filter graph 是一些串行連接的有序的，處理多媒體數據緩衝的filters。圖1給出了一個範例filter graph, 包含一個文件讀取filter,一個MPEG解碼filter,和一個視頻渲染filter,用以回放視頻。
Filters 通過pins連接起來組成filter graph。Pins在DirectShow中有兩種主要作用。第一是在filters互聯時協商media type，和Filter互聯時的分配內存。Media type 協商是media type管理兩個確定的filters數據交互的方式。內存分配協商被用以指定保存多媒體緩衝（也被稱爲media sample）的內存在何處分配，分配多大的內存（字節對齊，使用來自內存映射設備的特定區域的內存，等）。
DirectShow 中Pins的第二項任務是隱藏filters間交換數據的方式。一旦一條鏈接已被成功建立，filters只是簡單的接收和分發media samples至它的pins, pins相應的執行實際的操作，也就是samples 被分發到filter graph中下一個filter。
Media samples在DirectShow中是對存儲多媒體數據緩衝區的抽象。除了它們含有的多媒體數據緩，media samples還包含用來確定samples生命期的起始和終止時間戳。這些值可被渲染器用來確定何時播放和檢測性能問題。
DirectShow media types 指定了filters之間交換包含media sample的數據的格式。Media types包含好幾部分；其中最重要的是major 和minor 類型。一個主類型一般用來根據最高層的語義指導區分格式。MAJORTYPE_VIDEO 和MAJORTYPE_AUDIO是主類型的兩種。次類型一般用來確定格式的不同，比如MINORTYPE_AUDIO_G711A和MINORTYPE_AUDIO_G723。如果兩個filters之間的 pins可以找到相同的media type，那麼它們之間的就可以建立連接。DirectShow 允許定義新的filters，pins，和media types。充分利用DirectShow內在的可擴展性，我們定義了兩個新的media types和幾個filters，實現了DirectShow架構下采用RTP協議通過網絡傳輸多媒體數據流。這個新的NetMM框架被稱爲DirectShow RTP。
2．2 DirectShow RTP
DirectShow RTP 定義了一組支持使用RTP協議網絡傳輸多媒體流的fitlers和media types。
新定義的filters是RTP Source filter，RTP Render Filter, RTP Demux filter, RTP Receive Payload Handler(RPH) filter，和RTP Send Payload（SPH）filter。使用這五個filters（同時使用標準的CODEC和採集/渲染filters），構造一個可以通過RTP協議網絡傳輸音視頻流的數據平臺應用是可能的。
RTP Source filter被用來從一個單獨的RTP會話中接收RTP和RTCP包。這些包被封裝在media sample中發到filter graph。這個filter被用以外出連接的廣播media type包括主類型
RTP_MAJORTYPE_MULTIPLE_STREAM和次類型RTP_MINORTYPE_PAYLOAD_ANY，它們二者都是DirectShow RTP框架的一部分。這樣的media types組合表示這個filter可以生成一個包含一個或多個RTP流的流，放到一起有可能是單個負載類型或多負載類型。這個filter提供一個指定發送給其它主機RTCP接收器報告和指定網絡地址和端口接口來接收RTP會話的接口。
與RTP Source filter緊密相關的就是RTP Render filter。這個filter接收media type 主類型爲RTP_MAJORTYPE_SINGLE_STREAM，任何次類型的外來連接。爲了遵從AVP的對發送者在RTP流關於負載類型和SSRC的規定，更加嚴格的主類型的選擇是必要的。這個filter提供了與RTP Source filter類似控制的接口。
RTP Demux filter被用來多路分離來自RTP Source filter的RTP包。多路分離遵從SSRC和每個包的負載類型。這個filter接收主類型爲RTP_MAJORTYPE_MULTIPLE_STREAM和次類型爲RTP_MINORTYPE_PAYLOAD_ANY的pin的連接。此filter登記一個或多個輸出pin，
主類型爲RTP_MAJORTYPE_SINGLE_STREAM，與正在討論的pin上單個分發流負載有關的次類型。這個filter提供了控制流如何多路分離和如何分配到特定輸出pin的接口。
RTP RPH filter 被用來轉變來自單個固定負載類型源的RTP包爲它們對應的未打包的形式。因此，這個filter的一個版本是用來獲取RTP H.261包和生成H.261壓縮視頻幀。這個版本的filter已被設計爲支持H.261，H.263，Indeo，G.711，G.723和G.729和常見的多種音視頻負載類型。這些常用的音視頻RPH filter均遵從RTP AVP規定打包media sample。它提供了指定數目的緩衝的接口來解決在數據丟失（或轉發）前等待時間，特別是丟幀時重建，需要進行的緩衝重分配工作。RTP SPH fitler與RTP RPH filter相似，它的任務是將音視頻壓縮filter輸出的media samples的分解爲RTP包。它提供提供的接口有，指定最大生成包大小（爲了適用不同網絡的MTU（最大傳輸單元））和PT值（允許使用動態RTP? PT值）。
圖2和圖3展示了DirectShow RTP中定義的filters如何運用。圖2是一個採集本地多媒體數據並使用RTP協議通過網絡發送的filter graph。它包含一個輸出原始視頻幀的視頻採集filter，緊跟一個壓縮幀的編碼filter。一旦壓縮，這些幀就會被髮送到RTP SPH filter，分片打包，生成RTP包，對應的發送到 RTP Render filter，通過網絡傳輸這些包。圖3展現了一個filter graph，用來接收包含視頻流RTP包，播放視頻。這個graph由一個用來接收包的RTP Source filter，一個根據源和負載類型進行分類的RTP Demux filter，一個把RTP包轉爲壓縮視頻幀的RTP RPH filter組成。這些filter隨後的是用來解壓幀的解碼filter，一個顯示未壓縮幀的渲染filter。
DirectShow RTP 框架中最重要的就是對用來顯示RTP流和用來接收，處理，發送RTP包的五個filters的media type的定義。Media type的定義提供了一個有用的，描述DirectShow 系統結構中RTP流的方法，允許以後的可以添加新的處理RTP流方法的filters的定義。這些filter的實現提供了一組組件，基於此NetMM應用可以容易的被創建，並提供一套可用於未來NetMM領域的進一步研究的體系結構。
??
3．?DirectShow RTP 適配
DirectShow允許一個程序員編寫多媒體程序時不必考慮媒體的處理細節。DirectShow RTP拓展了這種架構以採用RTP協議支持NetMM應用。爲了支持適配，DirectShow需要做出幾處改變。組件被用來度量和監控多媒體流的分發和顯示的服務質量，測定在不利條件這些流任何出現質量下降的原因，對這些條件的初始適配，和測定是否適配針對流的分發和展現，達到了預期的改進效果。同樣必要的是開發一套決定同一程序或同一主機不同應用程序不同流相對的優先級系統。
DirectShow架構支持允許一個filter graph 適配影響它加載的流不利條件這樣一套機制。這種機制是基於質量消息（quality messages）的產生和解釋。Quality messages指出當數據被過快生成和過慢被graph中filters吸收時的情景。Quality messages在filter graph中在與數據流相反的方向傳播。這是每個filter向上傳遞消息以前嘗試保存狀態到quality messages的責任。爲標識流的爆發或枯竭的嚴重程度，quality messages包含一個字段，用來標識一個逆流而上的filter應該改變碼流的比例。除了一些默認行爲quality messages的分發, 同樣可能的是配置filter，分發這些消息到其它系統組件中。這允許DirectShow支持兩種模式的適配。默認的模式，包含向上傳遞的質量消息，允許流內方式的適配。重新路由這些消息到一個變化的接收者需要一個適配控制器集中適配控制多個流。這兩種quality message 分發方式導致了兩種不同的在DirectShow RTP架構中添加適配支持的方法。
3．1 流內方式
在這種方式中（如圖4所示），生成質量控制消息的filter會發送消息到下一個逆向filter。Graph 中每一個filter都可能改變它的輸出或不加處理向上傳遞這個消息。
這種方式有以下特徵：
每一filter監控QoS並能夠提供性能指示。
每個filter都可能含有解析質量信息並對它做出反映的功能。
適配的任務分佈於組件之中並且它們之間的交互是簡單的。
然而，這種方式也存在以下缺點：
每個流都單獨適配而不是與其它流協作適配。
一個應用無法與其它應用協作分享可用資源。
很難執行比如“在編解碼參數設置前適配採集”這種策略。
流內服務質量控制提供了一種簡單的，易於執行的機制來獲取一個filter graph中不利條件信息並做出反應。然而，這種質量度量方法在事實面前嚴重受限，它只適應於單個filter graph環境中而不是應用或廣義系統的範圍。
3．2適配控制途徑
爲一個filter指定一適配控制器（DirectShow中質量管理器），應用都爲它的每個filter pin設置一個質量消息接收入口。如果接收入口已設定，fitlers分發質量消息到接收器而不是向上發送。一個適配控制器可能監控單個filter,一個filter graph中所有filters，一個程序中所有filter graphs,或者甚至是在幾個不同應用環境執行的filter graphs。適配控制器採用質量消息進行適配選擇。圖5列舉了一個適配控制器控制兩個流，適配控制輸入來自兩個渲染filters,適配策略的執行通過修改源（採集）和編解碼filters的行爲得以貫徹。
一個採用適配控制的架構會引入幾個問題。其中一個必須說明的是確定適配控制如何與應用交互。同樣必要的是檢查適配控制怎樣可以以靈活的方式編寫，這樣可以控制不同種類的組件。最後，對網絡和主機不利條件適配策略必須確定。這些策略必須對單filter graph（媒體流）情況和多filter graph情形都具有可行性。應用根據與適配控制器的交互類型，可以分爲3個不同種類。這些類別包括應用與適配控制器的適配策略協作，應用只與適配控制器在初始時交互，和應用與適配控制器無直接交互。
與適配控制器交互的應用以DLL的形式加載控制器。在創建filter graph後，應用調用一個適配控制器提供的API來建立可能的連接允許適配控制器適配filter graph。應用正確配置那些可以被適配的filters和被用來適配的策略。
對於那些添加與適配控制器的交互的支持是不可行的應用，可以添加以初始適配控制的形式的小限度級別的支持。這種情況下，應用只需要控制應用爲每個filter graph創建的適配控制器的指針。適配控制器解析graph來獲取各種接口和以對應用透明的方式與之交互。
最後，對於那些需要適配，但不能直接修改的應用，可以通過添加一個適配代理filter到應用程序的filter graph中來實現。這種技術可以同DirectShow中的以文件形式存儲filter graph以備後用的能力一起使用。代理filter無需知道應用的信息就可直接添加到filter graph中。當這個filter graph被初始後，代理filter代表適配控制器貫穿整個filter graph，分發來自其它filters接口和質量消息到適配控制器。
爲了做成一個最多有效的利用DirectShow RTP 架構的應用，我們的適配控制器支持所有這三種應用交互。
3．3 控制filters引起適配
這裏探討兩種適配控制filter操作方式。其中之一，不直接干涉的適配控制器；相反沿着適合的filter graph逆流向上傳輸質量消息。適配控制器不必考慮filters和它們的各自的控制方法。然而，我們發現許多filters（像普通的DirectShow 視頻採集filter和一般的codecs）不具有處理質量消息的能力。其它的fitlers對質量消息做出的反應也不是很好，比如MPEG解碼filter，在接收到一個爆發消息後會丟棄所有的P和B幀。爲DirectShow RTP創建的適配控制器可以在缺少直接利用filters的輸出的方式的情況下簡單的發送質量消息。然而，這種方式只是在缺少好的控制方式時最後一個辦法，因爲適配控制器無法知曉質量消息的回饋。
許多filters提供允許適配控制器直接控制它們輸出的接口。爲了利用這種能力，適配控制利用filters上某些接口來實現適配行爲。直接控制每個允許適配的filter的輸出，可以選擇哪個filter它想適配，還有適配的程度。這種方式允許適配控制器以比前一種更優美和精確的控制方式適配，那種適配依靠逆流發送一條質量信息，希望某個filter如所期望的那樣做出反應。
創建的適配控制引擎提供對兩種適配類型的支持。這一引擎爲處於一個單獨組件一個進程中所有多媒體流集中適配決策。這樣產生比默認DirectShow行爲更有效的適配能力，那只是爲每個filter graph流在不協調時做出適配決策。在下一章節我們討論兩種適配機制，基於源的適配控制和通過分層廣播的接收驅動的控制。這篇論文講述了這些適配機制是如何在我們的基於組件的架構執行，還有這些機制是如何被用來獲得網絡和主機的適配。
4．?源適配控制
在適配源碼流控制（ASRC）中，發送者根據網絡資源的變化改變filter的採集幀率和壓縮設置等參數來響應。在我們的實踐中，我們拓展了ASRC，讓也也可以適配檢測到的本地可用資源的變化。因爲DirectShow提供的許多組件缺乏對適配的較好支持，創建新的滿足我們需求的組件是必要的。而且，創建一個能夠操控每個組件接口，以至執行ASRC的適配控制器是必要的。
4．1 視頻採集filter控制
爲了支持適配，視頻採集filter必須允許諸如採集幀率等參數和分辨率在不工作時可調。視頻採集filter也必鬚生成含有足夠精確可被渲染filter用來生成質量消息的時間戳的media samples。最後，它需要應答來自下游filters的質量消息。
如當前所執行的，改變採集filter中視頻採集的幀率或分辨率，需要停止採集，改變採集參數，重新啓動採集。當改變採集分辨率時，重啓filter時會有一個可覺察的停頓，在一個高速CPU比如P2-200 Pro處理器上視頻流中幀率的變化很難被覺察。這一在視頻採集過程中的特性告訴我們當需要適配時，通過改變幀率而不是分辨率來調整適配策略。改變採集頻率對DirectShow的時間戳影響顯著。DirectShow media sample的時間戳是基於採集驅動設置的視頻幀中消逝時間值。
Sample start time = Graph start time + Elapsed frame time in video frame
渲染filters根據sample時間戳來確定media samples是否準時到達。當視頻採集重啓，視頻幀中的時間戳值復位爲0。合成的DirectShow 時間戳看來比渲染filter還要老。
據觀察，幾分鐘後，視頻渲染filters顯示samples已延遲，儘管系統負載很低。會有這種問題出現是因爲視頻採集驅動產生的時間戳逐漸的落後wall時鐘時間。視頻採集filter從每個視頻幀頭生成這些時間戳，它們是基於採集設備的時鐘源進行賦值的。這種時鐘源採用不合適的分辨率和不精確特徵引起了和用於視頻渲染比較的時鐘之間潛在的不一致，導致sample 緩慢這種錯誤跡象。
爲解決這些問題，我們已經修改採集filter，讓它使用DirectShow 參考時鐘（它是基於更精確的wall時鐘源）來生成時間戳，而不是根據視頻幀頭找到的值。這樣排除了重啓和延遲問題，等同於下面的sample的起始時間戳賦值：
Sample start time = Graph start time + Elapsed wall clock time
除了需要高精確度的時鐘用於時間戳生成，還發現採集filter的緩衝管理策略對質量管理至關重要。一旦這個filter用完緩衝，它會拋棄最老的緩衝並把新的視頻幀放置於緩存鏈表頭。這意味着渲染filter將獲取最新的視頻幀而不是那些舊的，無效的緩衝。這使渲染者認爲所有的samples都被準時發送，意味着低CPU負載，沒必要適配或發送質量消息。一種解決方法是當採集filter用光緩衝後直接採取正確行動而不是依賴於來自下游的質量消息指令來採取行動。如果據此決定丟棄新幀，允許渲染器檢測接收到的sample將爲時已晚。
爲允許視頻採集filter在視頻控制器缺位的前提下適配，我們修改了採集filter的質量消息提醒功能讓它處理這些消息而不是忽略它們。一個下游filter（比如視頻渲染）通過質量消息調用這一功能，表示改變sample的發送率是必須的。迴應質量消息視頻採集的改變是在一個獨立線程中實現的，避免在呼叫線程環境做過多處理工作。這樣操作是必要的，避免因渲染錯誤檢測進一步引起的延遲，那樣有可能會發生渲染者線程被迫代表源filter做過多處理。
4．2 編解碼對適配的支持
Filter graph 中的編解碼是處理器資源的主要消耗者，因此它成爲適配的首選。我們採用的視頻的編解碼提供了一個控制輸出碼流和視頻質量的接口。適配控制器採用這個接口來影響CPU和網絡帶寬的佔用。我們發現這些接口對我們創建適配控制器的意圖非常有用，它能夠直接與單個filter交互。
4．3 RTP源和渲染filter適配
允許根據網絡和主機條件適配，需要RTP渲染filter的改變，它的任務是網絡傳輸RTP流和監控RTCP報告。這個filter必鬚生成能夠反應它通過RTCP接收器接收渲染流主機的報告的回饋的消息。
一個完成這項任務的方法是允許RTP渲染filter 解析RTCP接收器報告。這種解析將包含反映DirectShow 質量消息部分值的丟失比例的RTCP包的變化。這種方法的缺點是這樣限制了改變RTCP包解析和執行各種適配算法的能力。因而，爲了添加對基於源網絡適配的支持，發送RTCP包到網絡適配器同樣也是必要的。一個適配控制器能夠通過RTP渲染filter支持的一個普通接口截取原始RTCP消息。
爲允許發送方主機適配，RTP渲染filter需要生成能夠反映本地資源狀態，比如CPU這樣的質量消息。這一任務可通過RTP render filter繼承DirectShow 視頻渲染基礎類輕鬆實現。這個基礎類支持音視頻流質量消息的生成。
4．4 網絡適配控制
基於網絡的發送適配，對當呼叫發送時可用網絡帶寬未明時的點對點會議最爲有益。多播會議也可以使用發送適配方式，但這是假定主機應用很高的網絡帶寬。因而當採用多播，ASRC的最佳使用是在可用網絡能力比較同質的局域網絡會議。在這種環境下，根據發送問題減少發送帶寬這種輕量形式的適配方式，比接收驅動層多播方式（RLM）更會產生預期的效果。
網絡適配控制採用的算法與Busse et al描述的類似。適配控制器允許應用設定丟失閾值和最低，最高帶寬。我們擴展了ASRC概念，添加了設置單個應用中視頻流之間的優先級的能力。典型的，這包含爲希望減少高優先級流的可見丟失，適配低優先級流。
在我們基於數據源網絡適配的執行中，由以下三步組成。就是RTCP分析，網絡狀態預測和帶寬調整。
一旦接收到某個發送方的一條新的RTCP報告，這份新報告被用來校正最初發送RTCP報告接收者丟失的數據包。我們在低通filter中使用a（RTCP最近丟失報告的權重）=0.3 來計算平滑包丟失。每個接收者都在它們展現的參與過程中得以維護。RTCP Bye消息被用來從活動接受者列表中刪除接收者。因爲這個消息的丟失將導致用來調整決策的不準確。我們計劃給每個接收者添加時間戳，來記錄和當RTCP包在一個合理的時間內沒有到達時驅逐接收者。
基於每個接收者平滑包的丟失，可分爲堵塞，加載和卸載幾個狀態。每個狀態維護幾個接收者，當每個接收者從一個狀態變遷到另一狀態，當前一狀態的接收者減少，新狀態的接受者相應增加。平滑包丟失率超過4％的被視爲堵塞（congested），低於2%的視爲卸載（unloaded），介於二者之間的被視爲加載（loaded）。
根據每個狀態接受者的數目，來決定降低、提高或保持目前的比特流。如果超過10%的接收者都處於堵塞狀態，我們降低當前網絡的比特流使用目標。如果沒出現這種情況不過超過10％的接收者處於加載狀態（loaded）,我們持續維持目前的比特流。最後，如果不處於這兩個條件，我們提高網絡的比特流預期。
發送者使用加法提高和乘法降低的算法來調整它們發送數據的比特流。調整碼流有兩步任務，就如我們發現編解碼時偶爾會偏離目標比特流，如果幀運動會引起編解碼器劇烈超出設定碼流。在這個情況下我們提高採集幀率來達到預期的碼流。我們計劃加強網絡源適配控制來允許用戶獲取碼流和幀率調整的折中。
4．5 主機適配控制
主機適配通過graph中的filter提供的控制接口來初始適配，響應CPU負載變化。這一部分討論了主機適配控制器如何爲發送數據的NetMM應用提供適配。
圖2中，我們展示了一個典型的傳輸視頻流的filter graph，包含一個視頻採集fiter,一個視頻編解碼filter，一個RTP SPH，和一個RTP渲染filter。爲了爲這個filter graph添加適配功能，主機適配控制器配置RTP 渲染filter來分發質量消息至適配控制器而不是逆流發送。分發的質量消息中的比例字段值指定了碼流需要改變的程度。這些質量消息被轉換爲媒體參數可被用來操控視頻採集和編解碼。這些參數包括編解碼流，數據採集比特率，和數據採集方案。改變採集率和方案對CPU和網絡帶寬耗用有顯著影響，但改變編解碼比特率對CPU消耗影響甚微。綜合這些提供的參數，用於適配過程中用戶參數估計。比如，我們執行的一條政策包含特殊改變的路徑，描述如下：
如果編解碼率超出最低值，減少到最低值。
如果解碼率已處於最低值，幀率超出最低值，降低幀率。
如果幀率早已被降到最低值，降低幀品質。
Graph 運行期間改變幀率和比特率非常容易。然而，改變品質是複雜的，因爲它改變了用於協商filter連接的DirectShow中的media type。Media types在filters連接組成filter graph時會被協商，然後就確定下來。當DirectShow 不允許media types在運行狀態中被改變，許多filter很難能夠很快滿足這些變化。對於這些filters，有必要採用其它方法來動態改變media type。
H.263和H.261編解碼filters屬於這類不允許動態改變的filter。除了這些filters，標準視頻渲染filters不自動根據media type的改變調整顯示大小。爲解決網絡視頻源初始方法的變化，有必要編寫一個視頻分割器連接一對解碼器和視頻渲染。分割器根據它們的方法路由media samples，這樣這些分發數據流方案的改變對編解碼器和渲染器是不可見的。
當media type發生改變，應用必須被通知，這樣它可以採用合適的視頻渲染filter顯示輸出。因而，對於某些形式的適配（特別是那些導致用戶接口改變的），一個應用能夠感知適配是很必要的。
??
? 5．?採用層多播的接收驅動適配
我們執行的接收控制依賴於接收驅動層多播（RLM）來取得適配。這種適配類型的機制需要每個壓縮層發送到不同的多播IP地址（或單播地址和端口）。在RLM中，根據網絡條件比如可用帶寬和檢測到的損失，添加或丟棄層。我們接收適配也採用RLM來適配主機CPU負載，被處理的各層對處理器負載和總線帶寬等系統資源有直接的影響。
爲支持RLM，有必要創建新的組件，修改現存的DirectShow組件。我們使用c++類結構機制創建一套支持採用RLM實現網絡和主機適配的適配控制器。在這一章節，我們引入該版本的適配控制器和DirectShow需要的其它改變，添加基於組件架構對RLM接收適配的支持。
DirectShow RTP 收發負載調度器需要具有單個流的接收壓縮數據，處理後用於回放或網絡傳輸的能力。爲支持層壓縮，我們需要把包含各層的單個流分成多個獨立流，每個包含一個用來通過獨立網絡連接傳輸的獨立層。同樣必要的是能夠把多層合成爲一個單一的視頻流，分發給解碼器。爲了提供這種功能，我們添加了一個叫層負載調度器（LPH）的新類型的filter到DirectShow RTP。 LPH 是爲每個支持層次壓縮負載類型特地編寫的。LPH filters有兩個，Send LPH filters和Receive LPH filters。
SLPH filters執行當使用層多播時把每個視頻幀賦值到對應的流中的策略。這些filters接收來自codec的輸入，它生成一個包括來自流中所有層的幀的流。這些SLPH filter生成的流包含一些視頻幀然後在RTP SPH filters中打包。無需改變RTP SPH filters來實現，因爲每層只包含需求流的特定負載類型的合法幀。這些包會被RTP Render filter通過獨立的多播流傳輸。
在層多播中每個流的接收由RTP Source filter來完成，它無需改變就可支持此項功能。一旦接收，每個流都通過 RTP Demux filter分發到RTP RPH filter。每個RPH filter把一個流的包彙編爲合適media type 的幀。這些幀隨後分發到RLPH filter，它負責重新排序組合這些來自每層的幀到一個合理media type的統一流中，然後分發到codec中解碼和渲染。
5．1 Poorman Codec
當我們開始工作，我們對分級codecs諸如 H。263+或Indeo 5.0接觸不多。因而，我們決定實現一個簡單的SLPH（poorman 編碼）和RLPH（poorman 解碼）允許採用標準codec臨時的視頻縮放。Poorman壓縮器通過輸出Pins多路輸出視頻幀，poorman 解壓器把這些幀整合爲一個流。Poorman 壓縮器採用了（weighted round-robin interleaving algorithm）分配幀到各個pin。這種簡單的算法通過避免幀間依賴成爲可能，我們可以通過強迫視頻codec只生成關鍵幀來實現。明確的但不是優化的針對層視頻的解決辦法，我們發現這是很有效的進行多級適配研究和在缺少真正分級編碼條件下證明非常有用的工具。圖7和8顯示了採用poorman 編碼的RLM在filter graph中的實現。
在採用（weighted round-robin ）多播流算法的多路輸出視頻幀過程中，保持時間戳信息是非常重要的。確保接收者重組這些流爲按時間序列的單個視頻流，這個信息是必要的。
在我們執行中，RTP SPH filter確保相關各層RTP時間戳之間正確性，基於這樣的事實，它們繼承RTP時間戳，每個來自DirectShow被打包的幀有關的時間戳。在接收方，RPH filter 把RTP時間戳放置於DirectShow samples，允許在poorman解碼前同步和排列幀。一旦幀被poorman 解碼器排序和同步，有必要爲每個幀打上時間戳。這些信息對視頻渲染filter根據需要適配的主機或網絡條件正確生成質量消息來說是必要的。我們決定時間戳需根據如下公式賦值：
time offset = FIRST_RTP_TIME – STAT_STREAM_TIME
sample_start_time = CURRENT_RTP_TIME +Time_offset
Interval_time = PREVIOUS_RTP_TIME – CURRENT_RTP_TIME
考慮到 FIRST_RTP_TIME 是通過根據時間戳排列第一組到達的包獲取最小的結果值。必須在排序以前（因而獲取FIRST_RTP_TIME）接收到包的數目是可編程控制的。這種機制對於消除出現在網絡和發送接收主機操作系統到達包的抖動和重排的影響，是必要的。
5．2 H263+/Indeo 層負載操作者
分層負載操作者在初始設計過程集中設計了二個等級視頻壓縮，Indeo和H.263+。這兩個視頻壓縮器有不同的分層結構，致使被每個LPH執行的功能有點不同。Indeo 是基於波段的, 多波段視頻出現在每個壓縮視頻片段中。每個波段能都在一個單獨的流中傳輸和所有波段能夠通過一個流發送。爲區分一個流中的波段，使用了一種叫波段抽取的工具。在我們的實現中，SLPH起到了一個波段抽取的角色，接收來自壓縮器的複合幀，分割成波段數據，傳遞到RTP SPH filters打包，通過RTP流傳輸。波段被RLPH重新組合爲一個單獨的視頻幀，提供給解碼器。Indeo需要一個基層，可以被單獨接收，如果其它層需要處理也必須接收。其它層以連續的方式互相依賴，就是說，層1依賴於層0（基礎層），層2依賴於層1，等等。
H．263的分層結構比Indeo更爲複雜，有三個不同基本類型的層，或可以說是被引入的收縮性【18】。這三個可量測的類型包括時間的，空間的和SNR（噪音率信號）。時間可量測性，包含B（雙向預測）幀，提供一個較大的幀率。空間可量測性是指圖片大小的變化，比如從QCIF（176×144）到CIF（352×288）。SNR可量測性是爲了校正在壓縮過程中編碼錯誤對數據封裝，相較原始的未壓縮版本改進圖片。這三種可伸縮類型可以被結合在一起提供許多不同層的視頻。然而，每個視頻幀都是隔離的，只屬於一個層。兩個或更多的這些幀可以被編碼器組合來創建一個可用來顯示的圖片。不像Indeo, H.263+的分層沒有以一個有序的方式排列。當這兒需要一個基礎層，其它加強層可能依靠其它任何分層結構中在它下面的層。分層負載處理器被配置來知曉各層的依賴並根據這些信息決定丟棄還是添加層。
除了H.263+支持的複雜的層關係，重組層時需要特定序列的幀。這種序列，在H.263 ITU 介紹中有詳盡描述，需要提供B幀給解碼器，在基於它的雙向預測幀以後。比如，在連續的3幀中，幀2是來自幀1和幀3的雙向預測，順序將爲1，3，2。 這也是編碼器生成幀的序列，這致使RLPH接收到的幀以不同於原始採樣或採集順序。因爲RTP的說明中需要RTP時間戳基於即時的取樣，負載操作者必須爲幀重建一個即時取樣，在傳輸數據時生成RTP時間戳。同樣的，當接收方重排幀後，RTP時間戳不能被用來排列它們，分發給解碼器。重建時間戳不是一個難題，儘管它導致一個對即時取樣值的估算。然而，沒有RTP時間戳的協助來爲解碼器排列幀是一個非常難以解決的問題，兩個參考幀之間的B幀數目可以是變化的。我們通過與其它幀分開單獨排列B幀，把參考幀作爲用來預測B幀，來確定原始編碼序列的分割符來解決這個問題。因爲在任何“預測窗口”中預期的B幀數目是變化的，我們添加了一個可配置的緩衝超時時段。在此段時間，接收分層負載控制器將會在那個窗口的B幀提供給解碼器以前等待所有進入的B幀。我們也可以基於在超時後接收的B幀數目，動態適配這一超時時段。
適配管理器使用LPH filter 來動態的添加和撤銷發送或接收方的層。通過執行大部分很複雜的SLPH 和RLPH filter 特定的 RLM 和重用這些filters，能夠比較容易添加 RLM對我們適配引擎的支持。在這種單架構而不是像DirectShow這樣的基於組件的架構構建這種功能將會顯著增加明顯的複雜度。
5．3 RLM在網絡適配控制中的執行
我們的網絡適配控制組件實現了對RLM適配機制的支持。爲了簡化實現，RLM適配控制器提供一個有關適配策略的可變參數，可以在應用中設置。參數包括丟失閾值（在離開一個層前丟失的總量）和 離/合TTL消息（用來限制發送離/合消息到網絡子網）。除了這些參數，所有RLM的相關定時器可被應用使用。
RLM算法以包丟失作爲確定增添或去除層的依據。因爲這一信息目前保存在RTP SPH filter中，我們需要一個廣播到網絡適配控制器的方法。爲了這麼做，我們修改了RTP RPH filter，添加了一個用來分發丟包信息到適配控制器的回調接口。網絡適配控制器接收到來自每個RTP RPH丟包信息，跨層集合到一起。
我們的網絡適配控制的方式可依兩種操作模式實現。第一種，直接對不利網絡條件進行補償。這種行動可能包含命令RTP 源filter 添加/加入一個多播層和指示作爲結果行爲的RLPH，讓他知道是否需要等待來自一個特定層的數據。在另一種方式中，適配控制可在應用中使用。應用基於網絡適配控制器提供的信息執行適配決策（比如，操作RTP源filter 和RLPH）。
5．4 使用主機適配控制的主機接收適配
主機適配控制允許視頻流的接收者來選擇最適合主機可用源的一組層。主機適配控制的初始要麼通過應用執行（在適配感知應用中），要麼通過適配代理filter調用。主機適配控制器把自己設爲發送自視頻渲染filter的DirectShow 質量消息的接收器。當消息顯示爲一個洪流，控制器丟棄用於多播組RTP源filter提供的離合接口，當接收到飢渴消息時添加層。這些操作在一個單獨線程中實現，爲了避免與數據流衝突。
6．?體驗應用和測試
爲了測試我們的軟件架構，我們創建了一系列的適配應用。這些應用包含一個允許在HTML網頁顯示RTP流的ActiveX控件和一個普通的叫xNetMM的測試應用，它提供了類似VIC和VAT的功能。ActiveX控件的屬性可以通過各種語言在HTML頁中設置。
使用DirectShow RTP和軟件編碼/解碼，我們可以接收和解碼三個同步的H.263CIF視頻流，每個流20幀/秒，和一個音頻流，總共帶寬可超過3Mbits/s，在一個P2-266處理器的主機上。使用一個特定允許filters 直接寫視頻硬件存儲的DirectShow 視頻渲染filter，我們能夠提供在50%的CPU佔用率下，全屏高質量的Indeo視頻和音頻（MPEG2 SDTV 5Mbps質量）。
我們使用這些應用，如圖11所示測試平臺，來測試各種情景。Modem 的存在允許我們在廣闊的可用主機帶寬範圍中測試ASRC和RLM功能。處理使用modem來創造廣闊範圍的客戶帶寬，我們已經爲框架編寫了用於模擬網絡丟失的拋棄RTP包的組件。這些組件的行爲全可以通過參數配置，所以我們能夠詳細控制報丟失的分佈。最後，在我們測試環境的主機的處理器能力跨度較大，從p90到p2-300。
爲了證明多流應用中的主機適配，我們使用activeX控件的多實例在Web頁中的創建了一個視頻會議應用。會議中的視頻流使用允許接收者適配的層視頻。會議的參與者可以聽和看到對方，觀看視頻窗口的視頻剪輯。電影以幀率20Fps和44.1HZ indeo 音頻 播放。隨着參與者的增加，各視頻和音頻流的品質下降。視頻會跳動，音頻會出現噪音。當接收流和本地輸出流適配後，接收流會降爲很低的視頻層（2FPS），發送流會降到 5FPS。適配後，音視頻的質量會回到可接收的水平。這一情景包含明顯的用戶交互。在下一章節，我們着重說明如何最小化這些用戶輸入。
7．?未來工作
我們計劃拓展我們的適配架構，包含對多源和應用適配的支持。我們也趨向於改進我們的設計來允許用戶驅動的策略和優先級設置。擴展適配到廣闊的系統而不是對每個不利條件做出反映的應用，將超出目前的執行進一步加強用戶的體驗。通過考慮用戶在如此係統級的適配，其它的對適配控制器不可用的信息也可能被使用。我們相信這樣結合系統級的適配和使用用戶的選擇將允許我們到達一個最佳的適配水平。
7．1跨越多資源適配
用來監控性能的度量，適配的算法，和控制適配的機制是資源明確的。然而，我們相信用於爲特定資源的適配控制交互的接口可以被生成。提供一套標準的接口，應用可以實例化並與特定適配控制器交互，而不需要獲取一個很高水品的有關適配的應用知識。
爲允許應用跨多資源適配，我們計劃使用一套分級適配控制組織來擴展我們的體系。在這種安排類型中，應用與一個單根適配控制器交互，它反過來代表應用管理其它適配控制器。例如，爲適配主機和網絡資源，應用可以實例一個複合的適配控制器，它使用一個主機適配控制器和一個網絡適配控制器。當適配控制器是這個結構樹的一片葉子，它將不直接控制。而是諮詢他的父母，當條件允許時是否需要適配。 樹根將根據它所有孩子的當前狀態採取行動。我們相信這種分級方式將提供一套評估當前顯示質量和操控更廣範圍應用可用資源的方法，可以顯著提高用戶體驗的品質。
7．2 用戶特定適配策略
進一步工作的一個重要領域就是允許用戶設定參數，比如相關流和應用的優先級。用戶也應該能夠設置適配策略，也許根據應用和適配控制器的暗示。允許用戶遵照哪個流時最重要的輸入對達到最可能好的用戶體驗是關鍵的，如這些信息（用戶對體育頻道還是財經頻道趨向於更高優先級）是通過其它方式難以獲取的。用戶的喜好對於怎樣適配同樣是非常重要的，如一個用戶喜歡高的幀率，而同時另一各也許喜歡高的品質。最終，適配控制器提供給用戶的線索，什麼形式的適配對用戶來說更趨向於成功執行，將對幫助用戶確定適配策略有用。
爲了說明這些問題，我們計劃創建兩個實體，一個策略工具和一個策略控制器。策略工具提供一個圖形用戶接口，允許用戶選擇應用和指定策略。這些策略可以對單個應用或系統範圍都有效。我們想象一個策略工具，這個允許這些指定策略優先於應用運行，可以在運行期間修改。最後，這個策略工具將包含一系列默認的策略用於沒有用戶輸入的情況。
一旦一組策略已被設定（只要策略被動態改變），策略工具將加載它們到系統策略控制器。策略控制器負責與每個適配控制器和每個應用交互，來執行策略工具指定的策略。策略控制器還需要負責監控每個策略控制器的狀態，發送反饋到策略工具，它也許會同用戶交互，以至於更新策略規範。
8．?總結
以DirectShow爲基礎，我們已爲RTP流開發了一套叫做DirectShow RTP的框架。通過充分利用DirectShow的靈活性，和內在的可擴展性設計DirectShow RTP框架，我們實現了幾種網絡適配方法，並探究了新的主機適配方向。拓展流功能以自動適配網絡和主機條件，使多媒體展現質量最大化，而依舊使用標準的編解碼和協議變得可能。基於組件的DirectShow RTP 框架讓適配領域的工作變的簡單，因爲這一框架提高了以前創建組件的重用和可維護性。
DirectShow RTP框架擴充的適配能力被採用已在系統存在的原有質量監控機制實現。這樣使適配能力很容易使用這套框架就可添加到NetMM應用中去，無需或很小改變。這些對像DirectShow RTP基於組件框架附加的能力，導致了NetMM應用該框架後有了戲劇性的和直接的改進。這證明了適配能力的價值，和允許簡單快速的利用框架的價值。
致謝
謝謝微軟公司的Don Ryan 和Mike Clark, Don Newll， Dele Scotto，和許多其它的Intel架構實驗室成員，爲本項目做出貢獻。
DirectShow，Windows NT，ActiveX是微軟公司的註冊商標。
Pentium 和Pentium II是Intel公司的註冊商標