http://www.fame-ring.com/smart_cutter.html
- 7月 13 週四 201714:24
[轉貼] 轉檔軟體
http://www.fame-ring.com/smart_cutter.html
- 5月 09 週二 201710:58
pthread_cond_wait()的使用方法:
pthread_cond_wait()的使用方法:
- 4月 25 週二 201717:16
[轉貼] CMAF 的提出，還無解的 Video Streaming 的規格聖戰
CMAF 的提出，還無解的 Video Streaming 的規格聖戰
Apr132017
kkbox
所有的影音串流服務的營運單位都曉得， 日常的營運費用（OPEX）支出裏頭， 前三大的是支出分別是：
內容版權費是大老闆與首席內容官（Chief Content Officer）的事； 人事成本是營運長（Chief Operation Officer）與研發主管的事； 至於流量費嘛（以及與它高度相關的儲存空間費用）， 我們都曉得這是影音服務有別於其它網路業的最大支出。 流量費也是這一篇 blog 或這個 CMAF 標準在關心的議題。
從多媒體技術的觀點來看的話，現在的影音串流服務是怎麼做到的呢？ 以我微薄的知識與見聞來看，目前成熟的技術市場，大概是有以下的幾塊：
以一家有點規模， 平台有至少包含 Android, iOS, Web, STB, … 的 VOD (Video-on-Demand）服務來看， 一部影片，會因為上述的 1, 2, 4 這三點，少則要準備個 2 份，多則要個 3, 4 份。 然後 1 份裏頭，又會因為有 adaptive streaming 而有很多的 profiles， 然後一個 profile 又可能因為 media segmentation 而有很多的檔案。
以一部 60 分鐘的影片，10 個 profiles，5 秒為一個 media segment 來看：
video duration: 1 hour
segment duration: 5 seconds
adaptive profiles: 10 (audio and video)
media segments: 60 * 60 * 10 / 5 = 7,200
一份會有 7,200 個檔。
如果來個 3, 4 份的話，就是會有 21,600 ~ 28,800 個檔案。
這對於儲存空間來說，是一筆支出，但更嚴重的，是對於流量的支出。 原本，一部影片，CDN 只要 cache 個一份， 現在因為上述的原因，變成要 cache 個兩三四份，糟透了。 理論上，網路流量的支出是要高於儲存的支出的，而且高很多。 除非，你在經營一家沒有人看的影音服務…
2015 ~ 2016 年之間，兩大巨頭，Microsoft & Apple，坐下來談一件事。 他們針對上述的問題，做了初步的努力，這個產物就是 CMAF (Common Media Application Format)。 CMAF 繼續了 MAF 的特性（或說是美德也行）， 它並沒有定義任何新的技術或規格， 相反的，它是基於現在的技術規格下， *挑選（或限制）*出了一些規範（ex, profiles）來符合當下的軟硬體需求。
CMAF defines the encoding and packaging of segmented media objects for delivery and decoding on end user devices in adaptive multimedia presentations. In particular, this is (i) storage, (ii) identification, and (iii) delivery of encoded media objects with various constraints on encoding and packaging. That means, CMAF defines not only the segment format but also codecs and most importantly media profiles (i.e., for AVC, HEVC, AAC). – CMAF Scope
簡單來看，CMAF 決定了基於 ISOBMFF (or fMP4) 的 media segment 格式、 audeio 與 video 的 codecs、 以及字幕（subtitle）檔的格式。 但是它並沒有包含 adaptive streaming protocol， 所以使用 HLS 或是 DASH 並不在這個 CMAF 的定義範籌裏頭。
CMAF 想像中的美好願景是： 未來，一部影片只需要儲存一份，串流時也只要一種格式，CDN 也只要暫存一種就行。 同樣都是 fMP4（bye bye, TS)、 同樣都是採用 AVC, AAC, HEVC, VP9(?)、 字幕檔的格式都一樣… 是個美好的大同世界~
如果沒有 DRM，影音串流執行起來，困難度應該會少掉不少…
借用 STREAMING FORMAT EVOLUTION — DOES CMAF GIVE US THE SINGLE FORMAT?的圖來看會更清楚一點。 以下是一張從 streaming protocol 往內看，層層扒開，一路往內看的圖示。
DASH 與 HLS 在最外頭，它最薄，也最無關痛癢。 DASH 簡單來說，就是個 XML 檔搭配一些規範以及 validation rules。 而 HLS 則更是簡單到爆炸的類 txt 檔 。 它們倆都短小精幹，相對於 media segment 檔來說，是可以忽略的地步。 它們可以被事先產生好，也可以動態產生。 實務上，要讓它再更精簡一點的話，就是透過 HTTP Compression 即可。 對於儲存空間與網路流量來說，這兩個玩意兒不是問題。
fMP4 與 TS (or MPEG-2 TS, more formal name) 則是決定了 streaming file format 的重點。 TS 有其優秀而重要的貢獻，但在 adaptive streaming 的時代來看，就顯得過時了。 它的 188-byte packet 限制以及 4~12 bytes 的 header 設計， 使得每一個 media segment 的 overhead (浪費掉的空間) 明顯比 fMP4 來得多。 雖然說有各家的 TS optimizer 可以套用，不過就是整個很費工。 另一個影響 media segment 大小的，就是 codec 了。 但這個不在這一篇的討論範籌裏頭。
Web standards 一直是推進這個 Internet Era 的重要推手， 在 video streaming 這一塊也是一樣。 因為 Common Encryption (CENC) 的提出，各大家 DRM solution providers 也就更容易整合了。 雖然各家 DRM solution protocols 不同，但是加密的方式確是可以統一下來。 很遺憾的是，HLS (或更精準的說，是 Apple FairPlay）讓世界變得稍為麻煩了點。 它支援的 AES-128 或是 Sample-AES，都與其它 DRM solutions 都不一樣，無法納入 CENC。 雖然每一家都是採用 AES，但 HLS/FairPlay 只支援 CBC mode，而其它則是支援 CTR mode！ 因為 CBC 與 CTR 是兩個完全不相信的 mode，加密出來的檔案（或數位流）也不一樣。 換句話說，因為這個不同，CMAF 的一個檔通吃的美夢還無法完成！
影音串流的格式一統革命尚未成功，產業還需努力…
CMAF: (by CMAF: What It Is and Why It May Change Your OTT Future
References:
- 3月 27 週一 201714:36
pem and pfx
PEM =>數位憑證
PFX =>private + public key
PFX : PFX defines a file format commonly used to store private with accompanying public key certificates,
protected with a password-based symmetric key (standard-PKCS12).
PFX =>private + public key
PFX : PFX defines a file format commonly used to store private with accompanying public key certificates,
protected with a password-based symmetric key (standard-PKCS12).
- 3月 27 週一 201714:06
[轉貼] 憑證的運作方式 (X.509)
1. X.509
一種基於 PKI(公開金鑰) 的電信通訊標準
1. Root Certificate Authority (RCA)
最高層認證中心
- 3月 27 週一 201713:55
[轉貼]什麼是 PKI
一、什麼是 PKI
PKI 是一種用以強化網路安全的技術，讓使用者透過公眾網路與他人安全且經過驗證地交換資訊，就如同現實世界以簽名、密封文件的方式來保全交換的訊息。
Public 在此指的是公眾的設施、公開的存取，通常是指網際網路之類的公開實體；Key 是一種數位表徵，藉以密碼學的加密與數位簽章的方式達成所要求的安全目標；Infrastructure 則是幾個部分所結合而成的整合系統，這裡最重要的部分是憑證機構(Certificate Authority：CA)，將於爾後負起身份驗證與登錄的責任。PKI 整體而言透過網路所要提供給使用者的是：
‧保密性（Confidentiality）：確保僅有預期的接收者會收到訊息。
‧資料完整性（Data Integrity）：確保資料在接收前沒有被更改。
‧驗證性（Authentication）：確保參與資料交易者的身份無誤。
‧不可否決性（Non-repudiation）：交易資訊具有法律效力，參與交易者無法隨意否認。
二、PKI 組成要素
使用者的一對金鑰：這是提供給每一實體、每一個人，在數學上相關的一對鑰匙，每對鑰匙由私密金鑰（Private Key）與公開金鑰（Public Key）組成。公開金鑰可以發佈到網路或給其他使用者，私密金鑰通常只能存在於使用者的電腦，只有使用者可以存取。
數位憑證：由憑證機構發出，藉以向他人確認您的身分。數位憑證通常包含有持有者的公開金鑰、持有者的電子郵件地址、憑證發行單位、憑證有效期限…等等。
憑證機構(Certificate Authority：CA)：發行與驗證憑證的組織，是屬於公正的第三方，要負責證明提出憑證發行的人身分的正確性，要保證包含在憑證裡資訊的正確性，並且需要對憑證作數位簽章。CA 的角色可以比擬成發行駕照的監理單位，當您提供必要的證明文件來證明您身份之後，CA 就發給您憑證，CA 並且會對憑證作簽署以避免憑證被竄改。依據檢核的等級，憑證可以依不同等級來發行，總共可以區分為 3 到 4 種的憑證等級。Class 1 憑證只需透過 E-Mail 就可取得；Class 2 憑證需要額外的個人資訊即可取得；Class 3 的憑證必須提出請求者的身份證明，經檢核過才能取的；Class 4 是用於政府和機關團體，需要非常高等級的檢核。
三、PKI 如何運作
公開金鑰驗證數位簽章：
當使用者 A 想要與使用者 B 溝通時，A先產生一對金鑰再向 CA 註冊申請，A 除了提供 CA 必要的證明文件外，也需要送上公開金鑰的副本，當 A 的身份被驗證無誤之後，CA 將發佈結合 A 使用者公開金鑰的數位憑證，CA 會把此憑證擺在公用資料庫，這就如同是公用電話簿的公開電話一般。
當 A 使用者想要與 B 使用者溝通時，他只需以自己的私密金鑰對文件作簽章，B 使用者這端只需透過 CA 的資料庫取得A使用者的公開金鑰即可驗證文件的確來自A使用者；當由 A 使用者傳送過來的文件內容經過雜湊函數（hash function）所得到的文摘（digest）與A一併傳送過來的簽章經 public key 解密所得到的文摘作比對，若是符合即證明文件確實是 A 使用者所簽署。
公開金鑰加密：
上面例子是用在簽章，若A使用者希望也能傳送加密資料給 B 使用者，必須 B 使用者也使用 PKI。A 此時必須從 CA 取得包含 B 的公開金鑰的憑證，而B的憑證是以 CA 的私密金鑰作數位簽章，因此 A 必須以 CA 的公開金鑰驗證此簽章以取得 B 的公開金鑰，接著用於傳送加密資料。
公開金鑰密碼學是使用在數學上相關連的一對金鑰，如果以其中一把金鑰用來加密訊息，那就只能用另一把金鑰解開訊息；這對金鑰的其中一支稱為 Public Key（公開金鑰），通常被任意散佈；另一把鑰匙稱為 Private Key（私密金鑰），不對公眾公開，通常是放於電腦內部無法取得；由於加密與解密使用不同的一對鑰匙，所以稱為非對稱式密碼學（asymmetric cryptography）。
不過在實際的運作案例中，加密與解密大多是使用同一把鑰匙，也就是對稱式密碼學（asymmetric cryptography），在處理速度上比非對稱式密碼學快。
四、PKI 應用
PKI 在實際上與我們生活比較相關的應用就屬“自然人憑證”，自然人憑證就像是網路身份證，不需要出門就可以透過網路證明我的身份；因此我可以透過網路辦理網路報稅、申請電子戶籍謄本、更改駕照地址，甚至可以用於中華電信e櫃臺。另外台灣網路認證（TWCA）所發送的網路銀行憑證，可以用於證券網路下單、期貨網路下單、電子商務、網路銀行…等等，與我們日常生活也是息息相關。目前國內多數 PKI 的憑證機構仍是屬於政府機關在推動，在民間企業內部其實有諸多應用可以推廣；例如用於員工識別證，可以作為門禁管制、請假、公文傳遞，甚至在家裡辦公，因為電子化憑證的使用，強調的就是突破時空的限制。
- 10月 15 週六 201602:07
筆記
08048000-0804e000 r-xp 00000000 08:01 12118 /sbin/init
0804e000-08050000 rw-p 00005000 08:01 12118 /sbin/init
08050000-08054000 rwxp 00000000 00:00 0
40000000-40016000 r-xp 00000000 08:01 52297 /lib/ld-2.2.4.so
40016000-40017000 rw-p 00015000 08:01 52297 /lib/ld-2.2.4.so
40024000-40025000 rw-p 00000000 00:00 0
40025000-40157000 r-xp 00000000 08:01 58241 /lib/i686/libc-2.2.4.so
40157000-4015c000 rw-p 00131000 08:01 58241 /lib/i686/libc-2.2.4.so
4015c000-40160000 rw-p 00000000 00:00 0
bfffe000-c0000000 rwxp fffff000 00:00 0
0804e000-08050000 rw-p 00005000 08:01 12118 /sbin/init
08050000-08054000 rwxp 00000000 00:00 0
40000000-40016000 r-xp 00000000 08:01 52297 /lib/ld-2.2.4.so
40016000-40017000 rw-p 00015000 08:01 52297 /lib/ld-2.2.4.so
40024000-40025000 rw-p 00000000 00:00 0
40025000-40157000 r-xp 00000000 08:01 58241 /lib/i686/libc-2.2.4.so
40157000-4015c000 rw-p 00131000 08:01 58241 /lib/i686/libc-2.2.4.so
4015c000-40160000 rw-p 00000000 00:00 0
bfffe000-c0000000 rwxp fffff000 00:00 0
- 5月 26 週四 201623:29
[轉]如何正确的repo sync?
我們知道 repo 是 Google 為 Android source tree 的管理而寫的一個 script，以方便處理 Android 源碼包含的上百個 git repositories。要取得 upstream 最新的 code，只要下 repo sync 就行。它相當於對每個 project 做 git pull 的動作。不過如果你曾對 source tree 做一些修改，repo sync 可能遇到不同的問題。以下說明可能發生的情況，以及解決辦法。
首先視你是否 commit 過你的修改而定。如果你只是單純的修改檔案，而沒有做 git commit 的動作，那麼 repo sync 會嘗試將 upstream 和你的修改做合併(merge)。如果有衝突(conflict)，repo sync 就會失敗而停止。你的修改依然存在，不會被蓋掉。這種情況下，最好的辦法是先用 git stash 保存你的修改，再 repo sync。例如，假設你修改的是 frameworks/base：
$ cd frameworks/base
$ git stash
$ cd ../..
$ repo sync frameworks/base
$ cd frameworks/base
$ git stash pop
最後的 git stash pop 會將你的修改再 apply 到 repo sync 後的結果上。這時再手動修正衝突的部分就好。
如果你已將修改 commit 進去，那麼 repo sync 的處理方式，會依你的 branch 是否為 remote-tracking branch 而有所不同。若不是 remote-tracking branch，那麼 repo sync 的結果相當於 git checkout 至 upstream 相對應 branch 的 tip (即最新的 commit)。你可能會看到這樣的訊息：
$ repo sync frameworks/base
frameworks/base/: discarding 3 commits
不要驚慌，它其實只代表你的 HEAD 已被切換到 upstream。你原來的 commit 並沒有真的被丟掉，你仍然可以切換回來：
$ cd frameworks/base
$ git checkout ORIG_HEAD
ORIG_HEAD 就是指 repo sync 切換前的 HEAD。再來用 git rebase，把你的修改 apply 到 upstream tip 上：
$ git rebase m/gingerbread-x86
(如果你在弄的是 froyo-x86、… 就把 gingerbread-x86 換成 froyo-x86、…)
每次都這樣做是不是有點麻煩? 能不能自動完成? 當然可以，這就是 remote-tracking branch 的用處。如果你的 commit 是在一個 remote-tracking branch 上，那麼 repo sync 就會自動將你的 commit apply 到 upstream tip 上，例如：
$ repo sync frameworks/base
project frameworks/base/
First, rewinding head to replay your work on top of it...
Applying: fix wifi issues
git branch -v 時顯示 (no branch)
$ git checkout -b mybranch m/gingerbread-x86
Branch mybranch set up to track remote branch gingerbread-x86 from x86.
Switched to a new branch ‘mybranch’
首先視你是否 commit 過你的修改而定。如果你只是單純的修改檔案，而沒有做 git commit 的動作，那麼 repo sync 會嘗試將 upstream 和你的修改做合併(merge)。如果有衝突(conflict)，repo sync 就會失敗而停止。你的修改依然存在，不會被蓋掉。這種情況下，最好的辦法是先用 git stash 保存你的修改，再 repo sync。例如，假設你修改的是 frameworks/base：
$ cd frameworks/base
$ git stash
$ cd ../..
$ repo sync frameworks/base
$ cd frameworks/base
$ git stash pop
最後的 git stash pop 會將你的修改再 apply 到 repo sync 後的結果上。這時再手動修正衝突的部分就好。
如果你已將修改 commit 進去，那麼 repo sync 的處理方式，會依你的 branch 是否為 remote-tracking branch 而有所不同。若不是 remote-tracking branch，那麼 repo sync 的結果相當於 git checkout 至 upstream 相對應 branch 的 tip (即最新的 commit)。你可能會看到這樣的訊息：
$ repo sync frameworks/base
frameworks/base/: discarding 3 commits
不要驚慌，它其實只代表你的 HEAD 已被切換到 upstream。你原來的 commit 並沒有真的被丟掉，你仍然可以切換回來：
$ cd frameworks/base
$ git checkout ORIG_HEAD
ORIG_HEAD 就是指 repo sync 切換前的 HEAD。再來用 git rebase，把你的修改 apply 到 upstream tip 上：
$ git rebase m/gingerbread-x86
(如果你在弄的是 froyo-x86、… 就把 gingerbread-x86 換成 froyo-x86、…)
每次都這樣做是不是有點麻煩? 能不能自動完成? 當然可以，這就是 remote-tracking branch 的用處。如果你的 commit 是在一個 remote-tracking branch 上，那麼 repo sync 就會自動將你的 commit apply 到 upstream tip 上，例如：
$ repo sync frameworks/base
project frameworks/base/
First, rewinding head to replay your work on top of it...
Applying: fix wifi issues
git branch -v 時顯示 (no branch)
$ git checkout -b mybranch m/gingerbread-x86
Branch mybranch set up to track remote branch gingerbread-x86 from x86.
Switched to a new branch ‘mybranch’
使用repo sync时，如果当前仓库有检出本地分支，假设为dev, 对应的远程track分支为origin/dev。 而manifest.xml中指定的track分支为origin/master,那么在repo sync时会自动将当前的dev分支的远程track分支修改为origin/master, 不仅如此，同时还会将origin/master上的修改rebase到本地的这个dev分支上。
[轉]repo sync 时自动切换当前分支的remote track分支的问题
- 12月 07 週一 201517:32
[轉貼] DRM in Android
