如果您不熟悉數字媒體，本主題會介紹在撰寫媒體基礎應用程式之前必須瞭解的一些概念。
流
數據流 是一連串具有統一類型的媒體數據。 最常見的類型是音訊和視訊，但數據流幾乎可以包含任何類型的數據，包括文字、腳本命令和靜止影像。 本文件中 資料流 一詞並不表示透過網路傳遞。 用於本機播放的媒體檔案也包含數據流。
通常，媒體檔案包含單一音訊數據流，或只包含一個視訊串流和一個音訊數據流。 不過，媒體檔案可能包含相同類型的數個數據流。 例如，視訊檔案可能包含數種不同語言的音訊串流。 在運行時間，應用程式會選取要使用的數據流。
壓縮
壓縮 是指移除冗餘信息來減少數據流大小的任何程式。 壓縮演算法分為兩大類：
- 無損失 壓縮。 使用無遺失演算法時，重建的數據會與原始數據相同。
- 遺失 壓縮。 使用遺失演算法時，重建的數據是原始數據的近似值，但並非完全相符。
在大多數其他領域中，無損壓縮是不被接受的。 （想像一下，得到一個「近似」的電子表格！）不過，有損壓縮方法非常適合音訊和視訊，原因有幾個。
第一個原因與人類感知的物理有關係。 當我們聽一個複雜的聲音，如音樂錄音，一些包含在該聲音中的資訊對耳朵是無法察覺的。 在訊號處理理論的説明下，可以分析和分隔無法察覺的頻率。 移除這些頻率不會對感知產生任何影響。 雖然重建的音訊與原始音訊不完全相符，但它 音效 與接聽程式相同。 類似的原則適用於影片。
其次，根據預期目的，聲音或影像品質的一些降低可能可以接受。 例如，在電話語音中，音訊通常會高度壓縮。 對於電話交談來說，效果已經足夠好了，但您不會想用電話來聽交響樂團的音樂。
壓縮也稱為 編碼，而編碼的裝置稱為 編碼器。 反向過程是 解碼，而該裝置自然地稱為 解碼器。 編碼器和譯碼器的統稱是 編解碼器。 編解碼器可以在硬體或軟體中實作。
自數位媒體問世以來，壓縮技術已經迅速改變，目前正在使用大量的壓縮配置。 事實是數位媒體程序設計的主要挑戰之一。
媒體容器
將原始音訊或視訊串流儲存為計算機檔案，或直接透過網路傳送音訊或視訊串流是罕見的。 有一件事，不可能譯碼這類數據流，而不需要事先知道要使用哪一個編解碼器。 因此，媒體檔案通常至少包含下列一些元素：
- 描述數據流數目、每個數據流格式等等的檔案標頭。
- 索引，可讓您隨機存取內容。
- 描述內容的元數據（例如，藝術家或標題）。
- 封包標頭，以啟用網路傳輸或隨機存取。
本文件使用術語容器 來描述整個數據流、標頭、索引、元數據等的套件。 使用 容器一詞 而不是 檔案 的原因是某些容器格式是針對實時廣播而設計。 應用程式可以實時產生容器，永遠不會將它儲存到檔案中。
媒體容器的早期範例是 AVI 檔案格式。 其他範例包括 MP4 和進階系統格式 （ASF）。 容器可以依擴展名（例如，.mp4）或MIME類型來識別。
下圖顯示媒體容器的一般結構。 圖表不代表任何特定格式;每個格式的詳細數據差異很大。
請注意，圖表中顯示的結構是階層式的，標頭資訊會出現在容器開頭。 此結構通常見於許多（但並非全部）容器格式。 另請注意，數據區段包含交錯的音訊和視訊封包。 這種交錯在媒體容器中很常見。
多任務處理 一詞是指將音訊和視訊串流封包並交錯至容器的程式。 反向程式會從封包化數據重新組譯數據流，稱為 解構。
格式
在數字媒體中，格式 一詞模棱兩可。 格式可以參考 編碼類型，例如 H.264 視訊，或 容器，例如 MP4。 對於一般用戶來說，這種區別通常令人困惑。 媒體格式的名稱不一定總是有幫助。 例如，MP3 是指編碼格式 （MPEG-1 音訊層 3） 和檔格式。
不過，差別很重要，因為讀取媒體檔案實際上牽涉到兩個階段：
- 首先，必須剖析容器。 在大部分情況下，在此步驟完成之前，無法知道每個數據流的數據流數目和格式。
- 接下來，如果數據流經過壓縮，則必須使用適當的譯碼器進行譯碼。
這一事實自然會導致軟體設計，其中會使用個別元件來剖析容器和譯碼數據流。 此外，這種方法更適合外掛程式模型，讓第三方可以提供自己的剖析器和編解碼器。 在 Windows 上，元件物件模型 （COM） 提供一種標準方式，將 API 與其實作分開，這是任何外掛程式模型的需求。 基於這些原因，Media Foundation 使用 COM 介面。
下圖顯示用來讀取媒體檔案的元件：
寫入媒體檔案也需要兩個步驟：
- 編碼未壓縮的音訊/視訊數據。
- 將壓縮的數據放入特定的容器格式。
下圖顯示用來寫入媒體檔案的元件：
相關主題