コグノスケ

Appleとファウンドリ

「うわ... 私のiPhone 6sバッテリーもたない？」CPU違いの6sでバッテリーベンチをしてみました を読んで。

元々の原価が低いのか、FinFETで首位に立つべく値引きしたか、事情は知りませんが、廉価版のiPhoneほどSamsung製の搭載比率が大きいところを見ると、TSMCよりSamsungの方がAppleの利ザヤがデカいのでしょう。おそらく。

そういえばQualcommはSnapdragon 810（TSMC 20nm）で発熱問題に泣いて、次のSnapdragon 820はSamsung製らしいですね。16nm世代を採用したら次も泣かされそう…。

メモ: 技術系の話はFacebookから転記しておくことにした。

MPEG4-AVC / H.264の2つのフォーマット

今や映像の圧縮方式として当たり前となりつつあるMPEG4-AVC（※）には、2つの形式があります。

• ISO/IEC 14496-1: Annex B - Byte Stream Format
• ISO/IEC 14496-15: NAL File Format

Byte Stream Formatは、俗に言うスタートコード形式（0x000001を目印としてNALUが始まる）で、コンテナを使わない場合、リアルタイム配信（RTSP）、放送系（MPEG2-TSをコンテナ）で良く使われているようです。

利点としては「欠け」に強いことです。何か問題が発生してデータが欠けてしまっても、スタートコードさえ見つかれば、その地点から処理を再開できます。その分、毎度スタートコードを探す処理が必要がある、先頭が欠けても再生できるように重複して情報を入れる必要があるなど、やや非効率的です。

NAL File Formatは、いわゆるサイズ指定形式（数バイトのサイズの後にNALUが始まる）です。ファイル形式（MP4など）に良く使われているようです。

利点としては「効率的」であることです。余分な情報はコンテナに持たせて、ビットストリームからは取り去りますのでサイズが小さくできます。NALUのサイズも予めわかりますから不要なNALUをスキップする際の負荷も低いです。その分、1バイトでも欠けてしまうと、デコードできなくなってしまう弱さもあります。

実はこの2つを変換するのは面倒で、サイズ指定をスタートコードに置き換えるだけではダメです。そんな単純な変換では、上記のような特徴が出せません…。

（※）AVCはAdvanced Video Codecの略です。この規格はISO/IECとITU-Tの共同規格なので、MPEG4-AVCではなくITU-Tの規格名であるH.264と呼ぶ人も多いですね。

変換ツールの使い方

でも、自分でそのような処理を書く必要はありません。世の中にはナイスガイ達が居て、変換が可能なツールを公開してくれています。ありがたいことです。

まずはffmpegを使う場合ですが、コーデックは変更しないのでcopyを指定して、普段の利用ではあまり見かけないbsfオプションを使って変換します。

なぜmp4toannexbという名前かと言うと、MPEG4-AVCの規格であるISO/IEC 14496-1 Annex BにByte Stream Formatの規格が示されているからではないか？と思われます。

avconv -i /path/to/hogehoge.mp4 -vcodec copy -bsf:v h264_mp4toannexb hogehoge.h264

Gstreamerを使う場合はh264parseエレメントを使います。ffmpegと比べるとかなり長く感じますが、大したことはしていないです。

例では、改行を入れていますが、実際には改行を入れずに1行で書いてください。もしGstreamer 1.0系を使う場合は、video_00のところをvideo_0と書く必要があったはずです。たぶん。

 gst-launch filesrc location=/path/to/hogehoge.mp4 ! 
 qtdemux name=dem dem.video_00 ! 
 h264parse ! 
 video/x-h264,stream-format=byte-stream,alignment=au ! 
 filesink location=/path/to/es/hogehoge.h264

普通に動画を楽しんでいる人には、こんな変換は全く縁がありませんが、私にとっては便利なんです。こんなツール達がオープンソースで公開されているというのは、ありがたいことですなー…。

ちぐはぐなVisual Studioのエディタとコンパイラ

Visual Studio 2015のコンパイラは、未だにBOMを付けないとUTF-8を認識しません。なぜかShift-JISもコンパイルエラーになります（2013ではなりません）。

MSDNライブラリ（サイトへのリンク）でも「コンパイラおよびリンカーでのUnicodeのサポート（... 中略 ...）BOM付きのUTF-8」などと言いきる始末です。イマイチすぎる…。

Visual StudioのIDEはGitに対応したり、エディタがマルチプラットフォームになったり、コミュニティベース開発に力を入れたり、時代の流れに沿って進化していますが、

コンパイラはダメダメ感が漂います。C++0xの対応はllvm, gccの後塵を拝しワーストです。もはやMicrosoftですら単独でC/C++ コンパイラを開発するのは不可能なのかなあ…？

メモ: 技術系の話はFacebookから転記しておくことにした。

ジージェネレーションフロンティア

SDガンダム ジージェネレーションフロンティアの話。今までのFR設計イベントをメモしておきます。

第一弾

FRアカツキ（シラヌイ）/ 誘導機動ビーム砲塔システム
-- URゲーマルク（覚醒）/マザー＆チルド・ファンネル
-- URシナンジュ /バズーカ
-- URドム/ジェットストリームアタック
-- URデスティニーガンダム（最大稼働）/パルマフィオキーナ

第二弾

FR νガンダム/連続格闘
-- URクロスボーン・ガンダムX1改・改/ヒートダガー＆スクリュー・ウェッブ
-- URサザビー/ファンネル（Ver.2）
-- URジ・O（覚醒）/ビーム・ソード/四刀流 
-- URアルトロンガンダム/ドラゴンハング

第三弾

FRガンダムアヴァランチエクシア/GNソード/ソードモード
-- URストライクルージュ（IWSP)/一斉発射
-- URノイエ・ジール/有線クロー・アーム
-- UR ∀ガンダム/核弾頭
-- URケルディムガンダムGNHW（トランザム）/GNライフルビット

第四弾

FRガンダムデルタカイ/プロト・フィン・ファンネル
-- URグフ・カスタム/ヒート・ワイヤー
-- URガンダムDX（Gファルコン）/ツインサテライトキャノン
-- URデストロイガンダム/ツォーンMk2＆スーパースキュラ
-- URデルタガンダム/ビーム・サーベル/二刀流

第五弾

FRガンダムAGE-2ノーマル/MS/ハイパードッズライフル
-- URザクII改/ヒート・ホーク＆ダミーバルーン爆弾
-- URトールギスIII/メガキャノン/最大出力
-- URガンダムAGE-1ノーマル/ドッズライフル
-- URラフレシア/親バグ＆子バグ

これらのイベントは既に終わっていますが、しばらく経つと再実施されるようです。作り逃したFRキャラクターが居ても、後でまた作れるかもしれませんので、材料となるURキャラクターを、間違って処分してしまわないようにメモしておきます。

しばらくやってみた感想

楽しい点は、小学生の時にハマっていたSDガンダムのカードダス集めの気分が味わえることです。特にFRキャラクター（カードダスのキラキラカードに相当）が当たった時は、出たこれ！って気分で嬉しいですね。

ゲームとしてはつまらないです。もし同じ面を100回以上やる「イベント」を、毎週連発するだけのゲームが面白い！好き！と思う人が居ればオススメしますが…。私は立ちながらか、歩きながらプレイしないと確実に寝ます。

嫌いな点はUIです。いちいちボタンを押さないと進まないのに、ボタンの配置に統一感がありません。片手で遊びづらいです。

ネットワークドライブ上の実行ファイル

Visual Studio Community 2015をインストールしてみたので、適当なプロジェクトを作成して、デバッグしようとすると「アクセスが拒否されました」と怒られました。なんだ、いつのまにこんなことに…？

どうもプロジェクトをsambaの共有ドライブ上に作成していたのが良くないようで、生成されたexeファイルを直接実行しようとしても「アクセスできません」と怒られてしまいます。

原因

Sambaのデフォルトの設定だとWindows側からファイルを作成すると全てのファイルがパーミッション0755で作成されてしまい、実行ファイルでもないファイルに実行権限が付いてしまいます。

これはLinuxからファイルを見る時に非常にウザいので、私の環境ではSambaの設定にcreate mask = 0644を追加しています。しかし、この設定だとexeファイルもパーミッションが0644で作成されてしまいます。

Sambaはパーミッション0644をWindowsのACLに変換するとき「実行権限が無い」と解釈するため、Windows側が「実行してはいけないファイルを実行するな」と怒っているようです。

対症療法

Linux側から手動でexeファイルのパーミッションを644から755に変更すると、実行できるようになりますが、ビルドの度にパーミッションが644に戻るので、毎回変更しなければならずダルくてやっていられません。

逆にWindows側から実行権を付けようと [プロパティ] - [セキュリティ] - [編集] ボタンから、実行権限を付加しても、ファイルのパーミッションに全く反映されません。

解決方法

この問題に半日悩んでいたのですが、実は非常に簡単な設定がありました。

Sambaの設定にacl allow execute always = yesを加えれば解決しました。このオプションは名前の通り、ファイルは常に実行可能、と解釈するオプションのようです。

なぜか日本語のヘルプが見あたらないのですが、最近追加されたオプションなのでしょうか？まあ、今となってはどうでも良いですが…。

ちなみにSambaの設定ファイルは /etc/samba/smb.confです。もし現在のSambaの設定の一覧を調べたければtestparmコマンドを使ってください。便利です。

進撃の巨人3D VRシアター

グランフロント大阪（大阪市北区）に、進撃の巨人展に併設の3D VRシアター「哮」を見に来ました。

チケットに書いてあるフォルムからして、ソニーのHMDじゃなさそう、機材はOculus Riftですかね。

上映室を入り口から撮影

上映時間は5分くらいとのこと。見終わったらまた感想でも書きます。

鑑賞後の感想

見てきました。ストーリーは無いに等しいです。立体機動装置って何？くらいを知っていれば楽しめると思います。

映像はキレイとは言えませんが、画が動いていれば、荒さは気になりません。

視点の動きは立体機動にしては大人し目ですが、もしミカサやアルミン並の上下動をされたら、メチャクチャ酔うと思います。おそらく物足りない位がちょうど良いのでしょう…。

映画と違うなーと思うところは、やはり枠の概念がないことでしょうか。振り返ると真後ろの景色が見えるのはとても斬新です。

• 視聴者が好き勝手に違う場所を見るので、制作側は見せたい部分を強調しづらい
• 都合の悪い部分を枠の外に追い出せない（視野外を端折る、演出上わざと破綻させる、など）

技術面でも、

• カメラで撮る方法がない（必ず撮影者が映っちゃう）、半天ならできるかな？
• 全視野対応の映像を作成、提供する方法が確立されていない

後者はすぐ解決されると思いますが、何かしらの標準ができるまでは、互換性やフォーマット乱立で揉めそうな予感がします。

YouTubeが一部、全視野対応の動画を配信していた気がしますが、あれ半天だったかな？

あと、見る前は、映画館のように暗い部屋で見るのかと思っていたのですが、写真のように明るい部屋での上映でした。Oculusは視界を覆うゴーグルタイプだから、周りの明るさは関係ないんですなー。

ただ、端から見るとかなり怪しい集団です…。なんだこれ。

上映室を入り口から撮影

メモ: 技術系の話はFacebookから転記しておくことにした。