K75thunderbirdのブログ

どちらかというと自分の頭の整理用です。ネタとしてはモバイル、自動車、ロードバイク、電気関係やPC関係の突っ込んだ話題、ややデバイスやコンポーネント寄りの偏った内容になると思われます。

放熱は物量がモノを言う、という当たり前の結論

NVMeタイプのSSDで発熱と戦っている方々、いかがお過ごしだろうか。
冬になって、ほっと一息ついているのではないだろうか。
そんなわけで、今日は放熱について。

 

放熱と言えばヒートシンク、ヒートパイプ、はては水冷から液冷からガス冷まで様々あるが、今回はもっとも単純で簡単なヒートシンクに限定したい。

ヒートシンクの素材にはアルミ、あるいは銅が使用されるが、違いは重量だけではない。
銅の方が熱伝導率は良いのだが、アルミの方が自己放熱性が良い。
そのため、パッシブヒートシンクや風量の少ない状態ではアルミの方が放熱性能が高かったりする。

これに関しては、SSDに装着するヒートシンクの比較記事で、同じサイズに切ったアルミ板と銅板ではアルミの方が低温だったという結果が出ている。
たしか記事はエルミタージュだったと思う。
熱伝導率に優れる銅であっても、風がなければ性能を発揮できない例である。

余談だが、自動車のラジエータもアルミ製と銅製(黄銅だったはず)がある。
通常はアルミ製だが、社外品のアフターパーツではアルミ製ではないものもあるのだ。
これに関しては、走行時の性能は後者が高く、渋滞時は前者が高い、という話も聞いたことがある。
これも素材の性質を裏付けるものと言えよう。

さらに余談だが、普通のアルマイトとブラックアルマイトで性能差はあるのか?という話を思い出した。
ヒートシンクの雄であるアルファのページで読んだ記憶があるが、これはブラックアルマイトだそうだ。
ただし、周囲の熱源から赤外線で熱を吸収しない環境にあることが条件だとか。
なんとも面白い話である。

はては、ファンはヒートシンクに対して吹き付けるのが良いのか、吸い出すのが良いのか、といった話もあるが、それは脱線しすぎるので置いておくことにする。

 

さて、自己放熱性に優れるアルミ製のヒートシンクであるが、同じアルミ製であるなら性能差はどこから生じるのだろうか。
複雑な形状による表面積の拡大は当然だが、一連のSSDヒートシンクのテストを見ていると、ヒートシンクの重量が重要であるように思える。

たとえば、変換ボードを使って高い冷却性能を発揮している有名な製品として、KryoM.2がある。
ちなみに日本語でどのように発音するかは不明である。
くりょー?

それはさて置き、この製品はそれほど複雑な形状のヒートシンクではない。
隣のスロットとの干渉を避けるため溝も浅い。
しかしテストしてみれば圧倒的な冷却性能を示す。

これに対して、変換ボードを使わないSSDサイズのヒートシンクの場合、縦方向に拡大して表面積を大きくした製品であってもKryoには及ばない。
接触面が熱伝導両面テープとシリコンの違いなのか?とも思ったが、そこまで相関性があるようにも見えない。

そのため、最大の違いはヒートシンクの重量ではないか、と思う。

NVMeとはいえSSDが発する熱量はそれほど大きなものではない。
まして、単体のヒートシンクとKryoのヒートシンクでは重量に何倍もの違いがある。
ヒートシンクの熱容量が増えれば、吸熱できる量も増える。
ただし熱伝達速度の問題もあるので、やみくもに表面積を増やしても実際に使用される面積は少ないのだろう。
熱源に対して、その熱量に見合った分の吸熱素材が、妥当な熱伝達の範囲内に十分な質量を持って存在していることが重要だと考えられる。
それにより、安定した冷却性能を獲得しているのだと考えるのが自然だ。

そうであれば、単体のヒートシンクも肉厚で重量化すれば性能を上げられると思うのだが、マザーボードに直接実装する関係上、製品のサイズには制限がある。
また、重量の増加によって使用中に脱落する危険も増す。
危険回避のためには確実に固定しなければならないが、実装上難しい。
そのようなわけで、簡単にヒートシンクを追加して得られる冷却性能は、それなりのものでしかない。
それが現状のようだ。

ただ、少しでも高い放熱性能を得たいのであれば、少しでも重たいヒートシンクを選ぶというのは判断基準としてはアリだろう。
確実に固定できれば、という但し書きつきで。

個人的には、過去のCPUクーラーを加工して格安かつ激冷を実現できないかと考えていたりするのだが、固定方法を確立できないのが最大のネックだ。
いっそのことPen4世代のCPUクーラーにSSDを2個並べて貼り付ければ相当強力に冷却できるはずだが、NVMeのSSDを2つ並べて使用できるマザーがなければ無理な話である上に、固定する方法を考えつかない。

ヒートシンクを見ているとゴムバンド(シリコンバンド)でSSDと束ねるような固定方法もあるが、耐久性はともかく見た目が悪い。
まして、テープで固定するような製品は簡単に浮きそうで怖い。

ここはパッシブヒートシンクを諦めてファンを使用すべきなのかもしれないが、NVMeなSSDは幅22㎜しかない。
しかしマザーボードとの干渉も考えると、それほど大きなファンは使用できない。
そのようなわけで、マザーボードに直接実装する場合はあまり効果的な冷却方法がない。
「何もしないよりマシ」と考えるしかないのかもしれない。

他に考えられるのは、PC内を負圧にしてサイドパネルからSSD周辺にダクトを作って風を当てる方法くらいだろうか。
問題は、エアフローが変わる(乱れる)ことで、他の熱源への影響があること。
数Wのために数十Wの熱源を無視することはできないので、難しいところだ。

あるいはSSDの場所を風洞化して、そこにブレードサーバーのごとく横方向に風を通せば・・・とも思ったが、それこそM/B上でユーザーができる範疇の話ではない。
アイディアだけはあるが、実現は難しい。

 

結局のところ、お手軽冷却はそれなりの結果しか得られず、性能を求めるのであればPCI-Eのレーンとスロットを犠牲にして変換基板を使うしかない、という現状を裏付ける結論となった。
そして、物理特性に逆らうのは面倒であるということだ。

 

 

取り留めの無い結論になってしまったが、こんなところで。

それでは皆さん、ごきげんよう

 

SSDでコントローラーが重要である理由

前回は、チップレベルの話について。
今回は、それを制御するコントローラーの話に移る。

 

最初に認識したいことは、NANDメモリは使いにくいメモリだ、ということだ。
何故か。
まず、NANDメモリには書き換え回数に制限がある。
これだけでも面倒だ。
そして、書き換えるときはブロック単位で書き換えなければならない。
更に面倒だ。

そう、HDDのようにセクター単位で書き換えることができないのだ。
そのため、あるファイルに1bitの修正を加えただけで、そのファイルが書き込まれたブロックを読み出し、ブロック内を消去し、修正後の情報を書き込むという動作をしなければならない。
限りある書き換え回数が必要以上に減ってしまう仕様、それがNANDメモリだ。

では、そのブロックはどれくらいの単位なのか。
手持ちのSSDで、予備ブロックと無効化された容量から計算したところ、512GBの製品で2MB、960GBの製品で4MBのようだ。
おそらく、製品の容量に応じてブロックの粒度は異なると思われる。
参考までに、上の2製品はCrucialで、コントローラーはMarvellで、NANDはMLCである。

NANDメモリの仕様は上に書いた通りなので、下手な使い方をすると頻繁に同じ場所を使用することで早期に寿命を迎えることは想像に難くない。
そこで、コントローラーには「ウェアレベリング」という機能が搭載されている。
名前のとおり、摩耗の平均化だ。
ここで改めて説明しておくと、ブロックの書き換えには 読み出し⇒消去⇒書き込み の3ステップが必要である。
書き込む先として使用頻度の少ないブロックを優先的に使用し、書き換えが特定のブロックに集中しないようにするのが、この機能の目的だ。

しかし、空き容量が少なくなってくると、ウェアレベリングに使用できる領域が減ってくる。
極端な話、空き容量が数%といった状態で使用していると、書き換え対象のブロックを分散させることが難しくなり、どうしても特定のブロックを酷使することになる。
NANDメモリは読み出しこそ高速なものの消去には時間がかかるため、空き容量が減少すると消去待ちの時間が表面化する。
これの顕著な例が「プチフリ」である。

このような時、消去に要する時間を隠蔽し、パフォーマンス低下を抑制するための手法が「オーバープロビジョニング領域」である。
あらかじめ一定量の消去済みブロックを用意しておく、というもので、別名は余剰領域である。
漢字の方が分かりやすいだろう、読んで字のとおりだ。
ユーザーが使用できない領域を事前に確保しておけば、パフォーマンス低下を防ぐことができ、ウェアレベリングも行いやすい。

なお、容量が256や512や1024といった数値ではなく、240や480や960といった数値になっているSSDは、出荷時にオーバープロビジョニング領域として何GBか確保されていることになる。
また余談であるが、SSDパーティションを作成する際に敢えて未使用領域を確保しておくという使い方も、同じ効果をもたらすようだ。


しかし、ここで疑問には思うかもしれない。
パーティションで区切ってしまえば、その領域は一生使われないままなのではないか?と。
しかし、これに関しては全く問題とはならない。
何故か。
確かに、HDDのような媒体であれば論理アドレス物理アドレスは一致しているため、一度パーティションを区切ってしまえば当該領域は物理的に未使用となる。
これに対してSSDの場合は論理アドレス物理アドレスが一致しない(参照テーブルはコントローラーだけが持つ)ため、PCから見て同じ場所であるとしても、物理的に同じ場所であり続けることはない。
つまり、当該領域はウェアレベリングにより移動し続けることになるため、未使用領域が固定されることはない。


さて、NANDのチップレベルでの耐久性低下については前回書いたとおりだが、コントローラーも手をこまねいているわけではない。
NANDの多値化に伴ってECCを強化し、仮にある程度までセルが劣化してエラーレートが増えたとしても問題なく使用できるようにしている。
これにより、同じNANDを使用していてもSSDとしての耐久性を上げることができる・・・とされている。

 

まだ書き足りない点もあるが、脳内メモとしては以上としたい。
Trimの話や、NVMeタイプの発熱の話、仮想SLCキャッシュの話、TLCの書き込み速度の話などについては、別途書くことにしたい。
KryoM.2に関連した話も、少しだけあるかもしれない。

 

 

それでは皆さん、ごきげんよう

今、SSDの信頼性と寿命を考える(NANDメモリ編)

このBlog開設から1年経ったというメールが届いた。
大した内容は書いていないが、これからも脳内整理を兼ねて時々情報を書き留めておきたい。

 

話は変わって、SSDだ。
既に使っておられる方が大半かと思う。
高速であり、耐衝撃性に優れ、低発熱で、非常に優秀なデバイスである。

現在、速度はI/Fの限界に迫るものを獲得し、アプリの起動時間はすでにこれ以上短縮できないまでに飽和している。
この点において登場当初から飛躍的な進歩を遂げたことは疑う余地がない。

しかし、上に挙げたような特徴を本当に信じ続けて良いだろうか。
今のSSDは昔のSSDと同じ扱いで良いのだろうか。
SSDに使われているデバイスの観点から考えてみたい。

 

SSDが一般的なデバイスになったのは、一つにはIntelが自社製品としてSSDを発売したことが大きかったのではないだろうか。
当初、SSDと言えば「プチフリ」という単語に表されるように、安定性に欠けるデバイスである感が拭えなかった。

確かに速い。しかし扱いが難しい。

そのような状況に対してIntelが高速性と安定性を兼ね備えた製品を投入し、割高であるにもかかわらず人気を博した。
以来、徐々にではあるが、極端に性能の悪いSSDは駆逐されてきたように思う。

そのIntelの製品投入と前後して、SSDを低価格にするための技術革新があった。
フラッシュメモリ(NAND)の多値化である。

それまで、NANDの1セルに1bitしか記録することができず、SSDが高コストである主因となっていた。
これが、1セルに2bitを記録できるようになったことで、単純に同一面積に倍の容量を記録できるようになり、文字通りコストが半減した。
非常に大きな進歩と言える。

しかし、喜べる事ばかりではない。
引き換えになったのは、NANDの耐久性である。

今までは、セルに記録された情報が0か1(2値)が見分けられればよかったため、相当劣化したセルでも何とか使用できた。
しかし、2bit記録の場合は0か0.33か0.66か1(4値)を見分ける必要がある。
そのため、セルが劣化してきた場合に数値が判別できなくなるまでのマージンが少ない。

では、NANDメモリはどれくらい使ったら寿命となるのか。
これは単純に書き換え回数に比例する、と考えてよい。
 ※正確には読むだけでも多少影響があるようだが事実上無視できると考えている

1bitの頃、SLCと呼ばれているNANDメモリは、10万回とも言われる高い耐久性を持っていた。
これが2bitになり、MLCと呼ばれるNANDメモリは、一気に5000~1万回程度の耐久性に落ちてしまった。
今は3bit記録のNANDメモリも登場し、これに至っては3000回を下回るレベルとも言われている。

 

もっと悪いニュースがある。
半導体は年々微細化し、それによりロジックの大規模化を進めてきた。
IntelSSDを投入した当初、NANDメモリは50nmまたは34nmといったプロセスルールで製造されていた。
それが今や15nmに到達している。
問題なのは、微細化するほどNANDメモリの耐久性が落ちることだ。
つまり、多値化と微細化により、NANDメモリの耐久性は加速度的に下降し続けていることになる。
実際、15nmに到達したのは2年ほど前になるが、それ以降更なる微細化が進んでいないことは耐久性に致命的な影響があることの裏づけと言える。

実際、現在のMLCタイプでも3000回という値を聞くこともあり、TLCに至っては1000回という話もある。
使い方によって耐久性は上下するので一概には言えないが、基本的に耐久性は新しい世代ほど落ちる傾向にある。
これだけは間違いない。

 

ここまでの話を見る限り、NANDメモリは古いほど耐久性があって安心できることになる。
では、今のSSDは安心して使用できない欠陥品なのだろうか。
答えは否、だ。

これに関しては良いニュースがある。

微細化を進めていたNANDメモリだが、微細化しすぎて壁に突き当たったのだ。
前述のとおり、ここ2年ほど微細化は行われていない。

だからなんだ?と思うかもしれない。
が、話はこれからである。

これ以上微細化できない(微細化しても十分な性能が確保できない)と知ったメーカーは、今まで平面方向に作成していた半導体を立体方向に作成し始めた。
生産コストの安い従来型のNANDメモリを作りつつ、積層プロセスで3次元化したNANDメモリも製造するのが、ここ数年の各社のトレンドとなっている。

勘違いしやすいのは、この3次元化は、積層パッケージとは別の話であることだ。
積層パッケージは、メモリチップをパッケージ化する際に何枚ものダイを積層し、チップの実装個数を減らす技術だ。
これに対して積層プロセスは、ダイ作成時にトランジスタを立体的に作成するもので、物理的には1枚のダイである。
ただし、共に組み合わせることは可能なので、積層プロセスで作成したダイを積層パッケージにした製品は存在する。
ややこしいが、分けて考えてほしい。

話を戻すと、3次元NANDは64層くらいまで実用化されており、100層近くまでは実用化が見えているのが現状だ。

で、多層化すると何が良いのか。
問題はここである。

それは、多層化することで、同一面積で飛躍的に記憶容量を増やすことが可能になったのと同時に、半導体の微細化を少し前のレベルまで戻すことが可能になったことだ。
語弊を恐れずに言い方を変えれば、古いプロセスルールで耐久性を確保しつつ、減ってしまった容量を立体方向で稼ぐことができる。
その結果、耐久性(書き換え可能回数)と容量を両立させることができる。
これがNANDメモリにとっての3次元化の最大のメリットだ。

ただ、メーカーは具体的なプロセスルールや書き換え回数などの情報を明かしていないため、どの程度改善されたかは不明だ。
各社の論文を調べれば分かることもあるかもしれないが、そこまでの確認を行っていないのは勘弁していただきたい。
しかし、著しく減少していた耐久性が3次元化によりある程度のレベルまで戻ったことは事実である。
これが、現状のNANDメモリである。

 

ここまでが、NANDメモリについての話となる。
大容量化の影には、耐久性とのトレードオフや構造の変更があったのだ。

次回は、そのNANDメモリを制御するコントローラーの話について書きたいと思う。

 

それでは皆さん、ごきげんよう

気難しいサイバーナビ

今日び、融通の利かないナビで動画を再生するとか時代遅れもいいところ・・・なのは承知だが、そこにある機能を使えないのは悔しいのも事実なので、メモとして記しておく。

何か、誰かの役に立てば。

 

 

現行のサイバーナビFMCして 1DIN+1DIN の製品が消滅してしまったので、車のレイアウト上FMC前のサイバーナビを使っている人も多いはず。

現在自分が使用しているのはAVIC-VH0009である。

 

 

対応フォーマットについて、公式からの情報は次のようになっている。

pioneer.jp

 

VC-1ビットレートは低すぎるので無視するとして、MPEG4かAVCが一般的だろう。

MPEG4 であれば Advanced Simple Profile で 720x480@30fps で 平均4MbpsまでOK。

AVCであれば Baseline Profile で 720x480@30fps で 平均2MbpsまでOK。

 

正直なところ、これだけでは情報が不足していて失敗するのは目に見えているので、適当に情報収集。

XMedia Recode 使ったらイケた、というざっくりした情報をつかんだので、いつも使っているツールでもあるので、これで設定を詰めていくことに。

 

このソフト、メーカーや用途別に相当数のプリセットを持っている。

その中に pioneer があるので、それを適当に使えば良い、ということだった。

ということで、デフォルトのまま変換。

ナビで認識されず、見事失敗。

 

ネットの情報など、所詮この程度です。

ちなみにどうでもいいことですが、ソースは閣下が中野でアレしたアレのアレです。

 

とりあえずメーカー別プリセットと決別し、MPEG4で試してみる。

平均ビットレート1500Kbpsで変換すると、一応再生可能だった。

が、ブロック状に画面が崩壊するので、ビットレートの変更が必要と判断。

PCでは崩壊しないため、情報過多の可能性を考え、ビットレートを1200に。

結果、更に崩壊が進行。

MPEG4は実用にならぬ。

 

そのようなわけで、メーカー別プリセットで失敗したAVCを使うしかないようだ。

普通にAVCで変換。

当然のように失敗。

ここで疑問に思ったのが、プロファイルレベルの4.1とか3.1とかの値である。

考えてみれば、pioneerのプロファイルでは3.1であった。

そしてAVCのデフォルトでは4.1である。

もしや・・・と思い、3にしてみると成功。

2.2でも成功。

2.1は解像度がVGA以下に落ちているようなので、そこで確認を打ち切り。

ということで、プロファイルレベルが2.2~3までであれば再生できることを確認。

 

その後、ビットレートを平均1500Kbpsから1200Kbpsに落としたものの、画面の崩壊なども起きないため、これくらいの低ビットレートでも問題はないのかもしれない。

 

 

さて、話をまとめてみる。

MPEG4はビットレートのわりに再生品質がダメなので論外とする。

VC-1ビットレートが低すぎるので問題外。

実質使えるのがAVCのみ。

AVCであれば、Baseline Profile@L2.2~L3 で 720x480@30fps で 平均2Mbpsまでが再生可能。

 

 

それでは皆さん、ごきげんよう

CMOSと動画の関係は面白い!

一眼レフや大面積なイメージャーを使ったカメラの動画対応状況を調べていたところ、
ルフレーム? 全画素読み出し? ピクセルビニング? 画素混合? 画素加算? クロップ? ラインスキップ? ドットバイドット?
このような感じで疑問符が大量に浮かんできたので、ざっくり調べたメモを残しておきます。

 

ルフレーム
ニコンのDSLR説明文で見ることが多い。
ルフレームと言われて思い出すのはCCDだ。
一般的なインターラインCCDは受光部と伝送部が平面配置、フルフレームCCDは受光部と伝送部が立体配置、よってインターライン式よりも感度やDレンジ特性の面で有利というものだった。
正確には立体配置というよりバケツリレーのようなイメージらしいが。
が、今回はCCDではなくCMOSである。
どうも、35mmフィルムフルサイズフォーマットの意味で使用されているようだ。
撮像素子の方式ではなく、面積の話であった。
微妙に紛らわしい。


全画素読み出し
読んで字のごとく、そのままの意味。
動画生成時に対象範囲を全画素を読み出し、映像エンジン内で縮小処理することで、モアレやジャギーなどが少ない。
現状、最も理想とされる方式がこれ。


ピクセルビニング or 画素混合 or 画素加算
これらは、ほぼ同義と考えていいはず。
読み出し前にイメージャーで一定数の画素を足し合わせて仮想的な1画素を生成し、信号を映像エンジンに出力する。
CCDの場合、飽和信号量の関係でDレンジが狭くなる弊害があったはずだが、CMOSではどうなっているのか。
気になるので今後確認してみたい。


ラインスキップ
恐らく、もっとも嫌われている間引き方式。
5Dmk2やD800が有名。
もっとも、D800では3ラインごとに読みだして画像生成してから最終的に縮小処理をかけているらしく、mk2よりマシという話で、ラインスキップが全て同列で無能というわけではなさそう。
とは言え、ジャギーが出やすいので積極的に使用する理由はない。


ドットバイドット
拡大も縮小もせずに済む領域のみ読みだすことで、後処理を最小限に抑える方式。
処理が軽く、そこそこキレはあるが、画角が狭くなり、絶対的な解像度・ノイズの点で全画素読み出しに及ばない。
D5とか1DXmk2とか5Dmk4の4K対応がこれ。
EOSについては画角について情報が少ない(ほぼない)ので、買ってから後悔した人は多いのでは。

 

というわけで、全画素読み出しがベスト。
次点で画素加算かドットバイドット。
ラインスキップが許されるのは小学s(ry

 

 

それなら、何故全画素読み出しが普及しないのか。

原因は2つ。
1つは信号処理の速度の問題。
もう1つはCMOSの動作速度の問題。


前者は理解しやすく、一般的だと思われる。
考え方は簡単。
4K30pが可能なら、2K120p(FHDと書くのが面倒なので2Kと表記)が可能、という単純計算である。
つまり、1秒間に処理するピクセル数を判断材料にする。
細かいことを言えばイコールにはならないだろうが、大雑把な考え方としてご理解いただきたい。
もっとも、この辺は半導体を物量投入し、消費電力と発熱を二の次にすればどうにかなるレベルの問題である。


問題は後者。
これに関しては、メーカーはマーケティング上マイナスになる事を話さないので、メーカーの発言は正確に理解する必要がある。
ただ、少し考えれば難しいことはない。

例えば・・・
RX100M5の動画は全画素読み出し方式である。
これはある意味正しい。
しかし、メーカーは「全画素読み出しによる4K動画記録が可能」と言っているにすぎない。
したがって、2Kでは(恐らく撮影モードによっては)全画素読み出しではない。

フレームレートの方面から考えると理解しやすい。
4Kのフレームレート上限は30fpsである。
2Kのフレームレート上限は120fpsである。
全画素読み出しする場合、対象となる範囲の画素を全て読み出すので、フレームレートと動画の解像度は関係がない。
つまり、記録解像度が4Kだろうが2Kだろうがそれ以下だろうが、全画素読み出しが可能なのは30fpsまでなのだ。
よって、何らかの方法で読み出す画素数を減らさない限り、120fpsは不可能となる。

余談だが、RX100系ではなくRX10系の場合、同じ世代(RX100M4世代)であってもセンサーの読み出しスピードを60fpsに高速化したと明記しているので、消費電力や発熱などの問題さえクリアできれば、全画素読み出しで60fpsは可能なのかもしれない。
この辺り、発売時の情報を見る限りは読み出しに使用するフロントエンドLSIの性能次第のようだ。
ただし、RX10系の連写速度はRX100系のそれと同じなので、動画に直接関係しないのかもしれない。
しかし、連写速度については映像エンジンの制約の可能性もあるので判断はできない。
ただ、一つ言えることとしては、CMOSから映像エンジンへのデーター転送はフロントエンドLSIの性能で引き上げることが可能、ということは事実のようだ。

ちなみに、CMOSの読み出し速度が積層化で5倍になったというのは受光素子からDRAMへの転送部分であって、最終的にはCMOS内部のDRAMから外部へデーター転送しなくてはならないので、ネックになっているのは外部への転送の部分である。
このチャンネル数を増やしたりクロックを上げたりできれば、一気に高速化が進むであろうが・・・今はまだ布石の段階か。

もう一つ余談だが、SONYEVF搭載機でEVFfpsを60から120に切り替えできるものがある。
これは解像度の低下を伴うと書かれているので、上に書いたような全画素読み出し速度を高速化する話とは別と考えて良い。

 

 

閑話休題
では、全画素読み出しの限界解像度はどのあたりにあるのか。

ただし、業務用・映画用などの桁違いに物量投入されているものを除く。
また、センサーサイズによって駆動周波数限界は違うはずだが、その辺の差異も無視する。


CMOSの高速性ということで考えると、上にも挙げたとおりSONYの積層系のCOMSセンサーがある。
RX10系は上に書いたようにセンサー読み出しが60fps、ただし静止画連写性能は上がっておらず、証拠不足のため保留。
よって、確実なのは全画素読み出しで4K30pのところまで。


他にも、2000万画素クラスのカメラで、全画素読み出しで4K30pを実現しているものはある。
そのため、普通に設計されたCMOSセンサーであれば、この辺り(2000万画素クラス、全画素読み出し30fps)が無難なところに思える。

APS-CセンサーのSONYのαで2400万画素で全画素読み出しのがあったのでは?という話もある。
確認してみると、24fpsなら全画素読み出しで2.4倍の画素数からの縮小処理となるものの、30fpsでは1.6倍の画素数からの縮小処理であるとされている。
画素加算か?と思いきや、単にクロップしているだけのようだ。


ここで大本命。
動画対応が最も進んでいるカメラといえばGH5だろう。
これは全画素読み出しの60p・・・という話をよく聞く。もし事実なら同世代の倍速近い性能を持つことになる。
これはとんでもない話だ。

しかし、GH4との比較で「イメージセンサーからの信号読み出し速度は1.7倍」とされている。
これはimpressやITmediaなどのリリース記事に書かれており、間違いない情報と言っていいだろう。
ちなみにGH4はGH3の2倍となっており、2K60pから4K30pに進歩しているので、公称値通りの変化だった。

このような数値を公表する場合、メーカーは自分に有利になるよう情報を展開するのが常である。
更に、画素数が1600万画素から2000万画素に増えていることを考えれば、4K30pが4K60pになるわけがない。
もっとも、単にフレームレートが1.7倍になったとしても、51fpsであり60fpsには届かない。

また、4Kフォトは60fpsであるのに対し、6Kフォトの記録は30fpsにとどまる。
60fpsでの全画素読み出しに成功しているのであれば、30fpsではなく60fpsを実現していても良いように思う。
もっとも、これはコーデック(H265)や映像エンジンの問題も考えられるが・・・。

さて、どう考えればよいのか。

いろいろ読み返しているうちに、そもそも思い違いをしている事に気づいた。

GH3もGH4も、動画撮影時の読み出し性能が全速力というわけではないのだ。
GH3は連写性能20fps、GH4は40fps。
共に1600万画素なので、読み出し性能は2倍である。矛盾は無い。
とすると、計算上はGH4で全画素読み出し4K30pが可能である(16:9エリアなら47.4fpsまで)ことになるが、映像エンジンにおける縮小処理が追いつかなかったと解釈すべきだろう。
あるいはイメージャーの発熱の問題があったのかもしれない。

なお、GH5は連写性能が12fpsと控えめになったので、この尺度での比較はできない。
が、1.7倍という情報を元に計算すると、40*1.7/2000*1600=54.4fpsとなる。
60fpsに届いていない!と焦るが、これが全領域を読み込んだ場合である。
16:9のエリアに絞れば、64fpsとなるので、無事に目的の性能を達成している。

余談であるが、GH5ではセンサー読み込み速度が2.5倍になり、ローリングシャッター歪が低減されたというメーカーの方の発言がある。
これはどのように解釈すればよいだろうか。
動画撮影に関しての発言だったことを考えれば、画素数が増えたことと60fps化を掛け合わせて2.5倍となっている、という趣旨と判断するのが無難だろう。
2000/1600*60/30=2.5
前述のとおり、イメージャーの全力駆動時の速度は1.7倍であるので、限定された条件下での速度が2.5倍というわけだ。
もっとも、GH4は4K撮影時に全画素読み出しではないので、厳密に言えばこの発言は正確とは言えないが、同じ土俵で比較するならば・・・と考えれば理解はできる。
また、いくら速度が高速化しても画素数が増えて相殺されれば時間軸方向での改善は無いのと等しいので、読み込み頻度が2倍になったと表現するのが親切だろうか。

よって、紆余曲折したが、GH5は全画素読み出しで4K60pを実現していると結論できる。
他社が 2000万画素で24fps、1700万画素で30fps、などと言っている最中に1700万画素で60fpsである。
素晴らしいと言えよう。

他に気になるのは、ピクセルあたりの情報を何ビット取得しているのか?
コンデジ向けの撮像素子であれば10bitや12bitといったところだが、デジタル一眼レフでは14bit記録になって久しいので、12bitか14bitと考えるのが妥当だ。
GH5では10bit記録をサポートしていることからも、今更10bitで読みだしているとは考えにくい。
とはいえ、高速性を求める処理で14bitは重いはずだ。
よって、12bitが妥当なところではなかろうか。

試しに1秒間のデーター量を計算してみると、1700万画素で12bitで60fpsの場合、12.24Gbpsとなる。
これだけの情報量をイメージャーから映像エンジンに転送し続けるのに何ch使っているのだろうか。
駆動周波数やプロトコルや信号のエンコード方法は何だろうか。
機会があれば調べてみたい。

 

 

ということで、GH5で大盛り上がりした話を強制的に戻そう。
ここで、改めてRX100M5の素子の仕様を考えてみたい。

4Kについては、30fpsまでなので全画素読み出しで確定。
2Kについては、30fpsであれば全画素の可能性が残っている。
60fpsであれば画素加算で画素数を半分以下にしなければいけない。
120fpsであれば画素加算で画素数を1/4以下にしなければいけない。
この辺りはフレームレートを変更してエッジを確認すれば判断できると思われる。

4K時の全画素は5472x3080。2x2の画素加算で2736x1540。3x3だと1824x1026.6・・・
2x2は2Kに対して2倍の画素数3x3は僅かに拡大処理が必要となる。
ロジック的には2x2で120fpsまで対応できるはずなので、拡大処理は非採用だと思いたい。

と、ここで気づいたことがある。
ピクセルビニングを行っても、フレームレートに影響するのは垂直方向の情報だけであり、水平方向のビニングはフレームレートに影響しないのだ。
とすると、4K30pを基準にすると、2K120pでは縦解像度を1/4にしなければならないことになる。
ほぼ720pだ。
これはどうしたものかと思ったが、積層CMOSでは 受光素子 > DRAM > 映像エンジン となっているので、DRAMから映像エンジンに転送するのは通常のCMOSの考え方を適用する必要はないはずだ。
よって、2x2のビニングを行ってDRAMに置いたデーターを映像エンジンに流していると考えて問題ない気がする。
 ※でもGH5は通常のCMOSだから180fpsの実効解像度は結構落ちているのでは疑惑・・・

 

ここで、持っているわけではないが、D850の仕様も考えてみる。
FXフォーマットDXフォーマット、共に4Kと2Kの撮影が可能とのこと。
FXフォーマットなら3830万画素、DXなら1644万画素。
前者は画素加算で確定。後者はもしかすると30fpsであれば全画素読み出しの可能性あり。
これはどこかで検証してもらいたいところだ。

 

そういえば、某impressのα7R2のレビューで、画素加算はノイズの点で全画素読み出しに劣ることになっている。
しかし、CMOSの仕様を何度も確認してみたが、ピクセルビニングはノイズを低減する方向に働くはずなのだ。
だとすると、ピクセルビニングでドットバイドット記録したものと、約2倍の画素数から縮小処理したものとでは、後者の方がノイズ低減効果が大きかったということになるのだが、こればかりは検証したわけではないので仮定の域を出ない。
何か良い検証の素材があれば試してみたい。

 

話が飛び飛びになってしまったが、この辺でメモを終了としたい。

RX100M5に搭載されたPP7のS-log2は感度2000以上の設定だが、その感度では9EV程度のDレンジしかないので機能は無駄では? とか、
CMOSピクセルビニングのDレンジは結局どうなるんだ? とか、
RX10M3は「高速フロントエンドLSIの搭載により、動いている被写体を撮影した際に生じるゆがみ(ローリングシャッター現象)を軽減」って書いてあるけど、5倍に高速化したのは受光素子からDRAM部分であって、そこにフロントエンド関係しそうにないんじゃないか? とか、
RX10M3からM4で読み出し速度1.7倍っていうのは連写性能が14コマから24コマにアップしているから納得できるけど、そもそも動画撮影で全画素読み出し4K30pやってるのと矛盾するんじゃ? とか、
http://dc.watch.impress.co.jp/docs/news/439455.html
この5倍速って積層の5倍速に活用されてる技術だよね? とか、
気になることは山盛りですが、今後確認していくことにしようかと。

 


それでは皆さん、ごきげんよう

Twitterに動画投稿できない悩み

もう疲れたので、簡潔にまとめておきます。
同じような悩みの人のヒントくらいになれば。

 

40秒くらいの普通の動画を普通にアップロードしようとしたのですが、アップロードすると最後の最後で「お前の動画、互換性ないから無理(意訳)」と蹴られてしまう現象に悩み続けました。
実際、半日くらいトラブルシューティングに使いましたよ。

 

Twitterとしての公式の情報は以下のとおり。

Q:
ブラウザからアップロードできる動画の解像度と縦横比を教えてください。

A:
最小解像度: 32 x 32
最大解像度: 1920 x 1200(および1200 x 1900)
縦横比: 1:2.39~2.39:1の範囲(両方の値を含む)
最大フレームレート: 40fps
最大ビットレート: 25Mbps


以上。
実にシンプルです。
普通に考えれば、それほど問題になることはなさそうですね。

 


だがしかし、何度動画を作り直してもエラーになってしまう。


フレームレートが悪いのかと思い、オリジナルを保持 > 30fps に変更したもののNG。
元々は29.97でした。

バッファ容量が大きすぎるのかと思い、24000 > 12000 に変更したもののNG。

最大レートを 12000、10000、など変えてみてもNGのまま。

解像度を変更してみたものの、1080p、720p、480p、どれもNG。

メインプロファイルはレベル4.1で問題ないはず。

フレームパッキングは、なし。これも互換性を考える上では問題ないはず。

OpenGDP 有効
キーフレーム間隔 自動
最小GOPサイズ 自動

Bフレーム数 3 から 2 に変更するもNGのまま。

Bフレームモード なし で問題ないはず。

 

ここで設定をリセット。
その後、いつもどおりにビットレート制御モードを品質へ変更 値は26
最大レートを2400から10000へ変更。

・・・もしやこの設定を変更したら変わるかも?

 


・・・ということで、結局のところ「ビットレート制御モードをVBRにする」で解決しました。
品質固定は結果だけ見れば無問題でも、ファイルとしては互換性に乏しいらしいです。

実際に設定したのは、
平均レート4500
最大レート10000

実際に作られたファイルは平均6000Kbpsくらいでしたが。
ま、2passではないので、仕方ないですね。

 


そんなわけで、散々悩んだ挙句、原因は自分が好んで使用していたビットレート制御方式だったようです。
再現性の確認はもう少ししてみますが、とりあえずメモも兼ねて書いておくことにします。
訂正などがあれば、追って修正することになるかと。

 

それでは皆さん、ごきげんよう

Afterburner、OverClockするか? DownClockするか?

ちょいメモ。
自分のPCで、Geforce GTX 1060 3GB を使ったときの消費電力測定。

 

 

定格(元々OCされてる)状態でマイニング時、144W
パワーターゲットを60%に設定(メモリは7.6⇒8.7GHzにOC)時、117W
アイドル時、38W
(グラボ非装着時のアイドル時、28W)

定格より60%の方がハッシュレートが良くて、しかも27W省電力。
しっかり差が出ています。

具体的な数値が確認できて、一安心です。

 

それでは皆さん、ごきげんよう