星期一, 8月 18, 2014

python一行讀AFINN


dict(map(lambda (w, s): (w, int(s)), [ws.strip().split('\t') for ws in open("AFINN-111.txt")]))

星期一, 6月 09, 2014

Jawbone UP

我一直是什麼配件都不帶的人. 手上沒錶沒戒指沒佛珠沒項鍊的人. 連鑰匙都維持最少的數量...
之前耳聞要做Wearable, 買了一個Jawbone UP 2. 強迫自己每天戴, 但總是有些時候忘了帶. 斷斷續續戴了十個月, 終於達到了一百萬步!!
從這裡看來就知道顯然它沒有激勵我...

最近一個月, Jawbone UP上面的皮愈來愈長, 已經把按鈕都包住了. 上它網站上一查, 有一大堆人回報一樣的問題, 甚至長到把充電的蓋子都包起來了. 那些人的UP都被換新, 我立馬也開了一個ticket回報這個問題. 靜觀其變吧...

星期二, 5月 27, 2014

git clone failure

踩到gnutls的地雷, 不能clone某個用https來share的code.

以下的解法

http://askubuntu.com/questions/186847/error-gnutls-handshake-falied-when-connecting-to-https-servers

改成用openssl的tls即可...

星期一, 9月 30, 2013

影片轉檔速度範本怎麼選:尋找轉檔速度、畫質平衡點

影片轉檔速度範本怎麼選:尋找轉檔速度、畫質平衡點
http://feedly.com/k/168nbfR

筆者在上期技研堂單元中,探討了在進行影片轉檔時,使用硬體加速與純軟體運算,對畫質的影響。其中也稍微提到在使用同一套轉檔軟體的前提下,更改細部編碼設定,也會對畫質造成影響。

從容量反推畫質

以往筆者都是PSNR或SSIM等指標分數,做為評斷畫質的依據,這次筆者將換個方式,以x264編碼器CRF(Constant Ratefactor)編碼模式。由於我們固定CRF的Ratefactor參數,並更改細部編碼設定,理論上就可以得到相同的畫質但大小不同的影片,這時只需要比較影片壓縮率,即可反推當固定輸出影片大小時的畫質表現。

CRF模式的運作方式是會固定編碼器內建的品質指標,好處是只需執行單一pass,轉檔速度比較快,而且不會因為速度較快而對畫質造成負面的影響,其缺點則是無法預測輸出檔案的大小。

Medium速度畫質平衡點

筆者將測試影片以AVC High Profile Level 3範本進行轉檔,並套用x264編碼器內建的10種速度範本,並將轉檔速度與輸出檔案大小收錄於下方表格。我們可以看到輸出檔案大小在Very Fast開始明顯地變小,速度除了在Very Fast有明顯落差外,在Slow也有另1個落差。因此筆者推薦使用Very Fast、Fast、Medium這3種範本,能在速度與畫質間取得不錯的平衡,如果比較注重畫質則選Slower,超級注重畫質的話,選Very Slow就好,Placebo的速度太慢,且效果不明顯。

此外筆者也將部分因速度範本不同而異的細部設定收錄於下表,其中差異比較大的部分,是動態預測搜索方式,其意義為比對前後畫面,只將有變動的地方記錄下來時所用的預測方式。diamond僅搜索上下左右4個像素,效果非常有限,hexagon,為向周圍6個方向搜索,multi hex則使用更複雜的六邊型形狀,能提供更精確的結果。SATD Exhaustive則是使用演算法進行詳細搜索,雖然可以更精準地抓到動態向量,但是效率非常低,除了會讓速度變慢外,效果並不明顯,不推薦使用。

▲將所有數據除以Ultra Fast數據標準化之後,可以看到從Very Fast開始檔案容量明顯減少。

▲同樣將所有數據標準化後,發現Very Fast、Fast、Medium的速度比Slow快上不少。

▲編碼結果與編碼工具一覽

延伸閱讀:

軟體轉檔?硬體加速?影像品質大檢驗

影像順暢度深度解析:破解 FPS 盲點、找出影像頓呆的主因

新一代影像編碼格式 H.265 完全析解,流量省一半,檔案更小更美

硬轉影片上字幕,硬體加速也要嵌入字幕

顯示卡 4 大反鋸齒技術探討:鋸齒的產生與消除,前處理、後處理之爭


 

本文同步刊載於電腦王雜誌
  
歡迎加入電腦王雜誌粉絲團


加入T客邦Facebook粉絲團

shared via http://feedly.com