月份: 三月 2009

電影 送行者 – 禮儀師的樂章

昨天女兒考完期中考, 誓言要宅在家裡看電視. 不過她人權低微, 還是被我和老婆抓去看電影. 就是這一部 “送行者".

本片勇奪奧斯卡最佳外語片, 當然是一部好片. 尤其我希望我女兒能夠對生死的概念有多一點的了解, 而不是整天想著看不營養的卡通. 有些重播 N 遍, 連我都可以一眼辨識出來這是重播的卡通, 女兒都推說沒關係、忘記了… 所以還是讓她遠離那些東西為妙!

劇中有好幾位演員都演技都很出色, 深田恭子算是例外. 因為她在劇情轉折的時候都表情曖昧, 不知道在想甚麼? 若是回到大學話劇社的年代, 凡是外表看不出在演甚麼的, 我們都會恭維那是在演內心戲. 所以深田恭子應該多半是在演內心戲.

有一個畫面我覺得取鏡不錯, 就是主角小林大悟跑離公司, 而他懷孕的老婆美香出現在鏡頭遠方的一角. 按照劇情, 男主角因為不滿意父親丟下他們母子, 所以不想去認父親的遺體. 而這一幕跑開的畫面, 正好印證男主角也因為自己的情緒, 丟下了自己的妻兒. 小林想通了這一點, 所以回身去公司和老闆借車~~ 鏡頭雖然不錯, 但是味道少了一點點, 轉折不是很清楚, 我覺得稍微有些可惜.

另外不知道男主角在聖誕夜演奏的曲子有甚麼特別的含意? 因為老闆和女秘書聽著聽著都變得沉重起來. 我本身是樂癡, 所以不懂得欣賞其中的奧妙. 既然男主角在演奏之前, 事先徵詢老闆和女秘書是否有宗教信仰的顧忌, 而不是即興來一曲, 背後一定有些玄機. 我可能要去翻翻原著才知道那是何種典故.

總之, 這部片子笑中有淚, 也達到我對女兒寓教於樂的目的. 晚上我幫女兒點睡前散瞳劑的時候, 她又故意躲進被窩裡, 把頭整個蓋住. 於是我像電影中一樣, 只把臉上的那部分被子掀起來, 女兒就開始裝死. 點完眼睛之後, 我再把她的手交握疊在胸前, 我們兩個人就笑個不停… (本劇的教學成果就是教會大家如何把死人入殮). 老婆在隔壁房間問我們在笑什麼, 嗯, 很難解釋, 當場看才好笑~~

我讀 «How Networks Work» – 1

這本書是從日文翻譯過來的, 作者是戶根勤. 和這個系列裡面的其他書一樣, 這本書超棒! 它由淺入深地介紹了網路有關的種種東西. 並不會生硬地叫大家從 OSI 開始背誦知識, 而是一步一步地從最基本的網路連接講起.

首先介紹網路如何找到你要的網址開始這個探險旅程. 首先我們會有一個 URL, 然後呢? URL 又可以分為伺服器名稱、目錄與檔案幾個部分. PC 發出一些HTTP 的命令, 像是 GET、POST、PUT 等等. 我們的 PC 上的 web browser 會以 HTTP 特定的格式發出這些命令, HTTP server 收到這些東西之後, 就會給出回應.

但是光知道 HTTP 伺服器的 URL, 又怎麼找到它的 IP address 呢? 這個就要去問 DNS (domain name server).

DNS 查詢的動作, 基本上是一個名稱的解析 (name resolution、DNS resolver), 用 Socket library 就可以呼叫解析器.

<記憶體區域> = gethostbyname(www.abc.com);

傳回的這一塊記憶體, 裡面就會有 IP address. 當然, 中間的過程牽涉到 web 程式 call Socket library 裡面的 gethostbyname(), 而這隻 function 又會去 call OS 內部的 TCP/IP module, TCP/IP module 去 call LAN 網卡驅動程式, 底下才是網卡去和伺服器溝通.

世界上有不同等級的 DNS, 畢竟不是每個 DNS 都放置了全世界的 IP address 與 URL 的對應表. 不知道的東西, 就會層層回報到根網域, 據說這個等級的 DNS 全世界只有 13 部.

書中又特別強調: Socket library 和 socket 是不一樣的, socket 是一個插槽, 相當於一個check in 的動作. 帶著 IP address 和 port number check in 之後就拿到描述器, 相當於是旅館的預約號碼或是房間號碼.

無論在應用程式端 (Web browser 等等) 或是伺服器端, 都會有產生 socket 的動作, 而各自拿到描述器. 應用程式端的描述器變成 connect() 指令的參數, 而伺服器端的描述器則變成 bind() 指令的參數. Bind() 功能是瀏覽器所沒有的, 它會檢查每個 port 所註冊的伺服器程式各自是甚麼? 接著開始 listen().

應用程式以 connect() 來連接伺服器, 跟伺服器說房號 XXX 的客人來了, 伺服器就依據 port對應到的程式來 accept() 這個 connect(). 並且關掉現在的描述器, 產生新的描述器. 我們可想像是把預約號碼換成了房間號碼.

當應用程式 write() 資料過來後, 伺服器就用 read() 來接收, 應用程式送完資料後 close(), 伺服器也 close().

以上就是第一章的重點, 是不是還挺有趣的呢?

清涼美妹在 MSN

 參加完大學社團的聚會後不久, 我的 MSN 就收到了一個新的加入請求. 我還以為是學弟妹呢, email 地址看起來很正常, 沒有怪怪的英數字組合; 暱稱也不是前一陣子大陸同胞常用的 “感人佳句", 而是比較神祕的一片空白, 所以就讓他 (或她) 加入了.

喔!? 照片是一張清涼照! 而且畫面比較暗, 看起來是自拍, 而不是抓網路上現成的照片. 如果是林志玲的照片, 那還滿正常的. 但是個人的自拍照嗎? 我還沒有這麼 “熟" 的朋友…此時心裡已經浮現了 “網路詐騙" 這幾個大字.

接下來的幾個小時, 這位美妹又換了幾張照片, 都是大同小異不露臉的清涼照. 我在想: 如果我一直不理她, 接下來會怎麼樣呢? 該出狠招了吧? 嗯,呃,啊…原來對方沒有甚麼殺招嘛! 最厲害也就是遮胸的照片, 應該算是輔導級. 真正令人欽佩的, 就是對方也堅持不主動和我交談, 果然是滿懂得兵法.

隔了一段時間, 可以歸納出照片總共就是那幾張了, 並且可以經常感覺到我是被封鎖的. 我想這是投資報酬率的問題, 如果同一個時間對方只釣一隻魚的話, 未免也太不划算了. 畢竟一次要犧牲一個名稱漂亮的帳號, 就不能使用得太快. 把我封鎖的時間, 應該是在和其他的對象交談, 可以說是正在拼業績中~~~

不久之後, 那位陌生人和我已經互相封鎖了. 但是另外一個名字看起來很正常的人, 又要求加入我的 MSN. 等他/她加進來之後, 我發現照片還是上次那幾張中的一張, 根本就是 詐-騙-集-團嘛! 而且這一位 “分身" 還比較不阿莎力, 似乎沒有換過照片喔, 哈哈哈! 這麼不 “敬業".

有了上次的經驗, 不用遲疑立刻就將他/她封鎖. 比較猶豫的是, 公布他/她們的 MSN 帳號對我好像也沒有好處? 畢竟對方甚麼事都沒做啊? 總之, 我想不需要警示帳號, 只要大家有所提防, 就可以百毒不侵了. 在網路上有查到某些時間很多的網友, 他們會發揮柯南的精神, 經由 MSN 交談, 試著去證明兩個帳號是同一個人, 不過我沒那麼多閒功夫就是了.

PPStream 簡介

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 的規格裡面有一個 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 一些比較安全.