市面上的娃娃機方案五花八門，daniulive認為最簡單靠譜粗暴價效比的方案如下：

RTMP攝像機-->CDN-->daniulive player(專門針對直播娃娃機開通了“超低延遲”模式，公網實際延遲在200~400毫秒).

相關播放器下載：

比快更快，效果輕鬆PK市面上“全球第一、國際領先”的各類技術方案。

最近接到最大的質疑是：為什麼只有大牛直播推薦這種rtmp攝像頭方案？

回答：我們不是做雲服務的，通俗點說，我們不是靠頻寬盈利的，我們期望客戶採用更穩定靠譜的技術方案，服務於更好的商業模式。

可能的其他方案：

PC機一臺或工業主機板(android或linux)，每個連線兩個攝像頭。

a) 操作娃娃機的使用者，走私有協議，來實現所謂低延遲抓取；

b) 其他觀看者，資料傳到特定伺服器，走標準協議，延遲1-3秒。

為什麼我們不採用這個方案：

1. 位元速率：以720*1280解析度，20幀碼流為例，如果以android板件或windows系統編碼，再優化的演算法也要佔用1.2M碼流；如果走rtmp攝像頭，因為攝像頭本身資料壓縮率比較高，碼流大概佔用在0.3至0.4M，也就是說，同一臺攝像機，同等解析度，碼流只有windows或android採集攝像頭編碼的1/4~1/3。
2. 成本決策：以1M碼流一天的流量費用1塊錢為例，1000個併發，走PC或工業主機板，頻寬成本1000元，rtmp攝像機成本250~300元。
3. 實際上下行頻寬：問題來了，上行1.2M的碼流好傳，還是0.3M更容易抗網路抖動？下行呢？答案不言而喻。
4. 平臺穩定性：娃娃機屬於24小時不間斷推送的，一般rtmp攝像機，可靠執行60天，出問題的概率遠小於PC或工業板件；
5. 隔離效應：

a) 攝像機單獨部署，網線直接接交換機，每個模組獨立，相互干擾的可能性為0；

b) PC或工控機連攝像頭，普通攝像頭(非工業級攝像頭)連續執行60天面臨功耗和穩定性問題；

c) PC或工控機，託兩路，上行頻寬2.4M，是不是能一直得到保障？如廠商考慮成本，順帶娃娃機控制模組也跑在這個板件，相互影響的概率是不是增大了？

質疑1：別扯了，我可以用480*640解析度啊，反正也能滿足娃娃機抓取要求，0.6M就夠了

回答：是的，兩路1.2M，如果rtmp，每一路大概0.13至0.2M，兩路0.3至0.4M，如果沒有使用者抓娃娃，場景不發生變化時候，你關注下哪怕是720*1280解析度下，rtmp攝像頭實際佔用碼流，小到嚇人。

質疑2：說了這麼多，你們只能用rtmp攝像頭嗎？

回答：我們有提供android工業主機板推兩路rtmp資料的方案，問題在於，這個頻寬成本和其他風險，你們願意買單嗎？

附錄2：大牛直播Android工業板推兩路效果

視訊演示