⑴ 請賜教，視頻監控存儲方案！
需要4台16路硬碟機
1路視頻大概200多M/小時
1台16硬碟機1天大概佔用75G左右空間，半年大概13500G，也就是13T多，現在硬碟機有的可以裝8塊，每塊2T，大概一共16T。
但是那麼多硬碟很容易出故障的，建議還是縮短錄像保存時間，一般是30天。
視頻矩陣是指通過陣列切換的方法將m路視頻信號任意輸出至n路監看設備上的電子裝置，一般情況下矩陣的輸入大於輸出即m>n。
做電視牆的話必須使用視頻矩陣，不然60個頭不好切換，不可能裝60台監視器的。
⑵ 瑞馳的視頻雲存儲解決方案怎麼樣
瑞馳的視頻雲解決方案很好啊，能解決用戶安全訴求，高可靠對象存儲保證用戶數據安全，視頻加密、播放鑒權、版權保護等多種成熟視頻加密技術，讓您高枕無憂。
⑶ 高清網路攝像機視頻監控系統主流存儲方案都有哪幾種各自的優缺點主流
目前應用最廣泛的專業高清視頻監控存儲解決方案主要有兩種，一種IP存儲方案，另外一種是NVR存儲方案。
NVR一般採用專用視頻存儲方式和特殊的文件系統：專業的視頻存儲方式和特殊的文件系統是針對視頻的特徵而開發的，可以提高存取效率，減少視頻碎片，節約硬碟資源。
NVR可以直接回放NVR的視頻，而不需要通過客戶端或平台。
NVR提供多級的管理服務，通過平台的授權後，本地操作員不必登陸平台的情況直接對本區域的視頻進行操作或管理。
總之，在高清網路攝像機視頻監控系統中具有成本優勢的是NVR，不僅可以提供系統的可靠性，而且提供視頻的專業存儲，非常適用於視頻監控行業的應用。
⑷ 抖音視頻為何無法保存有什麼解決辦法
手機空間不足和錯誤的保存方法會導致抖音視頻無法保存，正確的抖音保存方法需要將視頻保存到本地，具體操作方法如下：
1、以榮耀8為例，首先打開【抖音】APP。
5、最後看到視頻已經成功保存在了某個文件夾就可以了。
⑸ 公司現在要一個視頻存儲的方案
如果每次都80G那我覺得沒什麼辦法保存啊，只能加硬碟。是不是可以轉化一個比較下的格式呢？？讓它變成幾G的文檔不可以嗎？？
⑹ 視頻文件存儲的方法
我給你推薦個辦法啊，如果覺得視頻太大了，你可以用轉碼軟體先把視頻格式搞小點，這樣的軟體可以用TMPGEnc與Canopus ProCoder來處理。當然這個會犧牲畫質。
然後就是壓縮成壓縮文件了，推薦採用WinRAR，因為這個普及率高，不太容易有問題，採取固實壓縮和分卷，分成幾個部分，同時加密，你只要把其中的幾個分卷保存在一個地方，剩下的就算誰拿到了沒另外幾個部分都沒轍，這個比加密效果好多了。但是有一點，你別指望壓縮和解壓縮速度很快，因為視頻文件本身就是壓縮過的，大小不會有太大變化。
還有一種辦法用使用微軟的最新DRM數字版權軟體證書加密視頻，這個破解的辦法也比較難，比破解WinRAR難很多，按照微軟的說法，基本上無解。
⑺ 各大視頻網站的視頻存放在哪裡那麼多的視頻，得用多少存儲空間呀！
有專門的儲存機櫃及解決方案，容量大到無法想像，周期性會上架替換一批批的硬碟。機房遍布全國乃至世界。
--天下數據--
⑻ 大型視頻網站的技術架構方案
國內的不清楚,給你看看YOUTUBE的
YouTube 的架構擴展
在西雅圖擴展性的技術研討會上，YouTube 的 Cuong Do 做了關於 YouTube Scalability 的報告。視頻內容在 Google Video 上有(地址)，可惜國內用戶看不到。
Kyle Cordes 對這個視頻中的內容做了介紹。裡面有不少技術性的內容。值得分享一下。(Kyle Cordes 的介紹是本文的主要來源)
簡單的說 YouTube 的數據流量, "一天的YouTube流量相當於發送750億封電子郵件.", 2006 年中就有消息說每日 PV 超過 1 億,現在? 更誇張了,"每天有10億次下載以及6,5000次上傳", 真假姑且不論, 的確是超乎尋常的海量. 國內的互聯網應用,但從數據量來看,怕是只有 51.com 有這個規模. 但技術上和 YouTube 就沒法子比了.
1. Web 伺服器
YouTube 出於開發速度的考慮，大部分代碼都是 Python 開發的。Web 伺服器有部分是 Apache， 用 FastCGI 模式。對於視頻內容則用 Lighttpd 。據我所知，MySpace 也有部分伺服器用 Lighttpd ，但量不大。YouTube 是 Lighttpd 最成功的案例。(國內用 Lighttpd 站點不多，豆瓣用的比較舒服。by Fenng)
2. 視頻
視頻的縮略圖(Thumbnails)給伺服器帶來了很大的挑戰。每個視頻平均有4個縮略圖，而每個 Web 頁面上更是有多個，每秒鍾因為這個帶來的磁碟 IO 請求太大。YouTube 技術人員啟用了單獨的伺服器群組來承擔這個壓力，並且針對 Cache 和 OS 做了部分優化。另一方面，縮略圖請求的壓力導致 Lighttpd 性能下降。通過 Hack Lighttpd 增加更多的 worker 線程很大程度解決了問題。而最新的解決方案是起用了 Google 的 BigTable， 這下子從性能、容錯、緩存上都有更好表現。看人家這收購的，好鋼用在了刀刃上。
出於冗餘的考慮，每個視頻文件放在一組迷你 Cluster 上，所謂 "迷你 Cluster" 就是一組具有相同內容的伺服器。最火的視頻放在 CDN 上，這樣自己的伺服器只需要承擔一些"漏網"的隨即訪問即可。YouTube 使用簡單、廉價、通用的硬體，這一點和 Google 風格倒是一致。至於維護手段，也都是常見的工具，如 rsync, SSH 等，只不過人家更手熟罷了。
3. 資料庫
YouTube 用 MySQL 存儲元數據--用戶信息、視頻信息什麼的。資料庫伺服器曾經一度遇到 SWAP 顛簸的問題，解決辦法是刪掉了 SWAP 分區! 管用。
最初的 DB 只有 10 塊硬碟，RAID 10 ，後來追加了一組 RAID 1。夠省的。這一波 Web 2.0 公司很少有用 Oracle 的(我知道的只有 Bebo,參見這里). 在擴展性方面，路線也是和其他站點類似，復制，分散 IO。最終的解決之道是"分區",這個不是資料庫層面的表分區，而是業務層面的分區(在用戶名字或者 ID 上做文章,應用程序控制查找機制)
YouTube 也用 Memcached.