YANO's digital garage

ゼンリンが国内主要都市を3Dで再現するUnity対応3Dモデルデータを提供というニュース。

ケータイ Watch 記事より

3Dな都市景観モデルがUbuntuの壁紙になるのかしら？

…と思いきや、Unity (ユーザインタフェース)ではなく、Unity (ゲームエンジン)というのがあるらしい。

…そいつは、知らなかったな。orz

しかし、具体的には

今回提供されるデータは、ゼンリンがカーナビゲーション向けとして独自フォーマットで整備してきたものを、汎用性が高いフォーマット「FBX形式」に変換したもの。

という事なので、正確に言うとAutodesk FBXへの対応に過ぎない。

つまり、「FBX Plug-ins/Converter/QuickTime Viewer」などを使って、Unity (ゲームエンジン)以外の世界でも活用する術は沢山あるという事になるので、覚えておきたい。

それにしてもUnityに限らず、3分動画でマスターする初心者向けプログラミング学習サイト：ドットインストールとか、いろいろ便利なのがあるんだねぇ…

【参照】
●ケータイ Watch http://k-tai.impress.co.jp/
┣第533回：Unity とは 2011年9月27日
┗国内主要都市を3Dで再現、ゼンリンがUnity対応データを提供 2014年8月27日
●ITmedia ニュース http://www.itmedia.co.jp/news/
┗リアルな街並みがゲームに　ゼンリン、3D都市モデルデータをゲーム開発用に提供　秋葉原データを無償公開 2014年8月27日
●Unity - Game Engine http://japan.unity3d.com/
●uinyan．com http://uinyan.com/
┗【Unity】素人が7日間クソゲーを作り続けてわかったこと 2013年8月7日
●ドットインストール http://dotinstall.com/
┣C言語入門 (全22回)
┣MySQL入門 (全19回)
┣Java入門 (全23回)
┣JavaScript入門 (全24回)
┣Perl入門 (全19回)
┣PHP入門（基本編） (全32回)
┣PHP入門（応用編） (全12回)
┣Python入門 (全24回)
┣Ruby入門 (全23回)
┗Unity入門 (全26回)
●Wikipedia http://ja.wikipedia.org/wiki/
┣Ubuntu
┣Unity (ユーザインタフェース)
┗Unity (ゲームエンジン)

昨年11月より噴火活動を始めた小笠原諸島西之島。

2014/8/26 11:11 海上保安庁撮影 全景より

3月には「噴火前の約3.5倍」の面積に達したが、その後も活発な活動が続いていて、斜面崩落により父島に津波の恐れとか爆発的噴火の恐れもという心配まで出てきたそうだ。

7月4日には父島から無人航空機(UAV)を飛ばして調査、撮影したそうで、

面積は噴火前とくらべて1.08平方km増加して1.30平方kmとなった。最高標高は約74mで、体積は2220万立方m（東京ドームの約18倍）となった

という事だ。

西之島付近噴火活動　斜め写真なんて惚れ惚れするほど美しいのだけど、崩壊して津波なんて事にならないように祈るばかりだ。

【参照】
●YOMIURI ONLINE(読売新聞) http://www.yomiuri.co.jp/
┣西之島、斜面崩落の可能性…父島に津波の恐れも 2014年8月19日
┗西之島、爆発的噴火の恐れも…火口に溶岩だまり 2014年8月27日
●ナショナルジオグラフィック http://www.nationalgeographic.co.jp/
┣小笠原諸島、西之島沖に“新島” 2013年11月22日
┣小笠原の西之島、さらに拡大 2014年7月28日
┗西之島、新たな火口と溶岩マウンド確認 2014年8月28日
●INTERNET Watch http://internet.watch.impress.co.jp/
┣小笠原の「新しい島」、鮮明な航空写真を「Yahoo!地図」で見られるように 2013年12月13日
┣国土地理院、西之島・新島の3Dプリンター用データ公開 2013年3月7日
┗【趣味のインターネット地図ウォッチ】 第193回：UAVで西之島の空中写真を撮影／AR花火スコープ　ほか 2014年7月31日
●国土地理院 http://www.gsi.go.jp/
┗「地理院地図」に西之島付近の噴火活動関連情報を掲載しています　－７月４日に撮影した西之島－ 2014年7月23日
●海上保安庁 http://www.kaiho.mlit.go.jp/
┗海域火山データベース海上保安庁海洋情報部 >> 西之島
●Wikipedia http://ja.wikipedia.org/wiki/
┣西之島
┗西之島新島

昨日のトップニュース、日本海津波の予測 最大23.4m。

毎日新聞記事より

日本海の海底断層で発生する大規模地震に関し、国土交通省などの有識者検討会（座長・阿部勝征東京大名誉教授）は26日、日本海に面した各市町村で予測される津波高の最大値を発表した。国による初めての試算で、北海道せたな町の23.4メートルが最も大きく、青森から九州北部までの各県の最大値は17.4～2.6メートルだった。検討結果は、各道府県が今後実施する浸水地域の想定など津波対策に役立てられる。

という報道で、確かに最大23.4メートルとか最短1分というのは確かにショッキングな数字ではあるのだが、最大値よりも福岡市近辺ではどの程度の予測値なのか知りたい。

というわけで昨夜から国土交通省のサイトで元ネタを探しまくっていたのだが、ようやく日本海における大規模地震に関する調査検討会のページに辿り着き、第8回調査検討会配布資料が入手できた。

資料－４ 日本海における大規模地震に関する調査検討会報告書 図表集（案）の表８「60断層毎の市町村毎の平均津波高、最高津波高」に書いてあったが、福岡市では最大1.7m程度だが、北九州市で最大2.6m、岡垣町、宗像市、福津市においては最大4mを越えるという予測値がわかった。

fnn-news.comの「日本海における大規模地震に関する調査検討会」会見(全録:42分45秒)も必見。

日本海中部地震から30年、北海道南西沖地震からも20年、新潟地震も50年前ですか。幸い西日本の日本海側ではここ50年以上大きな津波は発生していない事になるが、9年前の福岡県西方沖地震では津波が起こらなかっただけに、却って不気味な気もする今日この頃だ。

【参照】
●Yahoo!ニュース http://news.yahoo.co.jp/
┗日本海津波の予測 最大23.4m(2014年8月26日(火)掲載)
●www.fnn-news.com http://www.fnn-news.com/
┗(全録)「日本海における大規模地震に関する調査検討会」会見
●国土交通省 http://www.mlit.go.jp/
┣日本海における大規模地震に関する調査検討会
┗第8回　日本海における大規模地震に関する調査検討会　配布資料一覧
●にいがた防災アクション2014 http://niigatajishin.com/
●Wikipedia http://ja.wikipedia.org/wiki/
┣新潟地震
┣日本海中部地震
┣北海道南西沖地震
┣福岡県西方沖地震
┗東北地方太平洋沖地震

完成形に達したと思っていたffmpegによるmp4エンコードだが、今頃なってbオプションで指定した5Mbpsに遠く及ばない1～2Mbps程度になっている事に気付いた。

CRF	1280x720p			720x480p
	rate (kbps)	Size (MB)	Time(s)	rate (kbps)	Size (MB)	Time(s)
15	7966	84	645	3860	41	210
16	7349	77	629	3419	37	204
17	6639	70	605	3032	33	199
18	5826	61	576	2693	29	189
19	5100	54	552	2399	26	184
20	4470	47	527	2142	24	180
21	3923	42	504	1915	21	173
22	3453	37	487	1715	19	170
23	3051	33	465	1541	17	164
24	2709	29	452	1388	16	160
25	2415	26	436	1252	14	158

なんてこったい。Intel Media SDKどころの話では無く、我ながらうっかりにも程があるというものだ。

改めて調べてみるとx264の場合、ビットレートはCRF(Constant Rate Factor)によってコントロールするのが筋で、bオプションは無効らしい。

突然CRFと言われても現状 /usr/local/share/ffmpeg/libx264-hq.ffpreset で "25" に設定されていた事以外はよくわからなかったものの、ググったところ0～51の設定範囲のほぼ中間値だが品質指標としては比較的低いという事なので、1～2Mbps程度になってしまったようだ。

実用的には20～22が良さそうだというのも同時に察しが付いたが、折角の機会なので自力で検証してみる事にして、85秒の動画(地デジフルHD1440x1080、MPEG2TSで260MB)をMP4エンコード(1280x720と720x480)でCRF値を15～25まで変えながら、エンコードした平均を表にしてみた。

なお、動作環境がXeon E3-1275 (8M Cache, 3.40 GHz)@gt110bとCore i3-2120 (3M Cache, 3.30 GHz)@ML110G7での各10回ずつ廻した結果（各CRFで合計20回）。動作クロックは大差無い事から処理時間もさほど変わらなかったのだが、別プロセスの負荷やストレージデバイスの反応速度などの差分もあるのであくまでも処理時間は参考程度で。

当然、品質(ビットレート)に比例して処理時間は長くファイルは大きくなるのが落とし処として難しいところなのだが、バランス的には20～22あたりが良さそうな雰囲気かな。

CRF20でエンコードした例

ちなみに、MediaEspressoでは1280x720サイズが6Mbpsで63MB、4Mbpsで42MB。QSVのおかげで処理時間はわずか6秒の爆速だが、じっくり見るとx264とは違って破綻が良く見られるのが残念。

【参照】
●もにっき http://tutinoko.org/blog/
┗x264のcrf値はどれくらいが適切なのか？ 2010年12月25日
●いろいろwiki@princo.org http://wiki.princo.org/
┗x264エンコーディングで固定品質(qp,crf)の設定値を比較 2010年12月25日

予てより模索中の"Linux環境におけるQSV対応"エンコード。

Open SourceなHandBrakeのMilestone QuickSync Betaを見つけた時にはテンションが上がったが、開けてみたらWindows版だけだったという顛末にガックリ。

しかし、お土産にqsv-ffmpeg-codecなるものを発見。しかし、Intel Media SDK for Serversが必要と言う事なので、30日評価版を導入したところ、libdrm-intel1とコンフリクトしているというエラー発生。

Installing and Running Intel Media SDK 2014 R2 for Servers on Linuxによると

Intel Media SDK for Linux Servers comes with a customized libdrm. To avoid conflicts please remove any other versions of libdrm from the system. Where this cannot be done through regular package management commands, this can be accomplished as below

という「やんごとない」事情があるらしく、

sudo find /usr –name 'libdrm*' -exec rm –rf {} \;

しろという事だ。

う～ん、お試し環境がもう1台欲しいところだなぁ…

【参照】
●HandBrake: Open Source Video Transcoder https://handbrake.fr/
┗Milestone QuickSync Beta
●Ubuntu Sharing http://ubuntuguide.net/
┗HandBrake 0.9.9 released: Install in Ubuntu 13.04, 12.04, 12.10
●Ubuntu パッケージ検索 http://packages.ubuntu.com/
┗Ubuntu – trusty の libdrm-intel1 パッケージに関する詳細
●qsv-ffmpeg-codec https://github.com/shenhailuanma/qsv-ffmpeg-codec
●Intel® Developer Zone https://software.intel.com/
┗Intel Media SDK for Servers
●インテル http://www.intel.co.jp/
┗クイック・シンク・ビデオ