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

距離上次出現有關視網膜螢幕已經好幾年了
最近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之其他兩分量示意圖
也就是色度的解析度維持與Source相同

4:2:2
代表的意思是顏色 垂直採樣1:1 水平採樣2:1 非Y之其他兩分量示意圖
色度垂直的解析度與Source相同,水平解析度則是減半

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: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 的圖差在哪裡
(以上純就同樣RGB來相比是這樣,但如果是RGB轉YUV的話就看得出來差異了)
當然影片也是如此,理論上不需要特別去編10bit 的影片在8bit的螢幕下看
畢竟沒有辦法看出來差異
其實就連要從8bit 的畫面要分出色階差異對一般人來說就有很大的困難性
(修正:因為8bit YUV沒辦法重現8bit的RGB顏色 實際上還是需要10bit的YUV)
但影片的話轉換上有一些意外的運算bug存在
這bug讓8bit YUV編出的影片沒辦法完整重現8bit RGB的顏色
(YUV <->RGB轉換顏色上不完全可以100%對應)
要顯示出8bit的RGB顏色,首先影片必須要採用10bit的YUV編碼

主流媒體(BD、DVD…) 或許影片source 可能是10bit 或是12bit
只不過編碼出來一定要是 8bit(因為BD、DVD制定的標準就是8bit)
由於8bit的YUV 影片沒辦法呈現8bit RGB的全部顏色
所以到使用者端一定會有色階的問題
廠商為了要在8bit 的YUV環境顯示類似source的顏色,導入了dither
dither 是用很多雜點分佈來取代不能8bit 表現不出來10bit 色階的方式
dither 產生的雜點是吃掉頻寬的殺手級人物
實在不需要為了硬表現出8bitYUV不能表現出的顏色 弄出這些雜點吃掉頻寬
吃掉的頻寬會導致主體的細節因頻寬不足而模糊掉 實在得不償失
但就影片來說10bit 編碼的存在有其必要性
他不僅可以避免dither 吃掉頻寬
也可以讓8bit YUV沒辦法呈現8bit RGB,一定會有色階的問題得到改善
(10bit 以上也就不需要dither 產生雜點了,可以說沒人能分辨出來)

至於實際上編碼的情形是如何呢?
以下提供編碼出來的結果
由於沒辦法獲取4:4:4的Video source作為編碼比較
所以將原本source 是1080p(4:2:0 8bit)的BD影片
透過縮小的步驟 讓720p讓色度的垂直、水平解析度更接近於4:4:4
來進行實際上的編碼比較

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

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

只不過很可惜H264 一般硬解只支援8bit,要10bit 只能靠軟解
一般mobile 裝置效能不足以軟解1080p (甚至於720p也是) 的H264
H265的話已經把10bit納進支援標準內,未來很有可能可以直接硬解H265

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