簡介
1.IdleSignalMultipleAccess--空閒信號多址
MPEG2TS與ISMA的比較
1．目的比較
ISMA僅是為了Internet上的流媒體服務而做的標準，因此其目標是網際網路上的低碼率點播節目和低並發率。TS則是媒體行業通用的標準，其目標是基於寬頻的數字視頻廣播，並且支持多種基本媒體流和多種媒體編碼標準，已經有十多年實際的大規模普遍性套用，得到全球廣播行業和網際網路行業的一致認同。而ISMA的歷史相對較晚，且在行業上的認同度較低，也沒有大規模的部署案例。
2．StreamingServer的兼容性與升級
a)檔案格式的兼容性
在ISMA中，不同的編碼標準有不同的檔案格式，比如MPEG-4和H.264的檔案格式都不一樣，因此在檔案格式上是沒有任何兼容性的。而TS的存儲則與媒體編碼格式無關，MPEG-2TS可以將任何格式的內容封裝到它裡面。在對TS流進行存儲時，只需將其進行分段處理，然後加上Index信息，並與TS流共同存儲即可。因此採用TS流的檔案格式具有更好的兼容性，這對IPTV平台的平滑升級來說，是一個完美的解決方案。
b)流格式的兼容性
i.ISMA1.0/1.1與ISMA2.0
體系架構區別較大，升級困難，主要表現在以下幾個方面：
?ISMA1.0視頻基於MPEG-4Part2，以SP和ASP為基礎，並沒有涉及到H.264,而ISMA2.0則是基於H.264；
?ISMA2.0不兼容ISMA1.0，即ISMA1.0的servers和Clients不能平滑升級到ISMA2.0系統具體原因表現在：
?視頻RTP包的封裝模式不兼容：ISMA1.0的視頻RTP打包遵循“RFC3016：RTPPayloadFormatforMPEG-4Audio/VisualStreams”，而ISMA2.0的視頻RTP打包符合“RTPPayloadFormatforH.264Video”（目前該RFC沒有正式發布），加入了一些特有的限制和擴展，如不允許採用交織模式、不允許通過RTP包傳輸視頻序列參數和幀圖像參數等；
?SDP訊息格式不兼容：由於ISMA1.0和ISMA2.0視頻RTP打包方式的不一樣，導致SDP的訊息承載格式和內容也不一樣，如交織模式的定義參數不能在SDP訊息中出現，有關視頻序列參數和幀圖像參數通過SDP傳輸、增加了一些特有的域等；
?檔案的存儲方式不一致：ISMA1.0基於MPEG-4Part14（*.MP4），而ISMA2.0的檔案格式基於MPEG-4Part15(*.avc1)，對ISMA1.0的檔案格式進行了擴展，如H.264的參數存在檔案中的AVCDecoderConfiguration等。
ii.H.264
目前H.264專業級編碼器主要是以TS為主，而支持H.264的ISMA2.0剛出來，還沒有支持。
3．處理方法和性能
a)處理方法
ISMA的處理方法是：從編碼端到解碼端的所有環節，均需建立多個音視頻和其他數據流的RTPSession，因此在做StreamingServer的I/O時，需要管理多個輸入輸出，多個Buffer的管理以及它們之間的同步，將極大地增加StreamingServer的處理能力要求，也帶來了較大的算法複雜性，同時降低了系統的穩定性和可*性。而TS則將多個音視頻和其他數據流復用在一起，僅需建立一個RTPSession，因此在做I/O，Buffer管理和音視頻同步等方面將會簡單和容易得多。
b)連線埠需求
在NAT和防火牆上，ISMA需要為音視頻RTP分別分配連線埠，是TS流的兩倍。
c)性能
從上面的處理方法可以看出，用ISMA標準需要管理更多的RTPSession，要管理更多的I/O和Buffer，將極大的消耗StreamingServer和STB的CPU性能和記憶體，從而嚴重地影響系統的性能。根據Darwin系統及其實驗，我們在一台高性能機器上，也只能跑較少的Stream並且會有掉線情況發生。若採用TS流，則會支持幾百個2M以上的Stream並且不會掉線。
d)AVSync
ISMA的AVSync是依*RTP中的TimeStamp來實現，因此在同步時，需要等到音視頻的RTP都到達後才能實現AVSync。而TS流則不存在此問題，因為其時間信息都在一個流中。而且TS的AVSync只需在編碼和解碼端實現，中間的其他環節，如流伺服器等，不需要參與，可以降低StreamingServer的算法和處理複雜度。ISMA則相反，不光需要編解碼器，同時需要StreamingServer參與AVSync的處理，消耗了StreamingServer的資源，增加了算法複雜度和性能代價，並且降低了系統的可*性和穩定性。
e)解碼端
用ISMA對解碼器的要求也比TS流更高。TS流的主要工作是在解復用上，即解復用器需要分析PSI信息，然後根據PSI信息獲取音視頻的PID，在通過PID濾波，得到視音頻流，輸出到各自的Buffer中。由於TS是固定的188位元組包結構，因此PID在包中的位置固定，濾波很容易實現。根據我們的評估，採用軟體TS流解復用的方法，在EquatorBSP-15平台上，占用的CPU資源不足5%。而用ISMA時，由於多個RTPSession，因此需要有多個Buffer，並對其管理。所以採用ISMA時使用的Memory和CPU資源也更多。
4．對直播的支持
a)頻道切換
若採用ISMA方式，在LiveTV做頻道切換，STB需要從系統中重新獲取ISMA的檔案頭。因為STB解碼時所需的很多信息在此檔案頭中。所以系統還必須還有一整套ISMA的檔案頭的生成和管理。同時還會造成解碼頻道切換的延遲。
在LiveTV做頻道切換時，STB還需要獲取SDP以便得到解碼所需要的一些具體參數。再加上傳統的ISMA流中I幀間隔較長，一般多於4秒，從而造成STB的頻道切換時間長，完全不能滿足電信標準規定的2秒鐘。
b)直播參數的改變
在做LiveTV時，如果編碼器的參數被修改了之後，需要STB與編碼器或StreamingServer重新建立RTSPSession，以獲取新的SDP，然後才能從SDP中得到解碼所需要的一些具體參數。而在TS流中，所有的解碼參數均是伴隨著碼流一起下來的，因此不需要建立另外的Session，解碼器反應速度會更快。
5．Trickmode和DRM
a)在ISMA中，沒有一個關於Trickmode的詳細的定義，特別是在RTP中。因此各個廠家的Trickmode定義都不一樣，導致沒有一個統一的標準，標準也就失去意義。若採用TS流的方式，則我們可以在其extension中詳細定義Trickmode的相關信息，可以定義該RTP是Trickmode還是正常播放，以及Trickmode的具體模式等。同時還可以通過擴展，定義丟包重傳機制，保障用戶的服務質量。
b)在ISMA中，雖然定義了DRM採用AES的加密方法，但其DRM不具有擴展性。表現在：不支持多種DRM方法和加密標準，不支持對Key的管理。而TS則剛好解決了這一點，可以在RTP的extension中可以定義Key的管理方法和映射關係，以及不同的DRM方法和標準。使得系統在DRM方面具有廣泛的兼容性。
6．內容考慮
a)CP的支持
目前，大部分CP都是電視台、電影公司和廣電公司，他們主要的片源都是採用MPEG-2TS流封裝格式。因此TS能更好的適應CP的主要現狀和需求。
b)專業編碼器支持
目前全球的主要專業編碼器如Tandberg，Harmonic等都支持TS流封裝格式，只有少數廠家支持ISMA流格式。
7．晶片支持
目前，所有的MPEG-4和H.264的解碼晶片均支持TS。所以選擇TS可以為STB提供更多的選擇方案，利於降低STB的成本。
8．家庭網路
a)STB要接入家庭網路，需要支持DLNA。而在DLNA中，MPEG-2及TS是必選標準。
b)目前家庭網路中所有的攝像機和數位相機均支持MPEG-2TS而不支持ISMA。
c)目前家庭網路中所有的DVR，編輯設備均支持TS，而很少支持ISMA。
9．傳統數位電視的支持
a)目前在廣電領域，DVB全部是採用TS流封裝格式。因此，若採用TS，可以做到與廣電領域完全兼容，特別是在STB上的處理方式可以完全一致，增加了IPTV與DVB的兼容性，這樣更有利於電信與廣電的競爭。
b)廣電的趨勢是今後支持H.264(MPEG-4AVC)，並採用TS流封裝格式。因此有利於我們平滑升級到H.264。則可以直接從衛星上接受信號並直接進入IPTV系統，不用轉碼。
c)TS是一個真正的開放性的標準，有利於實現真正的“三網合一”。
10．媒體匯聚和交換
採用TS格式，利於媒體的交換和匯聚。IPTV網路的最終目標是發展為內容交換網路。顯然，媒體檔案過大，並不利於內容的交換。而TS每個包只有188個位元組，格式固定，利於交換。同時，TS是媒體行業通用的標準，這樣利於媒體的匯聚，可以支持我們從網路的不同節點獲取內容，並匯聚成一個完整的內容。
