設置(Profile)
一個設置是一個ASF的配置(configuration)的描述數據集合。一個設置必須至少包含一個流的配置設置。
流信息
設置中的流信息包含流的比特率(bit rate)，緩衝窗口和媒體屬性的設置。視頻和音頻的流信息準確描述了文件中的媒體配置，包括壓縮數據使用的編碼和解碼器（如果有的話）。
一個設置也包含很多創建ASF文件時使用的ASF的特性，這包括互斥、媒體優先級、帶寬共享和數據單位擴展。
每次寫文件時必須提供設置。你可以調用IWMWriter::SetProfile指定一個設置。
設置有三種形式，應用程序中設置對象包含的數據，XML文件，或者ASF文件頭。
設置對象
可以用設置管理器創建空設置對象，然後從現有數據載入設置
XML文件
具有PRX擴展名.注意Windows Media 9 Series 中沒有原來的系統設置(system profiles)也不再使用，而作爲這種形式存在。保存自定義設置時必須保存成這種文件。
ASF文件頭
ASF讀者創建一個設置對象，然後從ASF文件頭載入格式信息。但是修改文件頭不會影響文件的內容。可以重新對文件編碼來完成格式的修改。
使用設置編輯器
除了用Windows Media Format SDK之外，還可以用Windows Media Encoder 9 Series中包含的設置編輯器創建設置。在應用程序中使用IWMProfileManager::LoadProfileByData載入預定義的設置。但是，啓用“視頻大小：和輸入相同”這個選項將設置視頻的大小爲0；Windows Media Encoder 9 Series可以識別並且處理這種情況，但是Windows Media Format SDK的寫入對象不會自動處理，所以應用程序必須並且處理這種情況.
下面是一個XML格式的配置
<profile version="589824" storageformat="1" name="ICW" description="ICW Stream">
// 73647561-0000-0010-8000-00AA00389B71 'auds' == WMMEDIATYPE_Audio
<streamconfig majortype="{73647561-0000-0010-8000-00AA00389B71}" streamnumber="1" streamname="Audio Stream" inputname="Audio804" bitrate="1411200" bufferwindow="-1" reliabletransport="0" decodercomplexity="" rfc1766langid="zh-cn">
// 00000001-0000-0010-8000-00AA00389B71 WMMEDIASUBTYPE_PCM
<wmmediatype subtype="{00000001-0000-0010-8000-00AA00389B71}" bfixedsizesamples="1" btemporalcompression="0" lsamplesize="4">
<waveformatex wFormatTag="1" nChannels="2" nSamplesPerSec="44100" nAvgBytesPerSec="176400" nBlockAlign="4" wBitsPerSample="16" />
</wmmediatype>
</streamconfig>
// 73647561-0000-0010-8000-00AA00389B71 'auds' == WMMEDIATYPE_Audio
<streamconfig majortype="{73646976-0000-0010-8000-00AA00389B71}" streamnumber="2" streamname="Video Stream" inputname="Video804" bitrate="4000" bufferwindow="1000" reliabletransport="0" decodercomplexity="AU" rfc1766langid="zh-cn">
<videomediaprops maxkeyframespacing="80000000" quality="35" />
// 56555949-0000-0010-8000-00AA00389B71 'YV12' == MEDIASUBTYPE_IYUV
<wmmediatype subtype="{56555949-0000-0010-8000-00AA00389B71}" bfixedsizesamples="1" btemporalcompression="0" lsamplesize="0">
<videoinfoheader dwbitrate="4000" dwbiterrorrate="0" avgtimeperframe="1000000">
<rcsource left="0" top="0" right="0" bottom="0" />
<rctarget left="0" top="0" right="0" bottom="0" />
<bitmapinfoheader biwidth="0" biheight="0" biplanes="1" bibitcount="12" bicompression="IYUV" bisizeimage="0" bixpelspermeter="0" biypelspermeter="0" biclrused="0" biclrimportant="0" />
</videoinfoheader>
</wmmediatype>
</streamconfig>
// 73636d64-0000-0010-8000-00AA00389B71 'scmd' == WMMEDIATYPE_Script
<streamconfig majortype="{73636D64-0000-0010-8000-00AA00389B71}" streamnumber="3" streamname="Script Stream" inputname="Script804" bitrate="2560" bufferwindow="-1" reliabletransport="0" decodercomplexity="" rfc1766langid="zh-cn">
<wmmediatype subtype="{00000000-0000-0000-0000-000000000000}" bfixedsizesamples="0" btemporalcompression="0" lsamplesize="0">
// 82f38a70-c29f-11d1-97ad-00a0c95ea850 WMSCRIPTTYPE_TwoStrings
<WMSCRIPTFORMAT scripttype="{82F38A70-C29F-11D1-97AD-00A0C95EA850}" />
</wmmediatype>
</streamconfig>
</profile>
媒體採樣(Media Sample)
媒體採樣，或者採樣，是一塊數字媒體數據。採樣是Windows Media Format SDK可以讀寫的數據的最小單位。採樣內容由採樣相關的媒體類型指出。對於視頻，每個採樣表示一個楨，每個單獨採樣中包含的數據量由創建ASF時指定的設置設置。
採樣可以包含未壓縮的數據，或者壓縮過的數據，這時被稱爲流採樣。創建ASF時，採樣被傳遞給寫入對象，寫入對象使用相關的編碼器壓縮數據，並且寫入ASF文件的數據段。播放時，讀出對象讀出壓縮的數據，解壓數據，並且提供未壓縮格式的數據。
採樣被封裝在Windows Media Format SDK的自動分配的緩衝區對象中。需要的時候，你也可以自己分配緩衝區對象，使用它的讀寫特性。
這裏的採樣並非音頻採樣。通常，音頻採樣質量用每秒錄製的採樣數據數量表示，例如CD質量是44,100採樣/秒，或者44.1 kHz。
輸入，流和輸出
輸入對象是你用於寫入文件的任何數字媒體流，必須是可以支持的格式。支持很多標準RGB和YUV作爲視頻輸入格式，PCM作爲音頻輸入格式。如果編碼器不支持某種輸入格式，那麼寫入對象會初始化一個輔助對象，轉換輸入流到可以支持的格式，例如調整色深轉換、縮放，調整聲音質量、採樣率和頻道數目。某些情況下，壓縮格式的食品和音頻可用於輸入。輸入也可以是其他格式，例如文字，腳本命令，圖像，或者任意文件數據。
輸出是讀取對象傳遞給應用程序，提供用戶體驗的數據。一個輸出等同於一個流。如果你使用互斥屬性，那麼所有互斥數據共享一個輸出。
一個流是一個ASF文件中包含的數據。一個流的生命期中只有一種壓縮設置。一個簡單的ASF具有兩種流：視頻和音頻。更加複雜的ASF文件可以包含兩路音頻和多路視頻。音頻可以有同樣的壓縮設置，但是內容不同，例如不同語言的講解；視頻可以有同樣的內容，但是具有不同的壓縮比例。格式是在設置對象中指定的。
某些輸入可以是壓縮過的，這時讀取對象必須以流編號依次訪問數據，而不是按輸出順序訪問數據。
編號
流具有從1開始的編號，這是在設置中指定的。同時，流具有一個索引以在設置中枚舉流。這兩個數字並不相關，例如輸入1並不一定是編號爲1的流，編號爲1的流並不一定是輸入1，等等。
格式
每種媒體類型的全部信息。每個格式有一個主類型，例如音頻或視頻，並且可能有一個子類型。格式包含依賴於主類型的不同信息。視頻和音頻格式比其他格式需要更多信息。
輸入格式
描述你傳遞給寫入對象的數字媒體類型。如果ASF文件中的流是用編碼器壓縮，那麼編碼器只支持某些輸入格式。使用Windows Media 音頻和視頻編碼器時，可以使用寫入對象枚舉支持的輸入格式。寫到文件時，你有責任選擇一個匹配輸入媒體的輸入格式。
某些格式不必匹配編碼器指明的輸入格式，編碼器可以自行轉換數據到需要的格式。
流格式
ASF文件中的數據保存形式。在設置中描述，可以符合或不符合輸入、輸出格式（例如使用了某種編碼/解碼器）。可能必須獲得編碼/解碼器信息之後，纔可以設置流格式
輸出格式。
描述你傳遞給讀出對象的數字媒體類型。如果ASF文件中的流是用編碼器壓縮，那麼編碼器只支持某些輸出格式。使用Windows Media 音頻和視頻編碼器時，可以使用讀出對象枚舉支持的輸出格式。讀出文件時，你有責任選擇一個匹配輸出媒體的輸出格式。
某些格式不必匹配編碼器指明的輸出格式，編碼器可以自行轉換數據到需要的格式。
比特率(Bit Rate)
每秒傳遞給ASF的數據的數量，以位/秒(bps)或者千位/秒(kbps)爲單位。經常與帶寬混淆，帶寬也以bps或者kbps爲單位。
如果用戶的帶寬小於ASF的比特率,那麼播放可能中斷。通常，帶寬不足會導致跳過某些採樣，或者更多的數據緩衝時間。
每個ASF文件創建時被指定一個比特率，它基於文件中流的數量。不同的流可以有不同的比特率。比特率可以是常數（壓縮的數據可以以基本同樣的速度被傳輸）或者可變（保留壓縮的數據質量，即使可能造成突發數據溢出）。
同一個內容可以被壓縮成多個比特率不同的流，然後你可以配置他們爲互斥的。這個屬性叫多比特率(multiple bit rate), 或者MBR.
元數據
描述ASF文件或者文件內容的信息，位於文件頭。元數據的項稱爲屬性。每一個屬性由名字和值組成。全局常數用於標識屬性，例如ASF文件的標題被保存在 g_wszWMTitle 屬性中。在Windows Media Format SDK 中定義了最常用的內建屬性，但是你也可以定義自己的屬性。由於其他開發者可能和你是用同樣的名字，所以可能造成衝突。
一些全局屬性可以被修改，例如g_wszWMSeekable屬性（文檔是否可以從任意點被讀取）
一些屬性純粹用於信息用途，並且必須被設置，例如g_wszWMAuthor屬性（作者）
屬性可以被應用到整個文件或者單獨的流。
你可以用Windows Media Format SDK編輯MP3文件的元數據，但是必須使用ID3-compliant屬性保留與其他MP3應用程序的兼容性。
媒體時間
自第一個採樣開始的時間計量方式，單位和SDK其他時間的單位一樣，是100納秒。它使得文件中不同的流可以被同步。你寫入的每一個採樣都必須有媒體時間。ASF文件數據段中每一個數據對象都有媒體時間。每一個輸出的數據也都有媒體時間。
緩衝
讀取對象打開流文件時從文件頭的信息決定緩衝區大小。實際比特率是變化的，但是平均值應該是設置中指定的值。
緩衝窗口是以可以緩衝的數據時間長度來衡量的。例如，32Kbps的流，3秒的緩衝窗口，意味着緩衝區大小爲 12,000字節(32000*3/8)。解碼器限制了這個數值，所以緩衝窗口的平均比特率不大於流的比特率。
通常在設置中指定這個值，寫入對象處理剩下的部分。寫入壓縮數據到流時，必須自己確定寫入的速度不會超出這個值
ASF文件中的段
一個ASF文件中的段以對象的方式組織起來。一共有三種頂層對象，必須有的頭對象(Head),數據對象(Data)，以及可選的索引對象(Index)。
每個對象都以全球唯一標誌(GUID)和大小開始。這些數字使得文件讀者可以解析這些信息，並且載入到相應的對象。因爲這些GUID，底層的對象可以以任何順序排列，並且仍然可以被識別。這使得一個不完整的ASF文件仍然可被正確讀取，只要有一個完整的文件頭和至少一個數據對象。某些對象，例如流屬性對象，可能有多個示例。
頭對象包含文件的描述信息，同時是唯一的頂層對象容器。
數據對象以包的格式存儲流數據。數據對象還具有文件ID和包總個數屬性，但是對於流格式，包總個數屬性沒有意義。
每一個數據包包含發送時間和持續時間。這使得讀者可以發現流傳輸的中斷。
數據包的數據被封裝到載荷(payloads)中。一個載荷可以包含一個或者多個媒體對象（media objects），媒體對象的一個例子是視頻流的一個楨。大的媒體對象，例如視頻流的一個關鍵楨，可能被擴展到多個載荷，甚至多個包。爲了跟蹤對象的片斷，每個對象的段具有從0到255的編號。
除了數據之外，載荷也具有以毫秒爲單位的時間戳。
所有的包具有頭對象中指定的統一的大小。當一個包包含的數據少於指定大小時，用數據（"padding" data ）填充不足部分。
索引對象包含時間《-》關鍵楨的配對，以更有效地在文件中定位。因爲它處於文件末尾，實時媒體不能訪問這個對象。
使用回調方法
一些Windows Media Format SDK的接口的方法是異步執行的，很多這樣的方法使用回調方法和應用程序通訊。
使用OnStatus回調
在Windows Media Format SDK中，IWMStatusCallback::OnStatus 被很多對象調用。OnStatus接收SDK操作狀態的變化。每種對象可能有不同的方式連接到IWMStatusCallback。
使用事件進行同步調用
1 使用Platform SDK的API CreateEvent創建一個事件對象
2 實現回調函數，，捕獲事件，並且調用SetEvent函數標記事件對象
3 在應用程序中調用WaitForSingleObject 、監視事件對象。如果你是在爲Windows程序編寫代碼，你必須創建一個消息循環對用戶操作做出相應。
使用上下文參數
Windows Media Format SDK的一些回調函數具有pvContext參數，這個值是你在異步操作啓動時傳遞給對象的。
通常，多個對象使用同一個回調時傳遞對象指針作爲這個參數。
使用設置
設置的主要目的是描述其中的對象，以及對象之間的關係。不管是否使用編碼/解碼器，某些流需要配置纔可以工作。流的配置信息可以用IWMCodecInfo3 接口的方法獲得，但是不要手動配置一個使用了Windows Media編碼/解碼器的流。
創建/編輯設置的步驟
1 創建空設置，或者打開舊設置
2 配置每個流，如果需要的話，使用從編碼/解碼器獲得的數據
3 配置互斥（可選）
4 配置帶寬共享（可選）
5 配置優先級（可選）
設計設置
選擇編碼方式
1-pass Constant Bit Rate (CBR) 直播的唯一選擇。以預定的碼流率編碼，並且質量最低。
2-pass CBR 文件形式的流媒體，長度固定，質量比1-pass Constant Bit Rate (CBR)好
1-pass Variable Bit Rate (VBR) 需要指定質量時使用，本地播放或者下載後播放
2-pass VBR – unconstrained 需要指定帶寬時使用，但是真實帶寬佔用可以偏離指定帶寬，本地播放或者下載後播放
2-pass VBR – constrained 需要指定帶寬時使用，但是真實帶寬佔用不能大於指定帶寬，本地播放或者下載後播放
碼流率
除了數據之外，分包也要佔用一定的帶寬。如果流包含數據單位擴展，那麼這將大大增加流的碼流率。
同時，除了應用程序之外的任何連接都和應用程序共享網絡帶寬，所以不能認爲應用程序可以完全使用客戶的網絡帶寬。
配置流
如果流是視頻/音頻，使用Windows Media編碼/解碼器，那麼你必須使用IWMCodecInfo3的方法從編碼/解碼器獲得流配置對象。
如果流是其他類型，使用IWMProfile::CreateNewStream.創建一個新的流配置對象。
每個流配置都必須設置名字、連接名和流序號（從1到63）。
可能會修改使用Windows Media編碼/解碼器的two-pass VBR 音頻流的VBR設置。視頻流無需修改配置。
根據類型配置其他類型流。所有的這種流需要設置比特率和緩衝窗口。
使用IWMProfile::AddStream. 將流添加到媒體。
大部分設置可以通過IWMMediaProps訪問。這些設置保存在WM_MEDIA_TYPE 結構中。對於音頻和視頻，WM_MEDIA_TYPE結構指針指向媒體特定的更多信息，通常是WAVEFORMATEX 或者WMVIDEOINFOHEADER結構。視頻有第三個結構BITMAPINFOHEADER描述了視頻的楨。
從編碼/解碼器獲得流配置信息
使用Windows Media編碼/解碼器的視頻/音頻流需要從編碼/解碼器獲得流配置信息。儘管你可以自行設置這些配置，從編碼/解碼器獲得流配置信息使得數據是準確的。除非文檔推薦，否則不要修改獲得的流配置信息。
可以從設置管理器的IWMCodecInfo, IWMCodecInfo2, 和IWMCodecInfo3接口獲得信息。
枚舉安裝的編碼/解碼器
編碼/解碼器的編號從0開始，音頻和視頻的編碼/解碼器有獨立的編號。
枚舉編碼/解碼器支持的格式
配置音頻流
不要手動修改獲得的配置的質量設置，而應該用IWMPropertyVault接口修改。
音頻流的緩衝窗口不應該設置得比視頻流的緩衝窗口大，否則會造成播放不同步。通常，音頻流的緩衝窗口是1.5-3秒,視頻流的緩衝窗口是3-5秒。
配置視頻流
除非是RGB24數據，否則大小應該是4的倍數，否則會有非法格式/非法配置等錯誤。
配置屏幕流
和視頻流一樣，但是如果複雜度設置爲0，那麼IWMVideoMediaProps::SetQuality設置的質量會被忽略。
圖像流
包含JPEG形式的圖像數據。
視頻流的定位性能
可以使用IWMVideoMediaProps::SetMaxKeyFrameSpacing設置關鍵楨間隔。增加關鍵楨數目會降低視頻質量。
未壓縮的音視頻格式
不能用於流，必須手動設置帶寬，緩衝窗口應該設爲0
配置其他流
通常，這種流只需要比特率和緩衝窗口和WM_MEDIA_TYPE 中的媒體主類型設置。但是某些類型的流還需要其他設置
腳本流
WM_MEDIA_TYPE的成員formattype 要設置爲WMFORMAT_Script，指明pbFormat成員指向一個WMSCRIPTFORMAT 結構。
只有一種腳本媒體類型，WMSCRIPTTYPE_TwoStrings。
文件傳輸流
每個採樣需要一個數據單位擴展，你需要實現一個數據單位擴展系統。
調用IWMStreamConfig2::AddDataUnitExtension添加數據單位擴展到流。
hr = pStreamConfig2->AddDataUnitExtension(CLSID_WMTPropertyFileName,
-1, NULL, 0);
網頁流
WM_MEDIA_TYPE.majortype WMMEDIATYPE_Filetransfer.
WM_MEDIA_TYPE.subtype WMMEDIASUBTYPE_WebStream.
WM_MEDIA_TYPE.bFixedSizeSamples False.
WM_MEDIA_TYPE.bTemporalCompression True.
WM_MEDIA_TYPE.lSampleSize 0.
WM_MEDIA_TYPE.formattype WMFORMAT_WebStream.
WM_MEDIA_TYPE.pUnk NULL.
WM_MEDIA_TYPE.cbFormat sizeof(WMT_WEBSTREAM_FORMAT).
WM_MEDIA_TYPE.pbFormat 一個配置好的WMT_WEBSTREAM_FORMAT結構的指針.
WMT_WEBSTREAM_FORMAT.cbSampleHeaderFixedData sizeof(WMT_WEBSTREAM_SAMPLE_HEADER).
WMT_WEBSTREAM_FORMAT.wVersion 1.
WMT_WEBSTREAM_FORMAT.wreserved 0.
文本流
媒體類型WMMEDIATYPE_TEXT
計算比特率和緩衝窗口
簡單的辦法是設置爲數據長度/時間.但是圖像和文件流可能突發數據很多,但是有很多空閒時間.緩衝窗口必須設置得足夠大.需要的時候,可以適當增加這些值.
變碼流率流
數據單位擴展
保存/重新使用配置
不要手動更改PRX文件。看起來很小的改變會使得配置無效。
互斥
流優先級
帶寬共享
包大小
寫ASF文件
使用IWMWriter::SetProfile對寫入對象進行設置。但是，設置了之後，對設置對象的修改不會自動反映到寫入對象，除非再次調用IWMWriter::SetProfile。
設置寫入對象會復位全部頭屬性，所以必須在設置之後再修改這些屬性。
輸入
設置對象中的每個連接有一個輸入號。除非配置中有互斥流，否則每個流有一個連接。互斥流共享連接。
寫入流時需要用輸入號來區別每個流，所以必須用連接名字來判斷每個流的輸入號。
枚舉輸入格式
SDK可以對輸入進行預處理來判斷輸入的格式是否支持。
設置輸入格式
找到符合數據的輸入格式之後，可以調用IWMWriter::SetInputProps讓它可以被寫入對象使用。對於視頻流，必須設置楨的大小。
其他類型的流和預壓縮流
其他類型的流無需設置。
預壓縮流需要設置輸入格式爲NULL。這個設置必須在BeginWriting之前完成。同時需要調用IWMHeaderInfo3::AddCodecInfo設置預壓縮流的格式。
BeginWriting之前,還可以用IWMWriterAdvanced2::SetInputSetting設置和流無關的設置。
元數據
使用寫入對象的IWMHeaderInfo 或者IWMHeaderInfo2接口訪問元數據。必須在IWMWriter::BeginWriting之前完成元數據的寫入。
注意，如果創建了寫入對象而沒有釋放，然後再創建寫入對象，一些元數據會被複制到新的對象中。
寫入採樣
寫入採樣之前要調用IWMWriter::BeginWriting.
1 用IWMWriter::AllocateSample分配緩衝區，並且獲得其INSSBuffer接口
2 用INSSBuffer::GetBuffer獲得緩衝區地址
3 複製數據到緩衝區中
4 用INSSBuffer::SetLength設置複製的數據長度
5 把緩衝區、輸入編號和媒體時間傳遞給IWMWriter::WriteSample方法。音頻數據持續時間是一樣的，所以可以簡單地在現有時間上加上一個常數。對於視頻，需要根據楨率計算媒體時間。
WriteSample是異步調用，在下一次WriteSample調用之前可能沒有結束。所以要在每次寫入採樣之前調用AllocateSample獲取緩衝區對象。
所有采樣寫完之後，調用IWMWriter::EndWriting完成寫入操作。
流數據應該幾乎同時結束，否則某些流數據可能丟失。
寫入壓縮採樣
使用IWMWriterAdvanced::WriteStreamSample 替代IWMWriter::WriteSample。
寫入圖像採樣
必須用IWMWriterAdvanced2::SetInputSetting設置圖像質量g_wszJPEGCompressionQuality，範圍從1到100。圖像採樣壓縮比通常很大，所以要使用嘗試的方法設置緩衝窗口大小。
強制關鍵楨
使用INSSBuffer3::SetProperty設置緩衝區對象的WM_SampleExtensionGUID_OutputCleanPoint爲TRUE。
讀取
輸出
默認方式下，每個採樣有一個輸出編號，對應於ASF文件中的一個流。讀取者打開ASF文件時，爲每個流賦予一個編號。通常對每個流都有一個輸出。但是對於互斥的流，每一組互斥流只有一個輸出。多碼流率文件的情況，或者程序自行選擇流的情況下，輸出對應的流是由讀取者決定的。
因爲流的連接名字並未保留在文件中，讀取者爲每個流創建一個簡單的連接名字，就是輸出號的字符形式,例如"1","2","3"等等。
每個輸出有由編碼器決定的一個或者多個支持的輸出格式，打開時默認是從媒體的子類型獲得默認輸出格式。
使用異步方式讀取ASF文件
1 實現IWMReaderCallback，處理讀取者的消息，OnStatus處理狀態消息，OnSample處理解壓過的數據
2 讓讀取者打開一個文件，爲每個流設置一個輸出號
3 從讀取者獲得輸出格式信息
4 讓讀取者開始播放，採樣在指定的媒體時間傳遞給OnSample，直到讀取者被停止或者達到文件末尾
5 數據到達時，程序負責播放採樣
6 播放結束之後，讓讀取者關閉。
如果採樣是預壓縮的，那麼需要實現的是IWMReaderCallbackAdvanced::OnStreamSample 。IWMReaderCallbackAdvanced::OnStreamSample幾乎和OnSample完全一樣，除了它基於流編號而不是輸出編號之外。在開始回放之前，獲得讀取者對象的IWMReaderAdvanced接口，爲每個預壓縮流流調用IWMReaderAdvanced::SetReceiveStreamSamples.
定位
一個ASF文件必須被適當的配置纔可以定位到指定時間。默認情況下只有音頻的文件可以定位，但是包含視頻的文件需要有索引纔可以。如果你不確定文件的創建方式，你可以調用用IWMHeaderInfo::GetAttributeByName，傳遞g_wszWMSeekable來獲得是否可定位信息。
調用IWMReader::Start可以定位到指定時間。
[開發經驗]
選擇編碼器
Windows Media
儘管在低碼流率下的效果令人滿意，但是編碼時系統資源佔用過高，同時在高碼流率的情況下效果不甚理想。
Windows Media Video 9
Windows Media Video 9 Screen
對於格式比較挑剔，例如視頻的規格必須是按雙字對齊的。對於長時間的多媒體編碼，有階段性的質量變化（一段時間內楨率高，過一段時間楨率低）
Windows Media Audio 9
Windows Media Audio 9 Professional
系統資源佔用過高致使採樣不足的話會造成音調的變化，效果不可忍受。
自定義編碼器
多種數據混合編碼，避免了同步問題，但是不能單獨爲一種數據指定碼流率和優先級等信息。
旅行者
http://www.cnblogs.com/shenghuafen/articles/23396.aspx
Mon, 12 Jul 2004 05:39:00 GMThttp://www.cnblogs.com/shenghuafen/articles/23396.aspxhttp://www.cnblogs.com/shenghuafen/articles/23396.aspx#Feedback0http://www.cnblogs.com/shenghuafen/comments/commentRss/23396.aspx
http://www.cnblogs.com/shenghuafen/services/trackbacks/23396.aspx由於網絡帶寬的限制以及編碼技術的制約，實時視頻通信應用中存在視頻質量差、圖像延時大和抗分組丟失能力弱等問題，而在包括音頻、視頻和數據的視頻會議呼叫中，視頻部分通常會佔用整個呼叫可用帶寬的絕大部分。本文介紹的H.26L針對這種問題，能將帶寬需求降低50%，因而可在低帶寬網絡上實現視頻會議系統應用。
從固定和移動視頻電話以及視頻會議到DVD和數字電視，數字視頻正被越來越多的應用採用。這一現象之所以出現歸功於視頻編碼標準的發展，有了這些編碼標準，系統和系統之間才能實現互通性。此外，這些標準也爲降低整個網絡結構中所需的帶寬作出了貢獻，並在位率不變時，讓系統可以獲得更好的視頻質量，同時減小系統對視頻存儲的要求。幾年以前，基於模塊的壓縮算法才趨於成熟，而如今出現的H.26L標準卻已經在編碼效率上實現了突破，它可以通過進一步擴展優先標準中的基本技術，將位率降低50％。
H.26L中包含幀內預測(intra
prediction)功能、更靈活的運動補償功能、新的4×4整型轉換功能，還能實現功能更強大的熵編碼，這些對於H.26L而言都很關鍵。H.26L中提供了多種編碼工具，這就使系統開發商能夠針對不同的終端系統應用來優化其算法，達到區分產品的目的。但在開始採用H.26L進行開發之前，我們必需瞭解它能夠作些什麼，以及如何完成其功能。只有這樣，設計者才能很好的利用這項剛剛出臺的視頻編碼標準所具備的優勢進行設計。
H.26L概述
開發視頻編碼標準的正式組織有兩個，其一是ITU-T，其二是ISO/IEC JTC1。ITU-T視頻編碼標準被稱作建議，以H.26X的形式表示(例如，H.261、H.262、H.263和H.26L)。ISO/IEC標準則以MPEG-x的形式表示(例如，MPEG-1、MPEG-2和MPEG-4)。
ITU-T建議本來是爲視頻會議和視頻電話等實時視頻通信應用設計的，而MPEG標準主要則是爲視頻存儲(DVD)、廣播視頻(廣播TV)以及視頻流(例如，網上視頻、DSL上的視頻以及無線視頻應用)設計的。這兩個標準委員會通常都獨立工作，唯一的例外就是二者合作開發了H.262/MPEG-2標準。
最近，ITU-T和ISO/IEC已經達成協議，再次合作開發由ITU-T發起的H.26L標準。他們之所以能在開發H.26L上達成一致，原因在於，從性能的角度而言，H.26L超越了現有的所有視頻編碼標準。圖1對ITU-T建議和ISO/IEC MPEG標準的發展演化過程進行了總結。
開發H.26L項目的目的，是爲了通過採用“Back-To-Basics”方法，開發出一種基於通用模塊的，簡單直接的高性能視頻編碼標準。H.26L標準的開發工作是由ITU-T視頻編碼專家組(VCEG)發起的，開始於1997年。到2001年年底，他們發現，基於H.26L的軟件所能提供的視頻質量，就是現有的最好的基於MPEG-4的軟件也無法與之媲美。於是，ISO/IEC MPEG與ITU-T
VCEG結合起來組成了一個聯合視頻開發組(JVT)，接管了H.26L項目。JVT希望建立一個唯一的視頻編碼標準，同時使其成爲MPEG-4標準家族和ITU-T建議家族的新成員(比如，成爲MPEG-4中的第10部分或ITU-T中的H.264)。
H.26L的開發目前正在進行中，其第一版有望在2003年年底前公佈。
當前的H.26L標準中包含了一些能夠使其區別於現有的一些其它標準的特性，如：
1. 對位率的節約高達50%。在大多數位率的情況下，當編碼優化程度接近時，H.26L與H.263v2(H.263+)或MPEG-4簡化版相比，H.26L可以允許位率的降低程度平均達到50%。2. 可提供高質量的視頻信號。H.26L即使在位率很低的情況下也能提供質量穩定的視頻信號。3. 對延時約束的適應性較強。當用於實時通信應用中(例如視頻會議)時，H.26L可以以低延時模式工作，而應用於對延時沒有要求的應用中(例如視頻存儲)時，H.26L又可以以較高的效率處理延時。4. 具有誤差處理能力。在分組網絡中出現分組丟失時或在較易出錯的無線網絡中出現誤碼時，H.26L能夠提供處理這類問題所必需的工具。5. 網絡非常友好。在H.26L中，有一個新的特性，那就是視頻編碼層和網絡適配層從概念上分離開來。視頻編碼層用於對視頻圖像的內容進行高比壓縮，而網絡適配層用於根據用戶所使用的網絡類型的不同，將壓縮後的信息打包。這使得分組過程變得更加靈活和簡單，同時也改善了對信息優先權的控制情況。
綜合以上這些特性，可以看出H.26L在視頻應用方面具有相當的優勢。在本文的結束部分，我們將討論H.26L用於視頻會議時所具備的優勢。
H.26L是如何實現上述功能的呢？
開發H.26L的主要目的是希望找到一種方法來充分地實現更好的視頻質量，這種視頻質量是任何現有視頻編碼標準都無法達到的。但H.26L的實現方法和以前的那些標準(例如H.263和MPEG-4)中所用到的方法差別並不顯著，它包含以下四個主要步驟：
1. 首先，將每個視頻幀分成像素塊，於是，對視頻幀的處理可以建立在處理像素塊的基礎上。2. 其次，通過進行變換、量化和熵編碼(或可變長度編碼)，對一些原始像素塊編碼，從而將視頻幀中的空間冗餘度利用起來。3. 然後，只對連續幀之間出現的變化進行編碼，從而充分利用連續幀之間存在的時間冗餘度。這個過程是通過運動估值和補償來實現的。4. 最後，對餘差模塊編碼，也就是說，通過變換、量化和熵編碼對原始模塊和相應的預測模塊之間的差異進行編碼，從而充分利用視頻幀內剩餘的空間冗餘度。
從編碼的角度來看，H.26L和其它編碼標準的主要差別如圖2中的編碼模塊框圖所示。從運動估值和補償的角度來看，H.26L採用了各種尺寸和形狀的模塊，子像素運動估值的分辨率更高，並且可以有多種參考幀選擇方案。從所採用的變換方式來看，H.26L採用的基於整數的變換方式類似於早期那些標準中所採用的DCT變換，不同的是，採用這種變換方式進行反變換時，不存在失配問題。
在H.26L中，熵編碼有兩種實現方法，其一是利用一個通用的可變長度編碼表來實現，此外，也可由基於上下文的自適應二進制算術編碼實現。
如何組織位流
前面講到，在H.26L中，我們會將一個給定的視頻圖像化分爲許多小像素塊，這些小像素塊就叫做宏塊(macroblock)。如圖3所示，我們將一幅分辨率爲QCIF(176×144像素)的圖像劃分爲99個16×16的宏塊。對其它幀所作的宏塊分段處理與此類似。
我們以原圖像的分辨率對該圖像的亮度信息取樣，而對圖像的色差信息Cb和Cr，則從水平方向和垂直方向上進行下取樣。此外還應注意的是，一幅圖像只能被分割成整數片，因爲如果該圖像在傳輸過程中丟失了一些信息的話，那麼整數片的分割方法會大大有助於信息的再同步。
幀內預測(intraprediction)編碼
幀內預測(intraprediction)編碼
幀內編碼是指只利用視頻圖像內的空間冗餘度來優化編碼。採用這種編碼方式得到的圖像幀被稱作I-圖。I-圖通常是通過直接對一幀中的各宏塊進行變換得到的，其文件很大，因爲此時幀內還含有大量的信息，而且編碼過程絲毫沒有利用圖像的時間信息。
要提高H.26L中幀內編碼過程的編碼效率，就必須將同一幀中相鄰宏塊之間的空間關聯性利用起來。提出這一想法的依據是人們發現相鄰的宏塊常常具有類似的特性。因此，作爲對某一給定宏塊進行編碼的第一步，我們可以根據周圍的宏塊來預測我們所感興趣的宏塊，通常我們會選擇目標宏塊左側和上側的宏塊，因爲這些宏塊已經經過編碼了。然後再對實際的宏塊與預測宏塊之間的差別進行編碼。這樣，要表達出我們所感興趣的宏塊時所需的位數就比直接對該宏塊進行變換所需的位數少得多。
H.26L提供了6種模式用於實現4×4亮度塊的預測，包括直流預測(模式0)和其它5種有方向的預測模式(模式1到模式5，如圖4所示)。圖中，像素A到像素I均經過編碼，可將這些像素作爲相鄰模塊，用於預測目標塊。
例如，如果選擇模式2進行預測，那麼像素a、e、i和m在預測中被設置爲與像素A相等，像素b、f、j和n在預測中被設置爲與像素B相等。對於空間細節含量較少的區域(平坦區域)，H.26L也支持16×16的幀內編碼，此時可在4種預測模式中選用一種來對整個宏塊進行預測。
最後，每個塊在選擇其預測模式時，它採用各種模式的可能性由其周圍模塊編碼時所採用的預測模式來決定，分配給某模式的符號越短，採用這種模式的可能性就越大。
幀間預測和編碼
在幀間預測和編碼(interprediction and coding)中，運動估值和補償在實現時必須利用連續幀之間存在的時間冗餘度，因而這種方法可有效地實現視頻序列的編碼。如果運動估值所選定的參考幀是一個經過編碼的幀，那麼目標幀(被編碼幀)就叫做P-圖。如果已編碼幀和未編碼幀均被選作參考幀，那麼目標幀就叫做B－圖。
H.26L中的運動估值能夠支持早期視頻標準中的大多數重要特性，不同的是H.26L中的功能更多也更靈活，因而其效率得到了改善。除了支持P-圖(既支持單參考幀也支持多參考幀)和B-圖以外，H.26L還支持一種新的叫做SP－圖的流間過渡圖像。H.26L中採用的運動估值所具備的主要特性包括：塊大小和形狀多種多樣，高精度的子像素運動向量，多參考幀以及預測環路中的消塊濾波器。
1.
塊大小：我們可以通過使用多個不同大小和不同形狀的塊來完成每個16×16宏塊的運動補償，見圖5。即使只有4×4那麼小的塊，H.26L也可爲其傳送特有的運動向量，因此H.26L最多可以爲每一個宏塊傳送16個運動向量。H.26L同時也支持大小爲16×8、8×16、 8×8、8×4和4×8的塊，如圖5所示。H.26L這種能夠對小尺寸塊進行運動補償的能力，從整體上改善了目標預測的性能。特別值得一提的是，這同時還改善了整個系統模型處理精細運動細節的能力，並使得主觀視覺質量得到提高，因爲這些小尺寸塊不會生成大的塊狀馬賽克。
2. 運動估值的精確性：如果不由現有標準能達到的空間精確度來決定運動向量，而由更高級的空間精確度來決定運動向量，那麼H.26L中算法的預測能力又會得到進一步增強。H. 26L中，四分之一像素精確度(Quarter-pixel-accurate)是其最低運動補償精度。而在高位率和高視頻分辨率下，採用八分之一像素精確度(eighth-pixel accuracy)可能對提高編碼效率很有幫助。
3. 可選擇多個參考圖像：H.26L標準提供了一個選項，在圖像進行幀間互編碼時可以選擇多個參考幀，最多5個，這樣，主觀視頻質量更好，對需要編碼的視頻幀進行編碼的效率也更高。此外，採用多個參考幀也可以使H.26L位流具備更強的差錯處理能力。
具備消塊濾波器：H.26L定義了一種自適應消塊濾波器，該濾波器位於預測環路內，可工作於水平塊邊緣和垂直塊邊緣，以去除由於塊預測誤差引起的干擾效應。這種濾波通常是基於大小爲4×4的塊邊界進行的，邊界的兩端上均有兩個像素通過三點式濾波得到更新。
H.26L中的整數轉換
H.26L中的整數轉換
不論是幀內預測還是幀間預測，預測誤差塊中包含的信息最後都以變換系數的形式表達出來。H.26L採用了一種和浮點8×8 DCT相反的純整數空間轉換(類似於離散餘弦變換，形狀爲4×4)，這種轉換方法由早期的標準中用過的舍入誤差容限定義。4×4的小尺寸有助於降低塊狀和環狀馬賽克，而採用整數轉換又消除了反變換過程中編碼器和譯碼器之間的失配問題。
H.26L中的量化
H.26L中的量化
量化是數據壓縮中很重要的一步。在H.26L中，變換系數通過無擴展死區的分級量化量進行量化。在每個宏塊的基礎上可選擇32種不同的量化步長，這與早前一些標準的量化能力(例如，H.263支持31種不同量化步長)類似。但在H.26L中，量化步長是以前次步長的12.5%的速率遞增，而不象過去的標準中那樣每次遞增一個常量。有些時候，亮度係數的量化非常粗糙，而色差信號在量化時則採用了這種更精細的量化步長，因而色差信號的保真度較亮度係數大有改善。
量化後的變換系數對應於各種不同的頻率。圖6左上角的係數代表直流值，而其它部分的係數則代表各種非零的頻率值。編碼過程的下一步就是將量化後的係數排成一列，直流係數排在列首。
H.26L規定了兩種不同的係數掃描方式，見圖6。大多數情況下采用的都是簡單的雙掃描方式，這種方式和早期的視頻編碼標準中所採用的傳統掃描方式相同，根據係數所對應的頻率將他們以升序方式排列。要提高編碼效率就得采用雙掃描方式，這種掃描方式只適用於量化步長較小的塊內掃描。
熵編碼
熵編碼是視頻編碼過程中的最後一步。至今爲止，H.26L中只採用了兩種熵編碼方法。第一種方法的基礎是對通用可變長度碼(UVLC)的應用，第二種方法的基礎是基於上下文的自適應二進制算術編碼。人們已經爲在熵編碼中統一採用一種方法付出了實質性的努力，這種方法很可能是基於特殊VLC的自適應應用的一種方法。
在對量化後的變換系數、運動向量以及其它編碼信息進行壓縮的各種方法中，基於VLC的熵編碼方法是使用最廣泛的一種。VLC的基礎就是爲出現可能性較大的符號分配較短的碼字，而爲出現頻率較低的符號分配較長的碼字。各符號和相應的碼字存儲在一個叫做VLC表的查找表中，編碼器和譯碼器中都存有該表。
在H.263之類視頻編碼標準中，根據感興趣信息的類型(例如變換系數或運動向量)不同，需使用許多的VLC表。而在H.26L中，不論符號所代表的是什麼數據類型，都可以用一個通用的VLC表來對編碼器中所有的符號進行熵編碼。
基於上下文的自適應二進制算數編碼在編碼器和譯碼器內都採用了一種概率模型，該模型適用於所有的語法元素(如變換系數、運動向量)。爲了提高算術編碼方式的編碼效率，我們可以通過對上下文建模，將一個潛在的概率模型應用於視頻幀的不斷變化的統計量。這樣，我們就能對編碼符號進行有條件的概率估計。
如果我們採用了恰當的上下文模型，那麼我們就可以根據當前符號周圍的已編碼符號的情況來決定如何在各種概率模型之間切換，從而達到利用符號間已有的冗餘度的目的。每個語法元素都支持一個不同的模型，例如，運動向量和變換系數的模型就不相同。如果一個給定的符號具有非二進制的值，那麼就將它映射爲一個二進制序列，或者叫做“bins”。確切的二進制值轉換是通過一個給定的二進制樹實現的，在本文討論的模型中採用的是UVLC二進制樹。
接着，採用新的概率估計來對這個二進制結果進行算術運算，此處採用的概率估計系在前一次上下文建模階段更新後的概率估計。在對每個二進制數值編碼過後，這個概率估計的值又要根據剛剛編碼之的二進制符號進行調整。
本文小結
在利用數字信號處理器實現H.26L的過程中，充分利用了各種新技術，使得實時視頻通信應用的視頻質量和圖象延時都有所改善。一個實時視頻會議應用最能說明H.26L的實現機理。視頻會議一般都將穩定的視頻質量、較低的延時和較強的抗分組丟失能力作爲最主要的要求(即便在帶寬有限的情況下也要求視頻質量穩定)。而在一次涉及音頻、視頻和數據的視頻會議呼叫中，視頻部分通常會佔用整個呼叫可用帶寬的絕大部分。如果視頻部分所需的帶寬能夠得到降低，那麼將會有更多的低帶寬網絡接受視頻會議系統這種應用。H.26L就針對這種需求，將帶寬需求從H.26+所需的320kbps降低到160kbps。
此外，許多視頻會議解決方案爲了保證視頻質量令人滿意，仍在採用二次(two-pass)編碼方式，但這種編碼方法會爲會議呼叫引入令人討厭的延時。H.26L方案則保證了即使只採用一次性(one pass)編碼仍能得到優秀的視頻信號，這樣做也就降低了二次編碼方法中的處理延時。儘管在目前，大多數視頻會議呼叫都發生在本地專用網上，但在分組傳輸中仍然會出現一定程度的分組丟失。H.26L具備的編碼端的誤差處理能力和在解碼端的隱藏錯誤的能力使其即使在分組丟失率很高的情況下也能有效對抗這種分組丟失
旅行者
http://www.cnblogs.com/shenghuafen/articles/23394.aspx
Mon, 12 Jul 2004 05:29:00 GMThttp://www.cnblogs.com/shenghuafen/articles/23394.aspxhttp://www.cnblogs.com/shenghuafen/articles/23394.aspx#Feedback0http://www.cnblogs.com/shenghuafen/comments/commentRss/23394.aspx
http://www.cnblogs.com/shenghuafen/services/trackbacks/23394.aspx首先，傳輸數字圖像所需的帶寬遠窄於未壓縮圖像。例如，NTSC圖像以大約640 x 480的分辨率，24bits／象素，每秒30幀的質量傳輸時，其數據率達28M字節／秒或221M位／秒。此外，NTSC聲音信號還要使未壓縮圖像的比特率再增加一些。然而單速CD-ROM（1x）驅動器只能以1.2M位／秒的速率傳輸數據。
第二個原因是以28M字節／秒的速率，15秒的未壓縮圖像將佔用420M字節的內存空間，這對於大多數只能處理小圖像片斷的臺式計算機來說都是不可接受的。
當今把圖像加入電子信號的關鍵問題是壓縮方式。有幾種不同的壓縮方式，但MPEG是最有市場潛力的壓縮方式。
MPEG的全稱是Moving Pictures Experts Group（即動態圖像專家組），由ISO(International Standards Organization，國際標準化組織)與IEC（International Electronic Committee）於1988年聯合成立，致力於運動圖像(MPEG視頻)及其伴音編碼(MPEG音頻)標準化工作。MPEG共有4個版本，其中前兩個版本MPEG－1和MPEG－2應用比較廣泛，而MPEG－4雖然已推出近兩年，但有關它的應用卻直到最近才活躍起來，MPEG－7則是屬於未來的標準。
MPEG－1標準（ISO/IEC11172）制定於1992年，是針對1.5Mbps以下數據傳輸率的數字存儲媒體運動圖像及其伴音編碼設計的國際標準，主要用於在CD－ROM（包括Video－CD、CD－I等）存儲彩色的同步運動視頻圖像，它針對SIF（標準交換格式）標準分辨率(NTSC製爲352×240；PAL製爲352×288)的圖像進行壓縮，每秒可播放30幀畫面，具備CD(指激光唱盤)音質。同時，它還被用於數字電話網絡上的視頻傳輸，如非對稱數字用戶線路(ADSL)、視頻點播(VOD)、教育網絡等。 它的目的是把221Mbit/秒的NTSC圖像壓縮到1.2Mbit/秒，壓縮率爲200:1。使用MPEG－1的壓縮算法，可以將一部120分鐘長的電影壓縮到1.2GB左右，因此，它被廣泛地應用於VCD製作和一些視頻片段的下載，目前90％以上的VCD都是用MPEG－1格式壓縮的。目前一些製作VCD的採集壓縮卡，像SNAZII DVC，MP 10，白老匯等都是採用MPEG-1壓縮標準。
MPEG-2用於寬帶傳輸的圖像，圖像質量達到電視廣播甚至HDTV的標準。和MPEG-1相比，MPEG-2支持更廣的分辨率和比特率範圍，將成爲數字圖像盤（DVD）和數字廣播電視的壓縮方式。這些市場將和計算機市場交織在一起，從而使MPEG-2成爲計算機的一種重要的圖像壓縮標準。MPEG－2標準ISO/IEC13818）制定於1994年，是針對3～10Mbps的數據傳輸率制定的的運動圖像及其伴音編碼的國際標準。MPEG－2可以提供一個較廣的範圍改變壓縮比，以適應不同畫面質量、存儲容量和帶寬的要求。它在與MPEG－1兼容的基礎上實現了低碼率和多聲道擴展：MPEG－2可以將一部120分鐘長的電影壓縮到4～8GB(它提供的是我們通常所說的DVD品質)，其音頻編碼可提供左右中及兩個環繞聲道、一個加重低音聲道和多達7個伴音聲道(因此DVD可有8種語言配音)。除了作爲DVD的指定標準外，MPEG－2還可用於爲廣播、有線電視網、電纜網絡等提供廣播級的數字視頻。不過對普通用戶來說，由於現在電視機分辨率的限制，MPEG－2所帶來的高清晰度畫面質量(如DVD畫面)在電視上效果並不明顯，倒是其音頻特性(如加重低音、多伴音聲道等)得到了廣泛的應用。 MP3是應用於MPEG-1的一項音頻壓縮技術標準，英文全稱是MPEG-1 Audio Layer3。做出這個定義的依據是：第一，MPEG官方已經明確表示，MP3和MPEG-1 Audio Layer3是指同一件事情。第二、Layer技術的發佈者Fraunhofer IIS-A〔注1〕官方技術文檔中也提到過，MP3就是MPEG-1 Audio Layer3。此外，在很多知名廠商比如SONY、Philips的一些相關技術文檔中也直接說明了MP3是MPEG-1 Audio Layer3的問題(參考相應技術部分)。
MPEG－3是ISO/IEC最初爲HDTV(高清晰電視廣播)制定的編碼和壓縮標準，但由於MPEG－2的出色性能已能適用於HDTV，因此MPEG－3標準並未制定，我們通常所說的MP3指的是MPEG Layer 3，只是MPEG的一個音頻壓縮標準。
令人稱道的MPEG－4
MPEG－4於1998年11月公佈，預計投入使用的國際標準MPEG－4是針對一定比特率下的視頻、音頻編碼，更加註重多媒體系統的交互性和靈活性。爲此，MPEG－4引入了AV對象（Audio/Visual Objects），使得更多的交互操作成爲可能：
“AV對象”可以是一個孤立的人，也可以是這個人的語音或一段背景音樂等。它具有高效編碼、高效存儲與傳播及可交互操作的特性。
MPEG－4對AV對象的操作主要有：採用AV對象來表示聽覺、視覺或者視聽組合內容；組合已有的AV對象來生成複合的AV對象，並由此生成AV場景；對AV對象的數據靈活地多路合成與同步，以便選擇合適的網絡來傳輸這些AV對象數據；允許接收端的用戶在AV場景中對AV對象進行交互操作等。
MPEG－4標準則由6個主要部分構成：
1 DMIF（The Dellivery Multimedia Integration Framework）
DMIF 即多媒體傳送整體框架，它主要解決交互網絡中、廣播環境下以及磁盤應用中多媒體應用的操作問題。 通過傳輸多路合成比特信息來建立客戶端和服務器端的交互和傳輸。 通過DMIF，MPEG4可以建立起具有特殊品質服務（QoS）的信道和麪向每個基本流的帶寬。
2 數據平面
MPEG4中的數據平面可以分爲兩部分：傳輸關係部分和媒體關係部分。
爲了使基本流和AV對象在同一場景中出現，MPEG4引用了對象描述（OD）和流圖桌面（SMT） 的概念。OD 傳輸與特殊AV對象相關的基本流的信息流圖。桌面把每一個流與一個CAT（Channel Assosiation Tag）相連，CAT可實現該流的順利傳輸。
3 緩衝區管理和實時識別
MPEG4定義了一個系統解碼模式（SDM），該解碼模式描述了一種理想的處理比特流句法語義的解碼裝置，它要求特殊的緩衝區和實時模式。通過有效地管理，可以更好地利用有限的緩衝區空間。
4 音頻編碼
MPEG4的優越之處在於——它不僅支持自然聲音，而且支持合成聲音。MPEG4的音頻部分將音頻的合成編碼和自然聲音的編碼相結合，並支持音頻的對象特徵。
5 視頻編碼
與音頻編碼類似，MPEG4也支持對自然和合成的視覺對象的編碼。 合成的視覺對象包括2D、3D 動畫和人面部表情動畫等。
6 場景描述
MPEG4提供了一系列工具，用於組成場景中的一組對象。一些必要的合成信息就組成了場景描述，這些場景描述以二進制格式BIFS（Binary Format for Scene description）表示，BIFS與AV對象一同傳輸、編碼。場景描述主要用於描述各AV對象在一具體AV場景座標下，如何組織與同步等問題。同時還有AV對象與AV場景的知識產權保護等問題。MPEG4爲我們提供了豐富的AV場景。
MPEG－4的應用
與MPEG－1和MPEG－2相比，MPEG－4更適於交互AV服務以及遠程監控，它的設計目標使其具有更廣的適應性和可擴展性： MPEG－4傳輸速率在4800－64000bps之間，分辨率爲176×144，可以利用很窄的帶寬通過幀重建技術壓縮和傳輸數據，從而能以最少的數據獲得最佳的圖像質量。因此，它將在數字電視、動態圖像、互聯網、實時多媒體監控、移動多媒體通信、Internet/Intranet上的視頻流與可視遊戲、DVD上的交互多媒體應用等方面大顯身手。
當然，對於普通用戶來說，MPEG－4在目前來說最有吸引力的地方還在於它能在普通CD－ROM上基本實現DVD的質量：用MPEG－4 壓縮算法的ASF（Advanced Streaming format，高級格式流）可以將120分鐘的電影壓縮爲300MB左右的視頻流；採用MPEG－4壓縮算法的DIVX 視頻編碼技術可以將120分鐘的電影壓縮600MB左右，也可以將一部 DVD影片壓縮到 2 張 CD－ROM上！也就是說，有了MPEG－4，你不需要購買 DVD－ROM 就可以享受到和它差不多的視頻質量！播放這種編碼的影片對機器的要求並不高：只要你的電腦有300MHz 以上(無論是哪種型號)的CPU、64MB內存、8MB的顯卡就可以流暢地播放。
不過，和DVD相比，MPEG－4屬於一種高比率有損壓縮算法，其圖像質量始終無法和DVD的MPEG－2相比，畢竟DVD的存儲容量比較大。此外，要想保證高速運動的圖像畫面不失真，必須有足夠的碼率，目前MPEG－4的碼率雖然可以調到和DVD差不多，但總體效果還有不小的差距。因此，現在的MPEG－4只能面向娛樂、欣賞方面的市場，那些對圖像質量要求較高的專業視頻領域暫時還不能採用。
旅行者
http://www.cnblogs.com/shenghuafen/articles/23392.aspx
Mon, 12 Jul 2004 05:26:00 GMThttp://www.cnblogs.com/shenghuafen/articles/23392.aspxhttp://www.cnblogs.com/shenghuafen/articles/23392.aspx#Feedback0http://www.cnblogs.com/shenghuafen/comments/commentRss/23392.aspx
http://www.cnblogs.com/shenghuafen/services/trackbacks/23392.aspxMPEG-4技術的應用將使當前很多提供聲音和數據服務的系統得到進一步的擴展，根據涉及ISO標準的版本、部分、類(profile)和等級(level)的不同，MPEG-4對應不同的技術。本文將討論所有不同的MPEG-4技術，研究MPEG-4的需求、架構和實現策略，並討論計算需求以更好地理解MPEG-4的實現。
MPEG-4標準活動開始於1995年，至今還在不斷髮展之中。此標準由如表所示的16部分組成，本文將詳細討論該標準的第二和第十部分，這兩部分是關於視頻編碼處理。在很多出版物中經常出現MPEG-4，但常常並沒有嚴格區分出MPEG-4到底是用軟件還是硬件來實現的，本文試圖更明確闡述“MPEG-4”這個術語。有關MPEG句法的一部分新版本使標準實現向後兼容，這是MPEG-4的第二部分。在新的不能後向兼容的技術引入MPEG標準後，在2001-2003期間又創建了MPEG-4的第10部分，即高級視頻編碼(AVC)。
標準的創建需要通過工作草案(WD)、委員會草案(CD)、最終委員會草案(FCD)、草案國際標準(DIS)、最終草案國際標準(FDIS)和最終國際標準(IS)這一系列過程，在該過程中伴隨着技術的彙集、融合和應用。標準的修正通常都會增加更多的類，MPEG-4的第二版修正1和2就增加了FGS類，而修正3又增加了簡單可擴展level 0和高級簡單可擴展level 3b。MPEG的類規定了用於協同操作點(interoperability point)的技術，等級規定了一個類的範圍或大小。此外，MPEG還定義了碼流和解碼器的一致性問題，但並沒有直接規定解碼器的功能。
壓縮技術與MPEG-4
爲了更好地理解類和等級，先了解MPEG-4的簡單類(Simple profile)和核心類(Core file)。簡單類採用矩形I幀和P幀，具有基於運動補償離散餘弦變換(DCT)基本功能的編碼處理。I幀爲幀內編碼，而P幀爲幀間編碼，這兩類編碼方式是爲了降低冗餘信息。核心類可以採用I幀、P幀和B幀視頻對象平面(VOP)，並具有采用二進制形狀定義的任意形狀編碼功能。因此，如果採用核心類則必須開發出一種形狀自適應DCT來實現與核心類的互操作，而在簡單類中需要採用標準的8×8 DCT技術。
在MPEG的術語中，等級表示在一個類中的參數範圍。一些重要參數有：對象數量、量化表數量、視頻複雜度驗證子(VCV)緩衝大小、VCV解碼器速率(單位：kbps)。緩衝器大小和速度的限制，以及類採用的技術所規定的操作點(operate point)都明確定義了該類適合的應用領域。例如，假如互聯網流媒體聯盟(ISMA
1.0)決定在兩個操作點之間的互操作，對於視頻部分他們可以選擇Simple@Level1和Advanced Simple@Level3。開發工程師可以根據所要求的信道碼率和處理要求，選擇一個最具成本效益的類和等級。
MPEG-4複雜度變化
隨着數字視頻的廣泛應用，目前已經存在多種不同的MPEG-4解決方案複雜度。由於存在好幾種不確定因素，使得在設計一個複雜的視頻編解碼器之前很難確定真正所需要的計算能力。由於MPEG參考代碼的編制過程中會有若干公司和會員單位參與，儘管代碼在功能上是正確的，但在實時性和存儲器管理上並沒有實現優化。事實上，MPEG-4有第5部分的參考軟件和第7部分的優化參考軟件。即使是優化的參考軟件，由於它必須避免採用特定供應商的處理器代碼，因而比商業解決方案還是慢3到5倍。目前有兩個獨立於處理器的評估工具可以幫助評估MPEG參考代碼的複雜度：IMEC公司的Atomium工具評估軟件的內存轉移情況，而EPFL SIT工具以運營商的角度來評估最優化情況。這些評估工具的作用就是要給出在MPEG-4的類中的某項技術複雜程度的總體認識。
在瞭解了不同的MPEG-4技術的計算複雜性之後，下一步就是要知道編碼器和解碼器需要處理的原始數據量，通過了解每秒中宏塊數量就可以輕易地得到該數據。圖1中列出了簡單類的level 1到level 3，高級類的level 0到level 5，主類的level 2到level 4。值得注意的是，除了三個類的技術不同以外，不同操作點在單位時間內能處理的數量具有很大的差異。此外，如果包含了演播室類(Studio profile)，這個範圍可以達到每秒三百萬個宏塊。
MPEG-4的實現
假定你能夠確定一個或一系列操作點，怎樣才能實現實時操作呢？通過正確的MPEG-4技術的類估計，爲滿足類似於每秒內的宏塊數的系統級參數的並行特性要求，將採用一種具有軟件配合的視頻管線架構(video pipeline architecture)，FPGA可以提供這種必要的並行特性來實現實時的、具有成本效益的視頻編解碼器。考慮硅器件的MOPS(百萬操作每秒)參數，目前有約2,000MOPS的通用處理器，而採用DSP處理器可以將這個數字提高到約8,000MOPS，但存在數據流由限運算單元處理的缺點。帶有專用處理引擎的媒體處理器，如位運算單元可以將該參數提升到20,000MOPS，但FPGA和ASIC具有更高的設計自由度，可以擴展到100,000MOPS以上。
FPGA基於SRAM技術的特點使其具有可再編程功能。因此，對於一個給定的FPGA設計可以支持幾種操作點和不同的信道數，如圖2所示。在必要的情況下，不同的MPEG-4技術還可以編程在同一個FPGA中，在不超出FPGA計算能力條件下，甚至還可能支持MPEG-4標準未來的類和等級。像ISMA這樣的系統級要求經常具有不同的操作點以滿足不同的應用需要，利用FPGA的重編程的特性可以開發出足不同市場需求的設備。
H.26L中的量化
H.26L中的整數轉換
幀內預測(intraprediction)編碼