[開箱] Chromecast 與 AVerMedia ExtremeCap UVC BU110

前陣子在研究 Chromecast sender app ，覺得一直把 Chromecast 插在電視 debug 很煩，想找看看能不能把影像輸入到筆電，可以方便開發以及擷取影像做 auto test 等機制。當時跟幾位朋友請教後，正逢雙11特價，就下標 圓剛 BU110 免驅動影像擷取器 ExtremeCap UVC，那時朋友推薦只要購買 USB video class（UVC）產品即可，免安裝驅動程式！剛好這款價格最低，且在沃草的朋友也都靠這款直播 XD 就...衝了。





這款設備大小很隨身（但還要帶著 USB Type-C 的線...），金屬觸感簡約精美散熱佳，但要小心，一旦手滑掉到木桌肯定會凹個洞

結果就是功課沒做好，圓剛 BU110 搭配 Chromecast 基本上就是黑畫面無誤，只有 Chromecast 開機畫面會顯示 G logo 開機動畫，接著立馬黑畫面無誤。追蹤一下，搞懂了是 HDCP 的問題，而圓剛 BU110 本身不支援 HDCP 機制（或許該說這類產品不該有 HDCP 機制？），因此跟數位內容保護相關的產品，如 Chromecast、藍光播放器等等，應當都會進入黑畫面。



這時我才腦補完為何 Chromecast 黑畫面，俗稱： Chromecast 發現影像輸出的對象不支援 HDCP 架構，避免被內容被側錄而進入黑畫面。這做的真不錯，這樣就讓內容提供者可以安心信任 Chromecast 裝置，可以確保一般用戶無法複製內容。

那...身為資訊阿宅，就在多逛逛拍賣網，看到了玲瑯滿目的 HDMI 影像聲音分離術 :P 那其實就是破解 HDCP 的招數啦，買一買串一串，的確就達成 macOS 用 QuickTime player ，透過 UVC 把影像顯示在電腦上了！



只是下一刻才驚醒...這種 debug 真的蠢了點 XD 電腦還得看 IDE 顯示運行的 logs 啊，還是搭配投影機或雙螢幕吧，且還有一堆線，非常原本想省個螢幕或電視，最後發現良藥是微投影機...

更多資訊：

• Chromecast Ultra 4K Ultra HD - 2016/11/06 發表 Chromecast 第三代 1080p 60fps - 2018/10/10 發表
• Chromecast 第二代 1080p - 2015/09/29 發表
• Chromecast 第一代 1080p - 2013/07/24 發表
• Chromecast 與 AVerMedia ExtremeCap UVC BU110
• Chromecast 與 微型投影機 EZCast Beam J2 提供 Netflix 大螢幕投影

[NodeJS] 透過 Wget + HTTP Proxy Server 架構進行 Content 分析

前陣子研究抓取資料時，發現 web crawler 搭配 proxy 時，可以在 proxy 這層進行資料的處理、分析，就一直思考到底要用 python 還是 node.js 測試，最後，實在是 node.js 方便許多，就...衝啦。

在進行之前，小提一下 Proxy Server 本身就有 Internet Content Adaptation Protocol (ICAP) 機制，其實只需要架一個 Squid 在寫一些 ICAP 即可達到類似的效果，有興趣可參考：[Python] 使用 PyICAP 淺玩 ICAP 與 Squid (以 Response Modification / RESPMOD 為例) @ Ubuntu 12.04。

對於沒開發過 node.js 的我，就先參考 node-http-proxy 的目錄結構建立起來一個 open source：node-content-filter-proxy。

這兩天抽空把玩的心得：

• 支援 HTTP Requests
• 尚未處理 HTTPS Requests

抽取 <a href="...">...</a> 用法：


$ cd node-content-filter-proxy/examples && npm install
$ clear;node extract-hmtl-a-href.js
1 Jun 10:20:22 - Service Running at 3128 Port

透過 wget proxy usage：

$ http_proxy="http://localhost:3128" https_proxy="http://localhost:3128" wget -qO -  http://www.google.com/
<a href="http://www.google.com.sg/imghp?hl=en&tab=wi">Images<a/>
<a href="http://maps.google.com.sg/maps?hl=en&tab=wl">Maps<a/>
<a href="https://play.google.com/?hl=en&tab=w8">Play<a/>
...

簡單的說，想要透過既有的 crawler (wget) 去下載資料，但是，資料中我只對 hyperlink 感到興趣，所以透過 proxy server 更新成只回傳 hyperlink 就好，維持 hyperlink 結構可以讓 wget --recursive 抓資料。

如此一來，原先 crawer = wget 架構，轉形成 crawler = wget + proxy server + content analysis 模式，可以專心擺重在內容分析，不必從頭刻一隻類似 wget 的程式。

最後一提，在 extract-hmtl-a-href.js 範例中，採用的不是透過 regular expression 去分析 link ，而是接近一隻 Javascript Rendering Engine (cheerio) ，所以未來可以做的事更多了 :) 至於效率部分倒還好，畢竟 crawler 抓太快會被 ban 掉，此外，分析 content 時，也能設計複雜更高的 seed list (回吐  hyperlink 時)，能避開 DOS 現象（例如限定某個 domain 、網站一天只抓2000筆等）。