多年後重新檢驗視網膜螢幕是怎麼回事

距離上次出現有關視網膜螢幕已經好幾年了
最近Sharp 傳出要弄4K解析度在手機上
趁這個機會我重新檢驗視蘋果的網膜螢幕的到底是怎麼回事

就我所知道第一個retina螢幕的是iphone 4
不過查wiki 似乎ipod touch 才是,不管還是先用iphone 4的規格來計算
iphone 4:3.5″,960×640

我 前幾次試算視角 視力 視網膜螢幕,都是採人工計算 (關係式列出來,求解)
由於每次都要重複這些東西很麻煩,所以前一兩年我已經把它弄成程式碼
嚴格來說視力是關於水晶體曲度的問題,影響的是在視網膜上對不了焦的情形
視網膜螢幕應該指的是聚焦在視網膜上也看不出來差距的情形

隨著物體靠近的程度,焦點越容易聚焦在視網膜上
其實視網膜螢幕不應該考慮視力這個因素,只不過我歪打正著
即便透過眼鏡矯正後 能分辨的角度多半跟視力1.0的情形一樣(視網膜極限?)
現代人在一般生活環境下眼睛能分辨角度 多半也就1分度(1/60 度)
似乎有人可以到2.0 3.0,不過這不多見

由於之前的計算採取的是近似的方式,剛剛把計算法則修改成更正確的版本
對角線角落的地方是距離最遠的地方(解析度最不好),應該以這個為準
角落的像素間夾角=一分度的時候就是最遠距離

用這個來計算最遠距離的話
24″ 1080p=84 cm, 24″720p=136cm,48″ 1080p=168cm,48″720p=272cm
iphone 4的情形最遠距離是26 cm,似乎蠻符合一般人使用手機的距離
所以所謂的 retina螢幕 是距離26cm左右 看不出來差異的螢幕
而不是拉多近都看不出來差距的螢幕,apple 的retina 頂多只算是個廣告用語沒有實質意義
眼鏡最短聚焦距離應該是10cm左右,iphone 4 則是 26cm (是兩倍以上的距離)

Sharp 那個5.5″ 4K螢幕,最遠距離是7 cm
所以說Sharp 真的瘋了 有誰會想在7cm的距離下使用手機
Sharp 這個4k螢幕才真的算是 retina display

about AAC and multi-channel Audio

繼上一篇提到video 的部份,這篇要提的是AAC
目前來說AAC 有很多版本,就opensource 來說 libfdk_aac 是最好的
所以這篇主要針對libfdk_aac 的設定來著手,另外順便談multi-channel的問題

libfdk_aac 有五種profile

其中比較常用的三種是aac_he、aac_he_v2、aac_low
要使用哪個主要看的是要給多少流量

aac_he_v2 適合於24kbps (per-channel) 以下
aac_he 適合於24kbps~40kbps (per-channel)
aac_low 適合於64kbps (per-channel) 以上

40kbps~64kbps,aac_he_v2、aac_he表現幾乎一樣,個人建議用aac_he

aac_he、aac_he_v2 與aac_low(LC-AAC) 聽覺上最大的不同在於transparency
所以高流量(單聲道大於64kbps)的情形 建議profile採取aac_low
libfdk_aac 預設值是aac_low
另外profile 採aac_he 或 aac_he_v2 最多單聲道流量上限就64kbps per-channel
再多也沒有意義(實際上程式最多就給到64k),流量再多請改採aac_low

profile 採用aac_low 時,可以使用vbr模式 (可變流量)
vbr 有五種設定 分別是
1 20-32 kbps/channel
2 32-40 kbps/channel
3 48-56 kbps/channel
4 64-72 kbps/channel
5 96-112 kbps/channel

舉例
ffmpeg -i <input> -c:a libfdk_aac -flags +qscale -vbr 5 -afterburner 1 <output>

Downmix 主要是在多音軌下 輸出stereo


一般而言 常見的downmix設定是
FL = FL + 0.707FC + 0.707BL
FR = FR + 0.707FC + 0.707BR
但是這樣環繞的聲音太明顯,所以有人採下面的方案(個人比較喜歡)
FL = FL + 1.414FC + 0.5BL + 0.5SL
FR = FR + 1.414FC + 0.5BR+ 0.5SR
用在ffmpeg 上則是
ffmpeg -i <input> -b:a 256k -ac 2 -clev 1.414 -slev .5 <output>
或者
ffmpeg -i <input> -b:a 256k -ac 2 -clev 3dB -slev -6dB <output>
或者
ffmpeg -i <input> -b:a 256k -filter:a “pan=stereo|FL < FL + 1.414FC + .5BL + .5SL|FR < FR + 1.414FC + .5BR + .5SR"  <output>

multi-channel encode

當影片來源是一個video (0:0) 卻有兩個audio(0:1、0:2)時
只需要0:2 這個音軌,那就下面這樣
ffmpeg -i <input> -map 0:0 -map 0:2 -c:v copy -c:a copy <output>
兩個音軌都要就
ffmpeg -i <input> -map 0:0 -map 0:1 -map 0:2 -c:v copy -c:a:0 copy -c:a:1 copy <output>

10bit 8bit 編碼 、Chroma subsampling不同的差異

最近想弄一些bdrip,所以做了一下基本的研究關於color space 與 採樣顏色的差異
source

首先講一下Chroma subsampling是什麼東西
眼睛對亮度最為敏感再接下來才是色度、濃度

在數位化資料中也是採取這個方式進行
也就是一般認知的 YUV or YCbCr
而採樣的方式主要有4:4:4、4:2:2、4:2:0
第一個數字是亮度的解析度 4代表1:1完全採樣
眼睛對亮度最敏感當然這邊絕對需要完全採樣
4:4:4代表的意思是顏色 垂直採樣1:1 水平採樣1:1 非Y之其他兩分量示意圖
4:2:2代表的意思是顏色 垂直採樣1:1 水平採樣2:1 非Y之其他兩分量示意圖
4:2:0代表的意思是顏色 垂直採樣2:1 水平採樣2:1 非Y之其他兩分量示意圖

越編碼越模糊,很大一部份的原因在於Chroma subsampling的部份
目前主流是4:2:0(BD、DVD都是這個),每編碼一次 色度部份就模糊一半
雖然由於亮度1:1完全採樣 即便色度採樣模糊一半 實際上帶來的模糊感沒這麼嚴重
這邊有範例說明

Q:採樣1:1、2:1 會影響到編碼出來影片的大小嗎?
A:不會,影片採的是失真壓縮,只要內容沒有變得更複雜
採樣的方式不會影響到編碼出來影片的大小
會受到影響的是未壓縮的raw 影片,這在錄影 或者需要傳輸raw訊號的應用有影響

就我自己嘗試的結果4:4:4 編碼出來的影片可能還是最小的
(比4:2:2、4:2:0 小個10~20%)
實際上失真壓縮採用 4:2:2 就蠻夠用了,可以比對最下面的實際編碼圖
4:4:4畫面跟4:2:2非常類似,但檔案可以比4:2:0小10% 要用4:4:4 也是OK的

至於8bit、10bit 網路上常常找的到色階示意圖,其實這有很大的問題
市面上絕大多數螢幕是8bit
10bit 圖在8bit的螢幕下看 跟8bit 的圖在8bit 的螢幕下看,是一模一樣的
除非有10bit 的螢幕 要不然任何人都看不出來 8bit 、10bit 的圖差在哪裡
當然影片也是如此,理論上不需要特別去編10bit 的影片在8bit的螢幕下看
畢竟沒有辦法看出來差異,
其實就連要從8bit 的畫面要分出色階差異對一般人來說就有很大的困難性

不過影片是個例外
主流媒體(BD、DVD…) source 可能是10bit 或是12bit,只不過編碼出來的是 8bit
廠商為了要在8bit 的環境顯示類似source的顏色,導入了dither
dither 是用很多雜點分佈來取代不能8bit 表現不出來10bit 色階的方式
dither 產生的雜點是吃掉頻寬的殺手級人物
實在不需要為了硬表現出不能表現出的顏色 弄出這些雜點吃掉頻寬
吃掉的頻寬會導致主體的細節因頻寬不足而模糊掉 實在得不償失
就影片來說10bit 編碼的存在有其必要性,至少他可以避免dither 吃掉頻寬
(10bit 以上可能也不需要dither 產生雜點了,可以說沒人能分辨出來)

實際上編碼的情形是如何呢?
以下提供編碼出來的結果,source 原本是1080p(4:2:0 8bit)
透過縮小至720p 減少source 4:2:0取樣模糊的比例 (讓source更接近於4:4:4)
且由於編碼的頻寬大幅縮小至原來的1/10~1/7 頻寬不足 雜點會消失
取代的是10bit的色塊,在8bit的螢幕下看則是連續的

source
10bit-444
8bit-422
10bit-422
8bit-420
10bit-420

可以看出重新編碼後的畫質乍看之下 還比source 來的好
但這沒採取任何post processing effect

只不過很可惜H264 一般硬解只支援8bit,要10bit 只能靠軟解
一般mobile 裝置效能不足以軟解1080p (甚至於720p也是) 的H264

SFC Video output comparison

點進去可以看動態比對圖

SFC(SNES) output comparison

發現很少人實際上比對過RGB 跟 S端子 的差異
頂多只看到有人用相機拍電視來比對

今天就特別把這兩個side by side 來比對

顏色是差最多的,RGB整體顏色偏白
採RGB output的顏色感覺就像bsnes (higan) 那樣
S端子 就是bsnes (higan) 把 color emulation 打勾 那樣

S端子畫面都有著很細的斜紋 (間隔兩個像素),影片上看不出來
特定畫面會有一些詭異的細節出現,這影片上可以看得出來
之後有空再補上圖片

結論:
S端子顏色上我個人比較喜歡,可是S端子有著沒辦法避免的瑕疵 (在RGB則無)
RGB看起來乾乾淨淨的,S端子看起來就有點黑黑髒髒的感覺

把超任改成有色差端子輸出應該可以解決這個現象
可是問題在於我改了但沒成功 Orz
不清楚是LCD電視不吃480i的色差 還是改的有問題

minidlan should run as …

/etc/default/minidlna

USER="minidlna"

sudo service minidlna restart

ssh login should be allow

sudo nano /etc/ssh/sshd_config
AllowUsers XXX OOO
or
AllowGroups XXX OOO
not both
sudo /etc/init.d/ssh restart

Previous Older Entries