無版權謂之非法

如果你想要長長久久的穩定運營 IPTV 系統的話，請合法取得所有要播放內容的版權，如果無法取得的話，那就直接放棄作 IPTV 吧，我們看過太多的大哥，因為作盜版的 IPTV 後，機房被抄，公司被告，產品下架，大前年 2020 年最有名的就是 TvPay ，就因為部份節目內容沒有版權，硬生生的被抄，還有 Yes 5 TV，千尋，樂活 TV ，全視福，金雞母，嘉博，雲瑛，第五台 … 等，族繁不及備載，大陸的廠商更是不計其數

各位大哥及各位大老闆，請清醒一點，如果你沒有版權要怎麼在臺面上賣 ? 又要怎麼作到 30 萬戶呢 ? 這是一個很跟本的問題，為了談版權與找機上盒我花了 8 個月時間，全台跑透透，問了好幾個版權商，當你知道一個頻道一個月一個人頭的就要 4-5 元，Mini guarantee 要 5 萬戶時，你在還沒有任何客戶的狀況下一個月就要付出 20-25 萬，你有多少錢可以燒 ? 而這只是一個頻道，有些頻道的首次授權費用就要 200 萬，多少人頭再算，雖然有些包裹式的授權商可以一次 15 or 20 個頻道授權，但一個人也要 20-30 元一個月，就小算一下，120 個頻道的 IPTV，如果要合法版權的話大概要 450 元左右的授權費用，那有人問說凱擘，中嘉，北都是怎麼賺錢的 ? 他們因為戶數很多大多是採用 15% Ｍini Guarantee 的方式來付錢，比如說，板橋，蘆洲，三重，新莊有 100 萬住戶，授權費用就以 15 萬戶的錢收，看起來好像還 OK，不過那是你有 15 萬戶或者是超過 15 萬戶的情況之下，才可以降低版權費用，不然一開始就要每個月付 15 萬戶的錢

在最後還有在作 IPTV 的幾年裏，很多大哥都來找我們要作 IPTV，但是我們都以貴公司無法取得合法版權為由拒絕了，也有人硬著頭皮要作，但都是小打小鬧成不了氣候，也因為如此，你在台灣看不到有百萬用戶的 IPTV 第四台服務商，頂多就 3-4 萬戶，再大應該就會被版權商盯上，或者是電信警察直接抄了

無頻寬成不了 IPTV

在台灣如果你要作 IPTV，有解決的版權問題，再來就是頻寬了，之前千尋在台灣不過 3 萬多戶，就因為佔用電信骨幹頻寬，硬生生的 40G 頻寬被抄，所以很多大哥與老闆都說，我們只要用 P2P 就可以解決頻寬問題，但是 P2P 怎麼 P 可是一個大問題，一Ｐ下去整個網路從北到南都被炸的亂七八遭，再加上骨幹設備要處裏這些北到南或者南到北的流量，你說電信公司不把你抄了才有鬼

如果要避免因為 P2P 造成的流量亂竄，應該改用 P4P 的定向點對點傳輸，也就是說如果在台北市北區的客戶，就在該北區自己 P 起來，不要 P 到台中高雄，如果在高雄南區的客戶，就在南區自己 P 起來，不要 P 到台北市，這樣不僅可以節省骨幹頻寬，也可以達到 P2P 省頻寬的效果，如果無法達到這樣的系統，請直接使用各地 CDN，讓用戶連接到最近的主機群出流，這樣可以達到分流及不會被抄的需求

有人問說那中花電信的 MOD 為什麼可以全省收視 ? 那是因為他們不是用 Unicast 的方式來作連接，而是採用 Multicast 的廣播方式來連接，所以在骨幹的頻寬使用上來說會很節省，也可以在各地的 CDN 主機作發布, 說明如以下圖片資料 

串流防盜用

串流的保護工作除了驗證外，比你想的還要更多，一般基本的驗證不外乎就是是用戶或者 Token 的限定，但是在 Internet 上面來說是遠遠不夠的

1. 線路斷訊備用 : 在跨國服務中最常發生就是海纜有問題或者是頻寬阻塞，為了保證串流正常推用與發布，必須要有備用的訊號來源，一般我們會採用雙串流備用，或者是將各頻道交插在 4-5 路的路由主機，讓線路斷訊時不會造成所有頻道的斷訊，而也因為這樣也會造成一些成本上面的增加

2. 即時封鎖 : 在第一時間發現有異常串流輸出或者是異常連接時，就需要馬上將該 session 給斷開，並封鎖該來源 IP 及帳號，這樣可以在流量發生異常時作處理

3. 串流出流套餐驗證 : 用戶的帳號密碼是基本款，還有該用戶是否有盜用其他套餐的驗證，之前有很多大哥很喜歡作免費收視頻道，結果一堆人都用免費收視頻道的方便性通過驗證，然後因為串流沒有再作二次的套餐驗證，活生生的就全部免費了，所以在每個頻道出流前一定要作二次的套餐驗證

4. 串流出流的 IP 驗證 : 當有一個用戶在網路上面來了 10-20 個 IP 時，那就代表說你的串流被盜了，這個問題需要在串流主機上面持續紀錄來源 IP ，如果只有開放兩個設備可以用，那超過部份的 IP 就不可以出流，如果還是出流的話，就只要到網路上面公告播放地址就可以盜到訊號

5. 串流出流的用戶驗證 : 除了使用者的帳號與密碼外，用戶的唯一性要確認，不可以因為有了帳號與密碼就到處可以播放串流，那就失去保護的意義

6. 串流主機 : 因為 IPTV 的大量併發及傳輸，再 Linux 底層需要作修改，讓 TCP/IP 運作及主機運作順暢，還有驗證資料庫主機的 Cache，如果不開大的話，應該是頂不住大量的用戶使用

7. DDos : 為了保護串流主機群的安全，上 CDN 及分散多台主機及地點是必需要的，因為沒有分散的話很容意就因為單點攻擊而造成系統停服

8. 傳輸加密 : 串流的地址及帳號密碼被盜都是常見的問題，所以必須在取得資料前就將該資料加密，AES 128 是一個不錯的方式，因為需要有動態 Key 才能夠解，如果沒有的話就無法解，再加上動態的密碼，動態的 IV，這樣可以確保當節目地址流出後，第一時間失效，也不用怕到處論壇都是被盜的播放地址

9. 推流驗證 : 為保護串流主機及不被竄改的情況下，RTMP 的推流需要經過驗證保護後才能夠推流成功，不然隨便阿貓阿狗都可以在知道主機位址後就把串流打上去

10. 主機系統安全防護 : 目前全系統都採用 Linux 主機平台，主要是因為資源吃的比 Window 少，且大部份 Open Source 的程式都在在 Linux 上面運行，再加上不需要版權這一點，我們全面服務都是採用 Linux 系統，在主機上面需要作到幾點 : (1) 將不需要的服務關閉 (2) 開啟防火牆只有將需要用到的 port 打開 (3) 保持更新 (4) 使用安全的系統套件源頭更新如 epel-release (5) 給串流主機足夠的 CPU 及 RAM

11. 平行併發 : 因為大部份的 RTMP 或者是串流服務都是單一行程，如果想要服務更多客戶的話就需要將原本程式平行併發，一般我們在主機上面會啟用 10-15 個 Process 分別監聽或者是統一監廳一個使用 Port，用以擴充單一程序的不足

12. 主機連接安全限定 : 之前有遇過很多服務商，因為工程師操作完系統後忘了開啟防火牆，造成整台主機被盜用，所以應該是全部封鎖連接 IP ，然後限定可以使用的 IP ，這樣就不會有忘記的狀況發生，當然很多主機都會用 SSH Key 的方式直接登入，但是如果 KEY 被盜用的話，你的主機就謝謝再聯絡了.

13. 工程師資安教育 : 不要相信在網路上面與你聯絡的任何一個人，駭客可以透過 QQ WeChat Line … 等通訊軟體，入侵或者盜用工程師的電腦，當取得電腦控制權後，工程師所控制的所有主機將會被完全盜用，不要相信任何防毒軟體或者防木馬軟體可以保護你，都是沒用的，除非你遇到是很 Low 的駭客  

雲端串流主機群

在每一個國家的主機群，都不會是只有一台伺服器，需要由多台伺服器來組成一個 24×7 的主機服務群，特別是串流主機需要很多台來服務客戶，以免大量連線出現時客戶無法使用，當然也要避面因為單一主機有問題時需要作到的備援功能

這個坑我們可是換了很多套系統後才在 2017 年完全穩定下來，因為不是只有串流要發布，還有每個發布都要作驗證，如果沒有驗證的話，可是會讓所有人看光光，這個對於一般宗教公開頻道來說是再好不過的，但商業頻道來說可不得了，因為不僅收不到錢還會造成整個系統的 Loading 過重，影響到其他正常的用戶

在剛開始的全視福是採用 RTSP 的串流服務，所以該串流常有影音不同步的問題，再加上畫質應該只有 360P 所以整個收視體驗非常的差，改用彩虹直播後狀況改善，但是因為該串流主機是由原力的 FDBS FCCS FTDS 三個程式組成的 P2P 發布系統，整個就是一個沒保護，只要有原力的播方器知道地址就可以順利的播放出來，你說這樣要如何保護串流呢 ?

後來為了改善以上的缺點我們改用了 RTMP 的串流服務，雖然是一個 Flash 時代的古老串流，但是穩定度確非常的好，特別是在目前的所有雲端串流服務商都有支援其推流，且因為他是採用直連方式收視，所以我們只要在客戶連到串流主機上面作驗證就可以了

 目前如果有需要作串流服務的客戶或者是廠商，可以採用我們的雲端主機服務，該服務可以在客戶沒有主機沒有頻寬的情況下，作內容的發布與串流

全球 CDN

如果作 IPTV 沒有用到 CDN，那應該代表客戶數不夠多，不需要作分流與分散負載，因為大部份的客戶都分散在全球各地，如果只依靠單一國家的機房頻寬或者主機群服務，一定會有跨國及效能上的問題，且如果一個日本客戶要連到南非或者德國機房收視的話，單就跨幾個國家的線路穩定度就是一個大問題，小貓幾隻時還可以硬撐，但是當多人同時併發使用時就會一個很嚴重的問題

IPTV 要大規模採用 CDN 的主要原因有以下幾個 : 

1. 分散使用流量 : 將單一頻道的訊號傳到客戶要使用的國家，然後再透過該國家的 ISP 來提供本地的訊號輸出，這樣可以保障單一串流在跨國時可以用少量頻寬傳送，且到當地國家後作大量的使用併發

2. 減少攻擊 : 如果幹過 IPTV 這個行業的人都知道，Internet 上面就是有很多的人，每天閒閒沒事作，到處探測主機漏洞，到處盜取資源，如果有上過暗網的人客應該知道，每個攻擊或者是入侵都是有行情價的，所以要拉個 1-2 Gbps 的頻寬打爆你的主機群，對於專業的駭客來說是很容易的，所以如果有 CDN 將服務分散的話，就可以在單點受攻擊時請客戶切換到其他主機群使用

3. 降低成本 : 這個地方說的降低是你的客戶群要有一定的數量，如開號 2-3 萬人, 或者即時在線人數 6-7 千人以上，這樣建置全球 CDN 就可以降低成本，反過來說客戶數只有小貓兩三隻的話，那全球機房及頻寬的租用將會是一筆很大的成本

4. 增加客戶使用體驗 : 跨國的海纜因為距離長，所以一定會有封包的延遲，這樣的延遲在客戶開啟 APP 或者作頻道切換時都會造成等待時間，所以如果可以直連到當地的主機群，那出流及使用上來說是最快的，那年大家都想要作一個秒開的 IPTV ，但是在網路部份都沒有優化，所以只有少數幾家的廠商能夠接近秒開，就算有秒開也是先弄個靜態畫面先，然後再出流

APP 量身訂製

整個 IPTV 系統中很關鍵的一個部份就是使用者 APP 的開發與設計，但是要設計一個好的 APP 還真是有點困難且會有一大堆的坑等著你，主要考量的部份有以下幾點 : 

1. 作業系統平台選擇 : 當時整個業界最流行的機上盒及手機系統就 Apple 的 iOS 及 Google 的 Android，那時一度以為 Microsoft 的 Mango 也會參與這場移動裝置的大戰，還好最後退出市場，不然可能會累死工程師，因為 Apple 採用 Object C 開發設計，Google 採用 Java 設計，兩個開發工具也不一樣，雖然有很多的公司開發出跨平台的設計軟體，但因為需要客製化的地方太多就沒多少人採用，很多老闆都想要作一個雙平台可以用的 APP ，但是 Apple 的 App Store 在版權審核這關就過不去了，就不可能上架成功，所以大部份地下非法 IPTV 都是以 Android 為主要開發系統，行有餘力才作 iOS 平台，除了版權原因外，P2P 的播放器有沒有支援 iOS 也是另外一個問題

2. 作業系統版本選擇 : 話說那年的機上盒，能夠有個 Android 2.2 或者是 Android 4.0 就已經是很神奇了，因為每個版本的 API 不同，所以就會半強迫開發商升級到更新版的 Android，除非是作向下相容的處理，並降低 API 版本，這樣才可以在所有機上盒面運作

3. 開發語言的選擇 : Android 因為 Java 的版權問題被 Oracle 告上法院，逼得 Google 改用 kotlin 取代 Java，但是為了協同運作及開發的簡易性，我們當時全部統一採用 Java 以避免程式上面的混亂與不相容

4. APP 介面的設計 : 一個好的 APP 需要讓用戶方便操作與使用，很多公司要求我們開發的 APP 都是卯起來加一大堆的功能，當老闆的都想要把一堆有的無的功能加到 APP 上面，甚至還要在電視上面購物，整個操作介面多如牛毛，且用不到，一般人買機上盒回家，應該就是看直播不然就是點播，只要兩隻 APP 或者是兩個整合成一個， 之前安博及小七都是用兩個 APP 來裝到機上盒，最近幾年都是直播加點播合在一起，當時有很多的框架或者說開放程式可以使用，也因為這樣讓很多家的 IPTV 業者降低了進入的門檻

5. APP 防盜保護 : 因為 Android 的 APP 都是用 Java 開發，且安裝檔 .apk 本身就是 zip 的壓縮格式， 所以只要解包並反組譯後就可以取得 apk 的原始程式，那時很多破解版的 APP 流出，除了可以正常使用外，其實都含有大量的木馬及後門，等您一安裝後，您的設備及資訊就被接管了，這個問題在 Andorid 5 後才漸漸得到改善，加強了簽名認證還有不允許不明程式安裝，除此之外 APP 本的程式的混淆也是可以達到一定程度的延緩破解，在最早的 IPTV 系統，資料傳送都是採用 HTTP 的明碼傳送，有些會作點 MD5，但這些對於駭客來說都太簡單了，我們是全台灣第一家採用 AES 128 bits 加密封裝資料傳送的開發商，且每次的 Key 都動態產生，除非你要正確登入取 Key ，不然是無法用之前的 key 解出我們 EPG 送給 APP 的資料

頻道 EPG 管理系統

整個 IPTV 系統的控管都要靠 EPG 管理系統，這部份可以說是創意人資訊的強項，也是我們跳坑燒錢的前三名，雖然我們有自己的主機還有軟體設計工程師，但是事情是像一般人所想的這麼簡單，除了 Web 開發的管理系統外，還需要作到以下幾個部份 :

1. 全球 CDN 發布 : 因為 IPTV 的客戶是跨國界的，不是在單一國家與網路系統中，所以如果您只有一個主機群服務，絕對是會出問題的，因為單承載多人同時併發就會發生 session 不足的問題，再加上駭客攻擊的話，只要 EPG 掛整個 IPTV 系統就無法服務，用戶就無法登入作驗證，當然 APP 也就無法使用

2. API 設計 : 管理系統是看的到的，除了管理系統外 APP 和 EPG 溝通是透過標準的 RESETFUL 規格來通訊，所以還要製定每一個 API 的接口，讓 APP 能個正常的與 IPTV 溝通，這只是對用戶端，串流主機的防盜連及驗證保護 API ，也是要連到 EPG 管理系統上面，所以在一個萬人併發的系統來說，API 設計非常重要

3. 廣告推播系統 : 如果你問那些作 IPTV 的大哥，除了想要拿執照外，第二個都想作的就是線上廣告系統，每個人都想說我有個幾萬戶客戶後，就可以賣廣告賺錢，有關這個問題我有幫艾克斯問過，當時整個系統有開了 6 萬多個號，有使用的大概 8000 個號，再把分散在全球各地的因素考慮進去後，單一國家或者單一地區大概也就幾百個客戶，也就是說這對廣告商來說是無效的廣告目標群，因為除非你是跨國企業，不然台灣的寬頻廣告在加拿大是沒用的

4. 頻道套餐管理 : 依照不同的使用者會給不同的節目頻道列表，看起來是再簡單不過的程式與資料，但是若牽涉到不同代理商有不同套餐，多用戶同時併發後發生的系統資源不足，這個問題在之前彩虹直播是採用 .zip 檔案方式，在 APP 登入後下載該 zip 檔案，然後就是所有節目的列表與圖標，但這樣確會造成整個節目更新後在第一時間就洩漏播放地址的問題，之後我們把用戶的套餐作暫存，然後再登入時取得 JSON 內容，其中把使用者的 session 及帳號密碼給放在節目地址，這樣就可以從地址來作防盜及辨識用戶

5. 儲值系統 : 原本的艾克斯及全球看都是採用一年一序號方式來作用戶開通，先把序號都開給代理商，當用戶第一次登入後綁定設備的 MAC，然後就可以驗證，但是 MAC 是會變且重覆，最嚴重的是會假造，所以我們在系統上面增加的點數儲值系統，原本的 MAC 也改用整個系統的唯一值辨識處理，這樣就可以在後台確認用戶的唯一性，改這樣的儲值後代理商就可以自行開號一天扣一點

6. 代理商系統 : 單靠一個人來賣直播是很硬的，所以大部份的 EPG 都有多層的代理商系統，如雙子星的後台，就有和我們一樣多級的代理機制，除了能夠分層外還要讓上層的代理可以看到並管理下層的代理商

一. 訊號源分類

1. 類比訊號源 : 一般家中常用的 DVB-T (數位天線) 這個就是類比的訊號來源，早期台灣的第四台也是用類比訊號傳送，直到最近幾年才全面改為數位機上盒，類比訊號在網路上面是無法傳送的需要先由調變器把類比訊號轉為數位訊號，然有再作後續的編螞，還有早期的衛星的訊號也是用類比訊號傳送，後來改用數為的 KU 及 C 兩個數位波段傳送

2. 數位訊號源 : 一般電腦的檔案或者網路的串流都是數位的訊號，還有第四台及 MOD 機上盒輸出的 HDMI 介面，也都是數位訊號，應該之後所出的電子設備都會採用數位訊號傳送

二. 訊號內容

1. 電視台頻道 : 電視台製作的頻道內容，通常採用 24 hrs 直播加廣告，早期老三台時一天只有播幾個小時，直到有線電視普及後，才開始有 24 hrs 播放 

2. 電商產品介紹 : 因為網路發達，且頻寬增加，所以在網路上面介紹商品的內容，由圖片文字改為影片，所以也加大了 IPTV 的需求，現在產品的介紹如果沒有生動的影片，應陔很難賣的出去

3. 網紅直播 : 網紅如果沒有 IPTV 系統的幫忙，跟本不可能在網路上面紅起來，這個在 30 年前是完全無法想像的行業，因為那時 Internet 還不夠成熟，跟本連網路都還不普及，更別說會有人在電腦前唱歌在手機前表演給你看

4. 線上教育訓練 : 一間教室只能容納固定的學生，如果可以在線上直播老師的課程，那可以收視的學生就不在局限在同一個地方或者國家，且人數可以不限

5. 演唱會及表演 : 一個表演場地是有其局限性的，可以透過 IPTV 將訊號內容傳送到全球各地，只要整個系統運作完整，連非洲的南非，東南亞頻寬較小的國家，都可以透過 IPTV 傳送進去

6. 影片點播 : 電影，電視劇，短視頻，等線上點播都需要 IPTV 來幫忙傳送，內容只要能

三. 訊號採集編碼

1. 編碼規格 : 一般網路上面的編碼方式會用 H.264 或者 H.265 兩種方式來處理，通常如果要考慮較舊的設備，最好都全部採用 H.264，這樣相容性會比較高，且可以通用各種播放設備

2. 編碼格式 : 在跨國的網路頻寬通常超過 2.5M bps 就會有卡頓的風險，所以通常不會採用太高的碼流來傳送，早期廖董的艾克斯直播就是採用 8M bps 的碼流傳送，但在有時跨國頻寬發生問題時就會卡頓的很嚴重，且 8M bps 在光纖還沒有普及的年代，也是會有點吃力

3. 編碼設定 : 串流訊號分為兩個碼流，(1) Video 影片 (2) Audio 聲音，兩個透過 Timestamp 時間戳記來作影音同步，有一些串流的封裝方式如 UDP 或者 RTSP 就會常有影音不同步的問題發生，在目前大尺寸電視當道的市場，Video 最低需要 1280×720 的規格，Ａudio 最低需要 64Kbps 的需求，兩個合起來最少需要 2Mbps 頻寬傳送，如果要到畫質清析的話最少要 3.5Mbps

4. H.264 Profile : 一般常見的有 Base line ，Main profile ，High Profile 三種，如果編碼設備的效能可以支援的話，請盡量使用 High Profile ，因為該壓縮設定會用內插補點方式，讓動態畫面更清楚，不過這也需要有代價的，因為畫質高所有 CPU 運算也需要更多電力及效能，我們在 Xeon E5-2660 的伺服器上面編碼一路 Base line 直播頻道，大概會佔用 18-25% 的 CPU ，但是 High Profile 的話會佔到 35-40% 的CPU

四. 訊號編碼設備

1. 電腦 : 搭配各種的訊號卡，如 DVB-T 的接收卡，第四台電視卡，衛星接收卡，HDMI 訊號輸入將訊號輸入到電腦中，然後再透過 Nvidia 顯卡來作 GPU 的串流編碼，當然如果您的 CPU 夠力且有 2-4 顆的話，也是可以用 CPU 來作編碼，不過就電力使用及效能上來說，還是用高階顯卡來作 H.264 編碼效能最好，之前我們不知道，就買的 Nvidia 一般的顯卡來用，結果發現家用顯卡因為 H.264 的授權關係，所以都只能兩路硬體編碼，到後來改用 K4000 在整個編碼上來說效能提升，但因為 K4000 是偏繪圖用，最後改用 k2200 解決整個電腦編碼的問題

2. 專用編碼設備 : 市場上面有很多的串流訊號供應商，有一整台8路或者是16路的編碼主機，通常要價都不便宜，主要是因為串流解析度要求越來越高，早期的 360P 480P 都已經漸漸不夠，目前主流都是要 720p 或者 1080p 起跳，所以對於硬體的需求也就非常的高，很多廠商也因應這樣的需求開發出對應的產品，特別是中國大陸有很多作監控的場商，已經都作到 H.265 的基本配置了

3. 採集編碼盒 : 這是一種只有 HDMI 輸入，網路連線，電源，三個連接孔的小盒子，直接把 H.264　還有 H.265 作成 SoC 的晶片，也就是說整個盒子就是只編碼，盒子一般可以輸出 RTMP HTTP RTSP 等各種串流格式，所以在直播使用上來說很方便，且可以作到幾乎完全訊號同步處理，也就是你的訊號源輸出什麼直接就產生您要的訊號，主要的應用方式之後再專文介紹，下圖就是之前用的採集盒