目前大部分廠家推出的IP視訊監控系統都是採用這種模式。這種模式的核心在於利用系統中獨立的流媒體伺服器或者某個裝置中的流媒體功能模組來實現視訊流的複製分發，從而實現視訊客戶端解碼播放，視訊解碼上牆，而系統中的儲存伺服器或者儲存功能模組則獲取流媒體伺服器轉發來的視訊，實現視訊儲存。這種模式本身也經過了一系列的演化和發展。

　　常見結構

　　圖1描述的就是基於流媒體轉發技術的IP視訊監控系統的常見結構。此時的儲存伺服器和流媒體伺服器都是一臺高效能的電腦。流媒體伺服器從前端攝像機獲取視訊流，然後將視訊流複製，分發至儲存伺服器。由於IP監控系統中，儲存的要求基本上是全天候實時儲存，所以，這路分發給錄影儲存伺服器的視訊流將是源源不斷始終存在的。如果客戶端軟體或者解碼器上牆需要實時視訊流，則流媒體伺服器再會複製一路或者若干路視訊流給客戶端和解碼器上牆。

　　流媒體伺服器從前端攝像機獲取視訊流，然後將視訊流複製，一路肯定會分發至儲存伺服器。由於IP監控系統中，儲存的要求基本上是全天候實時儲存，所以，這路分發給錄影儲存伺服器的視訊流將是源源不斷始終存在的。如果客戶端軟體或者解碼器上牆需要實時視訊流，則流媒體伺服器再會複製一路或者若干路視訊流給客戶端和解碼器上牆。這種結構中，工作壓力主要在流媒體伺服器上，一臺伺服器的轉發能力是有限的，如果系統中是高清攝像機，轉發數量將有明顯下降。再說儲存，系統的儲存功能主要由儲存伺服器和磁碟陣列來完成，儲存伺服器作用在於從流媒體伺服器獲取視訊流，然後將其打包成檔案的格式再發送至磁碟陣列儲存，這裡儲存伺服器和磁碟陣列將有兩種連線方式：一種是通過IDE或者SATA線纜直接連線，即DAS方式;另一種方式就是通過網路方式，即NAS/IPSAN方式。

　　上述結構最大的問題在於系統中伺服器的數量將會很多，對於多點數的大型監控系統尤其如此，這顯然會增加系統的成本和維護複雜度。同時由於流媒體伺服器和儲存伺服器均為普通PC式伺服器，其中執行的程式也基本基於WINDOWS開發，其在穩定性上也存在一定隱患。

　　流媒體模組和儲存模組整合的結構

　　圖2所描述的結構對早期結構進行了一些改良，主要就是將流媒體伺服器和儲存伺服器作為兩個獨立的功能模組合二為一安裝在一臺伺服器上，這樣做既減少了系統中伺服器的數量，而且通過計算機內部的匯流排將視訊流交給儲存模組，減少網路頻寬壓力，同時儲存模組獲取流媒體模組轉發的視訊流也更加可靠穩定。但是，儲存模組將視訊資料處理成檔案包後仍將通過網路傳送至磁碟陣列儲存，這仍然會消耗網路頻寬資源。

　　加入嵌入式NVR的結構

　　為提升儲存部分的穩定性，嵌入式NVR出現了。嵌入式NVR在結構上將原來的NVR伺服器和磁碟陣列整合起來，一般是伺服器機頭加若干盤位的儲存構成，系統內的軟體也由以前的基於WINDOWS的儲存軟體改成嵌入式軟體，執行更加穩定可靠，伴隨著嵌入式NVR的面世，相當一部分IP監控系統的結構演變成圖3描述的形式。

　　由於早期嵌入式NVR只具備儲存功能而不具備轉發視訊的功能，所以系統中的流媒體伺服器繼續存在，但是儲存部分則變成了一體式的嵌入式NVR裝置，除了儲存執行更加穩定可靠，NVR獲取到流媒體轉發來的視訊流後餘下的工作均在本機內完成，不再把視訊資料發到網路上轉給獨立的磁碟陣列，這就降低了網路頻寬的壓力。

[nextpage]

　　不帶流媒體轉發伺服器的結構

　　嵌入式NVR很快變成了IP監控系統中一個非常重要的部分，除了儲存功能，更多的功能被新增到嵌入式NVR上，其中最重要的就是視訊流轉發功能和視訊管理功能，原來系統中流媒體轉發伺服器將不再需要，視訊管理功能使嵌入式NVR具備單獨構成小型系統的能力，在類似小區，連鎖店之類的專案中，嵌入式NVR就是系統的核心，具備IP數字監控系統的一切主要功能，在大型系統中，嵌入式NVR將作為一個基本組成單元融入整個系統。這也是目前主流的IP監控系統結構之一(如圖4)。

　　系統中除了管理伺服器不可或缺之外，嵌入式NVR成了組成系統的基本單元，其具備視訊轉發和儲存功能。這些NVR單元通過配置，直接從所管轄的前端IP攝像機獲取視訊流，如果外界沒有實時瀏覽的需求，則直接將這些視訊流變成檔案包存入本機內的磁碟陣列，如果有來自客戶端或者解碼器的實時瀏覽需求，則響應這些需求，複製另一路或者若干路視訊流轉發至客戶端軟體或者解碼器。整個系統的結構更加簡單清晰，網路的頻寬壓力也有大幅度下降。

　　上述幾種結構其實本質相同，都是基於流媒體轉發技術來實現瀏覽和儲存。這幾種結構存在兩個問題：

　　瀏覽視訊流和儲存視訊流來自同一個源頭，應用起來不夠靈活

　　具體地說，在這種基於流媒體轉發技術的結構中，流媒體部分(不論是功能模組還是獨立裝置)只會從前端獲取一個視訊流，然後轉發給儲存或者瀏覽裝置。如果前端攝像機是高清攝像機，使用者存高清視訊，那麼瀏覽的也必然是高清視訊，一臺客戶端電腦解碼超過9路高清視訊可能就吃不消了。再者如果客戶的儲存空間有限，希望瀏覽高清視訊但是儲存標清視訊，在這種結構下如果不做特殊處理也很難實現。一個更實際的需求是高清視訊需要儲存，但是瀏覽時並不需要始終是高清視訊，當客戶端上開9畫面或者16畫面時，單個畫面是不是高清的已經分辨不出來了，此時完全可以顯示標清或者更小解析度的視訊，客戶端電腦解碼這些非高清視訊時將比較輕鬆，畫面的流暢度也更高，當切回單畫面時，才需要再顯示高清視訊。

　　目前解決這個問題主要有兩個方法。

　　一是流媒體部分通過管理伺服器偵測客戶端的多畫面數量，一旦發現客戶端設定為9畫面以上，則流媒體模組將高清視訊流進行裁剪，降為低解析度的視訊轉發客戶端，一旦偵測到客戶端恢復單畫面視窗，則重新發送高解析度的視訊流。但是這樣做會使流媒體模組的負擔進一步增加，在總資源一定的情況下，必然會影響到複製轉發視訊流的能力，同時，前端攝像機的高清視訊流最好也是支援多級別可裁剪的。

　　另一種方法是藉助前端攝像機的另一路碼流，目前高清攝像機一般都至少支援一個高清碼流和一個低解析度碼流輸出，當流媒體模組偵測到客戶端開多畫面視窗後，則重新從前端攝像機獲取一個低解析度的視訊流進行轉發，同時斷開原來轉發的高清視訊流，這樣做有時會造成客戶端進行多畫面單畫面切換時，出現短暫的無視訊現象，在採用無線裝置傳輸視訊時這個現象可能更明顯。

　　NVR儲存模式不夠靈活

　　在這種結構下，每臺NVR都會管理一定數量的前端視訊，具體地說，就是每若干路視訊往一臺NVR裝置裡儲存。雖然嵌入式NVR比以前的PC式NVR要穩定很多，但是若某一臺NVR發生故障，被這臺NVR管理的若干路前端視訊都無法錄影了，後來採用N+1的模式使這種問題得到一定程度的解決。N+1模式就是除了必要的若干臺NVR之外，系統中再熱備一臺或者多臺(一般為一臺)NVR，平時這臺NVR不工作，只是處於預備狀態，一旦管理伺服器檢測到某一臺NVR故障或離線，則向熱備的NVR發出指令，熱備的NVR則主動接管受影響的前端攝像機，把視訊資料儲存在熱備的NVR內，同時系統報警，提醒維護人員去檢查維修故障裝置。一旦原來故障的NVR修好或者重新上線，熱備的NVR會把本機內儲存的視訊通過網路送回給原來的NVR，同時原來的NVR重新接管相關的攝像機，熱備NVR在傳送完視訊資料後繼續處於熱備狀態。但是系統中如果有更多的NVR故障怎麼辦?到底要熱備幾臺NVR?目前主流的廠商都基本只支援N+1的模式，即只允許一臺NVR故障。