PPS 為P2P電視服務的主要提供者之一, 其他業者包括 PPL、TVAnts、PPLive、EZTV 等等.
PPS 最大的收入來源為廣告, 而且播出的電影、電視都是合法買來的, 據說有一萬多部片子. 壓縮的格式主要是 RM 和 WMV9. 由於他們申請的執照是網路串流 (streming) 服務, 所以這些 content 都只能在網路上觀看, 不能夠存下來.
他們會在片頭放廣告, 我覺得無可厚非. 我們既然免費看電影, 也要付出一點時間來交換. 但是它會跑出 pop up 廣告就有點煩人了. 這招就是迅雷等公司都在用的 “奧步". 電腦的右下角很容易就跑出大張的廣告, 看了令人實在不爽~~~
PPS 的 UI 做得不錯, icon 也滿可愛的. 不過因為那個 pop up 廣告和我的防毒軟體意見不太合, 所以我就把它移除掉了.
商業週刊有介紹過這家公司, 原來 PPS 是台灣人徐偉峰和兩個大陸 (西南交大?) 的學生張洪禹、雷量開的.
http://www.businessweekly.com.tw/webarticle.php?id=28566
HDMI 的規格裡面有一個 auto lips sync, 以便 HDMI 的 source 或是 repeater 送出符合 repeater 或是 sink 的 AV 訊號. 當這台 sink 的 HDMI device 處理 audio 比 video 快的時候 (通常如此), 希望上游可以晚一點送出 audio 的資料 (raw data 或 PCM), 使得最終在 HDMI sink 上面可以做到視訊、音訊的同步輸出.
至於怎麼做到 auto 呢? 其實對 sink device 是 auto, 但是對 source device 卻不然. 根本就是 source 要做苦工去迎合 sink. Sink 只要大剌剌地把它處理 audio 和 video 的絕對延遲時間, 用 EDID回送給 source 端就好了.
由於 sink 端可能對於解不同的 video/audio format 的速度不同, 因此就算不插拔訊號線, 它還是會穿插地送出不同的 audio latency 與 video latency. 特別是 video 在 progressive mode 和 interlace mode 的速度差了不少, 因此 sink 有時會送出第二組 latency: Interleave audio/vide latency 給 source. 在 source 的 HDMI driver 裡面, 就要依據 max 和 min 的 latency, 去計算 audio 與 video 的 avearge latency.
audio 的絕對 delay 值 = (max_latency + 2*min_latency)/3
video 的絕對 delay 值 = (2 * max_latency + min_latency)/3
而 Audio 的相對 delay 值 = video 的絕對 delay 值 – audio 的絕對 delay 值.
這是因為人類對於 “audio 比 video 快" 比較難容忍, 所以 audio 多 delay 一些比較安全.
這顆 Seagate 當前最大容量的 SATA2 硬碟, 本來應該是碟王, 不過它會熱當喔! 請認明型號 ST31500341AS, 千萬別買.
因為這一顆是我最大的單顆硬碟, 所以當作其他硬碟的備份. 老實說沒有甚麼在用, 只有在旁邊休息的份. 有養驢子的硬碟都活得好好的, 但是這一顆, 昨天突然消失了. 在我的電腦裡面找不到, 到硬碟管理裡面也找不到…
幸好我是把它放在抽取式的硬碟盒裡, 關機之後輕鬆地把它拿出來吹風. 原本熱騰騰的硬碟, 休息十分鐘之後, 再放回電腦裡面, 就一切正常了. 所以當掉的原因應該是過熱啦!
DLNA（Digital Living Network Alliance）是一個數位家庭的網路規格, 架構於原有的有線或無線網路之上.
比較特別的是 DLNA 創造了一些名詞, 它讓大家會看得有點暈眩. 包括: Digital Media Server（DMS）、Digital Media Player（DMP）、Digital Media Controller（DMC）、Digital Media Renderer（DMR）與 Digital Media Printer（DMPr）.
DMS 儲存/送出 content, 如電腦.
DMR 接收/顯示 content, 如螢幕.
DMP 檢索/顯示 content, 如電視.
DMC 操作 DMP 或 DMR 的東西, 如遙控器.
DTCP-IP 驗證 DMS, DMR, DMP 之間連線的規格.
參考: http://www.eettaiwan.com/STATIC/PDF/200811/20081117_Allion_TA02.pdf?SOURCES=DOWNLOAD
有一個有趣的問題: 假如 cache size 是 8KB, 而 virtual memory 的 page 是 4KB 會怎麼樣? 這個就是 cache alias的問題.
根據新版的 “See MIPS Run" 這本書的 10.3.4 Cache Aliases and Page Coloring, 名詞定義是這樣:
1. index range = the size of one “set" of cache. 舉例來說 4 KB 的 page 可以對應到 8KB 的 direct map, 或是 32KB 的 4-way set-associative cache.
2. page color = the value of those one or more virtual address bits that choose a page size chunk within the propriate page set.
3. cache aliases = two virtual pointers to the same physical data can produce an alias only if they have different page colors.
若是把 32KB 4-way associative cache memory 看作 4 塊 8KB 的 cache memory, 那麼每一塊都比 4KB page 大一倍, 一抓就有機會抓到和另外一個 way 重疊的內容.
解法: 只要 virtual address 彼此距離夠遠, 比方說在 4KB page 下間隔 64KB, 那麼每個 page 的 color 都會一樣.
另外有人說, 可以讓 virtual address 的 bit 12 (假設 page 是 4KB, 12 bis) 強制和 physical address 的 bit 12 一樣, 也就是說每 8KB 的第一個 4KB, 和第二個 4KB 在 physical address 上都沒有重疊. 由於每一個 way 不會抓到一樣的東西, 這就確保了兩個 way 之間的 cache 不會重複. 它聽起來等效於 page size 變成 8KB, 所以應該會沒問題.
先不管軟體實作上的困難, 這種 work around 的 hit rate 將會很低. 每次 hit 到奇數 page, 就要連前一個偶數 page 都抓進來. 那些資料通常已經是過去式了, 所以 cache 的效率應該挺差的.
——————————————————–
20090320 重新整理
cache alias 可能發生在 Linux 的 user mode 之間, 也可能發生在 user mode 與 kernel mode 之間.
單純在 user mode 的解法有很多種:
1. 只要 virtual address 彼此距離夠遠, 比方說在 4KB page 下間隔 64KB, 那麼每個 page 的 color 都會一樣均勻, 如小魚的第一個回覆一樣.
2. 根據小魚的說法: 奇數 8KB (i.e. 4(2n+1)KB) 和偶數 8KB (i.e. 4(2n)KB) 的 physical address 都對應到不同組的 virtual address. 而 memory cache 既然是根據 virtual address 所做的, 那麼就沒有機會 cache 到重複的 physical address.
有人說用這種說法: “可以讓 virtual address 的 bit 12 (假設 page 是 4KB, 12 bis) 強制和 physical address 的 bit 12 一樣, 也就是說每 8KB 的第一個 4KB, 和第二個 4KB 在 physical address 上都沒有重疊. 由於每一個 way 不會抓到一樣的東西, 這就確保了兩個 way 之間的 cache 不會重複. 它聽起來等效於 page size 變成 8KB, 所以應該會沒問題.
為了 hit 到 8KB 裡的一個 Linux 4KB page, 現在必須抓 8 KB 的 cache. 和原來的方式相比, 原來讀到 0x80001-000 的時候, 我們 cache 0x80001-000~0x80002-FFF, 是指望後面進到 cache 的 0x80002-000~0x80002-FFF 這個 page 等一下會用到. 根據新的方式, 就會變成 cache 0x80000-000~0x80001-FFF 這 8 KB. 所以還是會有一些差別, 如小魚第四篇回覆所說的: " 0×00410_000 和 0×00411_000 是無法同時對到 0×40400_000 的“.
本來我有個直覺, 覺得分了類之後, 對於大量連續資料, 又放在虛擬記憶體的連續位置時, 上面的做法可能會降低效率. 但想想也只是 cache 到不同 way 的 cache memory 去了, 應該是還好.
[後記]
1. Kernel space 和 user space 存取同一個 page 的話, 也會有 virtual alias 的問題.
2. 還是要感謝小魚啦! 哈!
Cash Chou's Blog 