印刷所のWebサイトで直接作ってそのまま注文できる、初めてのアイマスP名刺の作り方

はい。フサギコです。

この記事を開かれているということは、

アイドルマスターを楽しんでいる人たちは自分の名刺を作って、名刺交換をして交流しているらしい。
でも自分の名刺なんてどうやって作ればいいかわからない…

というお悩みをお持ちなのではないでしょうか。

そこでこの記事では、専門的な知識は可能な限り放り投げて、
「とにかくまず、及第点くらいの名刺を印刷所発注で作ってみる」ためにはどうすればいいか、
そして発展的内容として独自性の出していきかたについてお話ししようと思います。

僕自身、そんなにデザインセンスがあるわけではないので、下記のようなデザインでちょくちょく改修しながら5年ほど使っています。

担当アイドル増えすぎてさすがにちょっと野暮ったくなってきたな…w

この記事を読み終わると最終的にこれができあがります。

目次

気が早い人向けにまず結論

今の時代では、印刷所のWebサイト上でデザインを作ってそのまま発注できるようになっているので、それを使いましょう。

もうちょっと詳しく

10年前とかだと稀によく聞くAdobeillustratorとかでデータ作って入稿しないといけなかったんですが、
技術が進んだ今の時代、なんと印刷所のWebサイトでデザインを作ってそのまま発注できるようになっているので、
めちゃくちゃ凝ったデザインを作りたい、という段階まで到達していなければWebサイトからの発注だけで完結してしまいます。

この記事では、僕が愛用している印刷所であるマヒトデザインさんの画面を例にして解説します。
2012年くらいからたびたび発注しているんですが、首都圏だと翌日とか翌々日に届きます。速すぎる。

マヒトデザインさんの名刺テンプレート一覧を開くといろいろ作例が並んでいるんですが、今回は一番左上にある白紙から作っていきます。


カラー、横向きを選択し、作成ボタンをクリックすると、下記のようなデザイン画面が出ます。

この世でいちばんシンプルな名刺

名刺に最低限書いてあると良いのは下記の2つです。

  • 名前
  • 連絡先

これだけ。

左にある編集パネルで上から順に、

  1. 文字タブを選択
  2. 書体を選択
    • 明朝体、ゴシック体、丸ゴシック体が無難で、その中でも明朝体が最もフォーマル、丸ゴが少しカジュアルな印象になります。
      それ以外は個性がかなり強いのでお好みで。おすすめは丸ゴ。
  3. サイズを入力
  4. (複数行あるとき)行の揃え方
  5. 内容を入力
  6. 塗り(文字色)を選択
  7. 線(縁取り)の色と太さを選択

するとデザインに文字を入れられます。 ほかの項目はいったん無視でOK。

  • 書体: 丸ゴシック体-普通
  • サイズ: 48
  • 塗り: 黒
  • 線: 透明(白に赤の斜線) 太さなし

でOKを押すとこうなります。 名前は一番重要なので真ん中にでっかく。

連絡先として、TwitterのIDと、追加でBlueskyのID*1も載せることにします。
文字サイズ10で入力するとこうなります。

この世でいちばんシンプルな名刺、完成です。

ぶっちゃけこのまま右上の「デザインを決定する」ボタンをクリックして、マヒトデザインさんにユーザ登録して、裏面デザインなしで発注していい。

発注する

右上の「デザインを決定する」ボタンをクリックすると、このような画面になります。

裏面もデザインしたければ「ウラ面のデザイン作成」ボタンを押すとウラ面のテンプレート選択画面になりますが、裏面デザインなしでも問題ないです。
裏面が空白だと受け取った人がいつ会ったか、みたいなメモができるのでそれはそれで便利です。

そして一番右の「デザインを保存する」から保存しておきましょう。次回以降は選択するだけで同じデザインを発注できるようになります。

注文管理名を入力して「用紙・営業日の選択に進む」ボタンを押すと下記の画面になり、ここで紙の種類と納期を選択することになります。

紙の種類についてですが、少し良い紙にしたい場合はマシュマロホワイト180kgやマットポスト220kg、価格重視なら上質紙180kgが一番お手頃です。
僕はとにかくたくさんの方々と名刺交換をしていてたくさん配っているのでずっと上質紙180kgです。
もちろんせっかく作る名刺ですから、マシュマロホワイト180kgやマットポスト220kg、あるいはもっとこだわりの別の紙にしたりするとそれはそれで質感が変わってテンション上がると思います。

次に納期ですが、これは緩ければ緩いだけ安くなります。この名刺をいつ使いたいかによって選択しましょう。
表記は出荷日の期限なので、また別途配送にかかる日数があることに注意が必要です。

あとは配送先の入力とかクレカでの支払いとかすれば終わりです。

というわけで、これだけでもう名刺として成立するものを注文できました。及第点です。

ここから先で書く内容は全部追加点です。

独自のデザインにしていく

肩書を付けてみる

我々はプロデューサーなので、どのアイドルの担当プロデューサーかを載せてみましょう。 載せておくと好きなアイドルを軸に話題が広がったりします。

文字サイズ16で乗せてみた例がこちら。

背景と文字の色を変えてみる

上水流宇宙担当プロデューサーと記載したので、背景と文字の色を青系にしてみましょう。

背景色は右に並んでいる「表示パネル」の中から一番下の四角をクリックすると変更できます。
また、文字の色は画面上の文字をクリックして選択し、編集パネルの中の塗りを変更してOKを押せば反映されます。

担当アイドルのイメージカラーが明るい色なので読みづらい…という場合は同系統の暗い色で縁取りをするのも手です。

縁取りをするとかなり目立つ(重くなる)ので、全ての文字を縁取りにするのは避けましょう。

SNSのアイコンを載せてみる

SNSのアイコンを載せてみましょう。

編集パネルの画像タブからユーザ画像を選択し、新規画像登録ボタンを押すとアップロードできます。

名前のフォントサイズが大きくてアイコンを置く場所がなかったので文字サイズを調整して、こうなりました。
上から順に12、40、10にしています。

背景を2色にしてみる

背景が一色だとのっぺりとした印象になってしまうので、2色にしてみましょう。

背景色は白に戻してしまって、編集パネルの図形タブからカスタムシェイプ、上段中央の四角を選び、塗りの色を選択してOKで追加しましょう。

専門的知識はできるだけ放り投げるというこの記事の方針によって今更なんですが、 右下に2つあるボタンの右のほうをクリックすると、画面上に印刷範囲が点線として表示されます。

上の画像に書いてある通りなんですが、赤い線が仕上がりサイズです。
また、名刺は紙の裁断位置がずれる可能性があるので背景をフチなしで印刷するときには青い点線まで満たし、
途切れては困る文字や画像は緑の点線の中に収める必要があります。

というわけで2色塗り分けにしてみたのがこちら。

斜めにして文字とアイコンの位置を調整してみたり。

基本的に同系統の濃い色と薄い色でやるのが簡単ですが、赤と青のような正反対の色にしたりもできます。
この辺は配色の知識の話になるのでこの記事ではこれ以上詳しく扱いません。

というわけで

ここまでの全部をやった結果はこんな感じになります、なりました。

あとはもうこのデザインを保存して注文するだけです。できた。

難しいことしなくてもそれっぽく見せるコツ

難しいことしなくてもそれっぽく見せるコツとしては、

  • 重要な内容を大きく、細かい内容は小さく
    • 文字サイズの差を大きくするとフォーマルさが減りますが、まあ趣味名刺なので
  • 載せる内容は絞りこむ
    • 多すぎるとゴチャゴチャしてしまう
    • 記事冒頭に貼った僕の名刺がだいぶギリギリ(担当アイドル増えすぎやねん…)
  • 色は同系の濃い色薄い色でまとめる
    • 色相が違う色を組み合わせるのは配色の知識が要るので慣れてからで
  • 文字が背景と十分にコントラストがあって読めるかどうか気を付ける
    • どうしてもという場合は縁取りで対処する

が意識できていると十分すぎるくらいだと思います。

より発展的には

濃い背景色の領域や文字、画像を重りと考えて、それらの重心が名刺の真ん中に来るような配置になっているとバランスが取れているように見える配置となります。なので下記みたいな配置もアリ。

まとめ

この記事ではアイマス名刺を初めて作ってみたくなったかたへ、マヒトデザインさんのWebデザインツールを例に名刺の作り方、印刷所発注のやり方を書いてみました。

お気付きかと思いますが、名刺を作るのに使った画像はSNSのアイコンだけで、新しい絵を描いたりは一切していません。
Adobe Illustratorのような専門的な高いソフトも要りません。
なぜなら印刷所のWebサイトで作ってそのまま注文できるからです。

といあわけでアイマス名刺、ぜひ作ってみてください。
もし機会があったらぜひ名刺交換しましょう。

*1:僕は特殊な設定をしているのでfusagiko.jpですが、普通はfusagiko.bsky.socialみたいな形式だと思います

会社ブログを書いていた15

developers.bookwalker.jp

先日開催されたKaigi on Rails 2024に参加したので、その参加報告ブログを書いていました。

記事にも書きましたけど、処理系としてのRubyの高速化のための各種手法などといった計算機科学方面の興味を刺激するRubyKaigiとは違って、普段のRailsでの開発において参考になる、Railsで開発するのを頑張ろうと思えたのがKaigi on Railsの特色だなと思いました。

そしてKaigi on Railsのあとに開催されたpixivさん主催のRubyMusicMixin on Rails 2024でDJもやらせてもらいました。

いやー、今回は完全に公転周期、ともすれば、(中略)アイドル、群青イニシエーションの3曲を流すためだけのつもりで応募したらトリのご指名を受けてしまいどうしようかと思ったんですが、最終的には開き直りました。

聴いてね。 open.spotify.com open.spotify.com open.spotify.com

母上にPCを献上した

母上のPCをいつリプレイスするべきか - このIP網の片隅で の続き。

Win10のセキュリティパッチ配信の終了時期が来年10月に近づいて来たので、一念発起して母上に新しいPCを献上した。

ThinkCentre neo 50q Tiny Gen 4のi5 13420Hモデル。 めちゃくちゃ小さい。

kakaku.com

これにバッファローの外付けSSDであるSSD-PUT1.0U3-BKAサンワサプライの指紋認証リーダーである400-FPRD1を付けて献上。

内蔵の256GBのSSDだけだとさすがにすぐ不足しかねないので…デスクトップやマイドキュメントなどを外付けSSDにしておけば再び他のPCに移動するときがきても苦労しないはず。 そんなに頻繁に書き込みしないだろうし。

指紋認証は母上のパスワードがあまりにも脆弱すぎたので我慢できなくなって付けました。 さすがにchromeのパスワードマネージャ使いましょうと。

3Dゲームを全くやらないのでGPUが不要とはいえ、僕のデスクトップのi9 9900Kとほぼ同等のCPU性能がこの小さな筐体に入っているとは…技術の進歩だなぁ

僕の9900Kもパワーユーザとしてはいいかげんリプレイスしどきなだけか。

アイマスハッカソン2024で機材・配信スタッフをした

先日、10/12に東銀座のTOKIUMさんのオフィスをお借りしてアイマスハッカソン2024という非公式イベントを開催し、その機材・配信担当をしました。

imas.connpass.com

www.youtube.com

スピーカーとプロジェクターとHDMIケーブル以外は全部持っていきました。

配線図はこんな感じ。

  • 発表者によってマイクを持ったり持たなかったり声量が全く違ったりで音量差を吸収しきれなかった
  • 会場スピーカーのAUXがミニジャックだったので短いケーブルしか使えずマイクとスピーカーの距離を離せなくてハウリングしてしまった
  • マイクが1本しか用意できなかったので会場質問の質問者の声が入れられなかった
  • せめて会場カメラとして使ってたWebカメラのマイクで拾えばよかった

とか色々大きな反省はありますが! とりあえず最低限、止まることはなくてよかった。

自分の発表したLT、配信中の該当部分は下記。

docs.google.com

www.youtube.com

こういうとき、自分でワイヤレスマイク2本持ってればよかったのになぁ、とか機材オタクの血が騒いで色々新しい機材欲しくなってしまうので危険。

当日流していたBGMのプレイリストとLTの資料作りだけで時間が終わってしまったので本来やろうと思っていたことは何もできませんでしたがまあそういうこともある。

ご参加いただいた皆様ありがとうございました!

上水流宇宙の18歳の誕生日を祝ってリフレクターリストバンドを個人制作・配布した #ヴイアラ #宇宙星人 #上水流宇宙誕生祭2024

はい。

先月、2024/9/12は僕の担当アイドルである上水流宇宙の18歳の誕生日でした。

これに際して、僕はリフレクタリストバンドを個人制作し、当日に新宿歌舞伎町のnamco TOKYOで開催されたパブリックビューイング会場において配布しました。

経緯・制作過程

これを思い立ったのは元々、宇宙の新衣装解説配信の中で「韓国アイドルでは、同じアイドルのファンはライブに行く際にテイストの似た服、あるいはグッズを身に着ける」といったような話があったのがきっかけでした。

そのときは「水色の光反射リストバンド」かな、と思ってamazonで適当にそれっぽい色を探して注文したんですが、それが届いたときにふと「いや、これオリジナルのデザインで製造できるのでは?」と思いついたのでした。

それからわずか1時間弱、Photoshopでラフに作った最初の案がこちら。

7/6 第1稿

左右が逆だったりしますが、ぱっと見は完成品の形がだいたい見えるようにはなっていました。 線だけなので大した手間はかかっていませんが、宇宙星人も自分で描いています。

そして翌日にもう少しブラッシュアップしたものがこちら。

7/7 第2稿

巻いたときに名前の一部が隠れてしまうのが嫌だったのと、できれば巻いたときに読める向きにしたかったので、左腕に巻く想定で右端を持って腕に着けたときにHappy Birthdayがちょうど隠れるように配置を調整しました。

自分の手首回りが17cmだったので、宇宙星人の左までが6cmになるように。

ここまで作ってから仕事が忙しくなり、今回の製造をお願いした業者さんに問い合わせしたのが8月の上旬。

8/8 第3稿

ここからデータチェックで、左下の線ならびに線と線の間の間隔が細すぎるという指摘が入り、白抜きになっていた文字を普通の文字に戻したり配置調整したりした結果が決定稿のこちら。

8/9 決定稿

あとは実はCの上側の線が短すぎるような気がして伸ばしてたり。

そして決定稿で本体色2色*1の試作品をお願いし、届いた試作品をタオルなどの公式グッズと比較して、本体色を決めました。

8/21 試作品と公式グッズの色の比較

9/4に量産品が届き、hotarubiさんに宇宙へのファンレターとともに献品を発送し、記事冒頭に貼った自称Xでの告知を経て当日を迎えました。

当日・配布

というわけで当日、宇宙誕パブリックビューイングの会場内で配布しました。

かっしーにも渡しました。

気を付けたこと

今回これを制作するにあたって気を付けたのは、公式の商売のタネを奪いすぎない、ということで。

まあ同人グッズである時点で間違いなく多少は奪っているんですが、少なくともこれがあるから公式のグッズ買わなくてもいいや、とはならないように。

というのも、今回のリストバンドは白インク単色で制作したんですが、当初はカラーにして宇宙だけでなくヴイアラとしての汎用的なリフレクターリストバンドを作るという案もあり、 戯れに876プロロゴとヴイアラロゴを使って素案を作ってみたらあまりにカッコよくなりすぎてしまって、これは公式すぎるな…となったのでボツにしたのでした。

逆に言えばですね、公式でヴイアラのカッコいい、3Mの良い反射材使ったキラキラのリフレクターリストバンド作って売ってください。欲しいです。お待ちしてます。

費用面とか配布実績とか

具体的な金銭の話もあってなかなかなので畳みます。 読みたい人だけ下記をクリックないしタップして開いてください。

今回発注したのはホットモバイリーという業者さんでした。 検索して何社か比較したところ、他社は最低ロットがいずれも300以上で、100からなのはここだけだったためです。

当日の配布数を100と見積もり、献品・ファンレター分を足して110本発注しました。 100~300未満は単価576円なので、総額としては576*110=63,330円でした。

そこに献品を送るときの郵便料金やイラレなどがいくらか。

制作した110本のうち、5本を献品して、7本が手元に残っているので当日現地配布の実績が98本ということで、ほぼ完ぺきな見積もりだったと密かにドヤ顔しました。
全員に渡しきれたわけではないので現地はたぶん120人くらいだったんじゃないでしょうか。
ちなみに僕が使っている1本は試作品です。

まとめ

というわけで宇宙の18歳の誕生日を祝ってリフレクターリストバンドを作って配布した話でした。

当日僕のほかにも着用してきてくださったかたを何人も見かけて嬉しかったです。

費用については事後カンパを募るかどうかもちょっと考えたんですが、今回は募集しないことにしました。
左下に思いっきり「produced by fusagiko」って俺の名前単独で載せちゃったしな!

元々僕個人だけで出せる金額でやった企画だし、太っ腹ということにしておきましょう。
その分公式のグッズだったりなんだったり買ったりしてください、ということで。
来年には1stライブもありますからね。

*1:薄青と水色、採用したのは水色

会社ブログを書いていた13 & 14

Rubykaigi2024に参加しました & #RubyMusicMixin 2024に出演しました - このIP網の片隅で でも触れましたが、沖縄で開催されたRubyKaigi 2024に行っていました。 そのRubyMusicMixin以外の部分についての参加レポートを会社ブログで書いていました。

developers.bookwalker.jp

それと今日、小ネタとしてjemallocを適用してみた話を書きました。

developers.bookwalker.jp

この程度の手間で高速省メモリになるならやって損はないし、railsがnewしたときのデフォルトにするのもわかる、という感じ。

私的映像エンコーディング概論

少し前にTwitter(自称X)の相互フォローの更に先あたりで学級会が開催されていたらしく、「そんなことよりもエンコーディング論とかやってくれ」という話があったので。

そこで、本記事では自分の認識の整理も兼ねて、映像をエンコードするときにどの程度の設定にすればよいかについて、現状の認識を記述しようと思う。

先に結論

フルHDH.264ならx264のpreset veryslowで8Mbpsの2passエンコードにしとけば、まあ十分でしょう

エンコード形式の"画質"って何だ

日常会話において、映像のエンコードについて言及するときによく曖昧なままにされがちなのが、「〇〇形式は画質が良い/悪い」という言葉である。

これについてもう少し詳しく考えると、映像をエンコードするにあたって、「最も画質が良い」とは、「エンコード元の映像データと比較して何も値が変わっていない、言い換えれば差がない状態」*1である。
エンコード結果はその原理目的から考えれば"画質"は最良でも同じ、それ以外は悪くなる方向にしかならないので、前述の"差"のことを損失と呼ぶことが多い。

反対に、「最も画質が悪い」について考えると、実はこれは結構難しいのだが、映像のエンコードというのは人間が目で見て初めて役立つものなので、この記事では「人間がエンコード後のデータを再生したときに、エンコード元の映像データに映っているものを何も判別できない状態」という説明とする。

これで、最も良い状態と最も悪い状態の二つの説明が定義できたので、本記事における「画質」の評価軸はその2点を結んだ中間、「人間がエンコード後のデータを再生したときに、エンコード元の映像データと比べてどれだけ損失が少ないと感じるか」であると考えることができる。

損失の少なさを評価する試み

直前にも述べたが、映像のエンコード形式の最終的な受益者は人間である。つまり人間が良いと感じれば良いのである。

…という話で終わってしまっては各エンコード形式の画質の良さを比較することはできない。

そこでどうするのかというと、人間をそこそこの数連れてきて、映像を見せるのである。 そして画質はどれくらい良く感じましたか?と点数を付けさせる。

これのことを、人間の主観に基づく評価なので主観評価と呼ぶ。

ただし、主観評価では人間が評価するということは当然、評価する人や時期によって評価基準にブレが生じる。なんなら見せた順番によっても結果が影響を受ける。すなわち、異なる時期に行われた試験の評点を比較することはできないという弱点がある。
ブレを小さくするための様々な見せかた*2が検討、提案されているが、主観評価なので、ブレを0にするのは原理的に不可能であると言ってよい。

この弱点に対し、エンコードの前後の映像をもとに、画質の良さを数式から計算できる評点にしようと言う試みもある。
これを客観評価と呼び、よく言及されるのはPSNRまたはSSIM*3である。
しかし、それらの指標は、主観評価と緩やかな相関を示すとされるものの、主観評価を完全に代替できるほどの強い相関ではないと評価されている。

これら主観評価、客観評価といった学術的、あるいは標準化団体的なアプローチに対して、実産業からアプローチするものとして、Netflixのvmafがある。
これは、エンコード前後の画の数値的な差と、人間が感じる画質の主観評価値という具体的な関係式が明らかでない2値の間を機械学習によって近似しようとする試みである。

その評点が主観評価とどの程度の相関があるか、それが客観評価よりも強い相関なのかについての評価は定まっていないが、少なくとも同じ機械学習モデルを用いる限りは決定的*4なはずなので、異なる時期に行った評価の評点でも比較可能と考えられる。

国内でのvmafの実用例としては、DMMがvmafも含めた画質評価によってAV1のパラメータをチューニングし、従来使用していたH.264と同等評点の画質でビットレートを削減した、と主張する事例を観測している。

最も画質が良いエンコード形式、それは

さて、「エンコード元の映像データと比較して何も値が変わっていない状態」は実は簡単に実現できる。
頓智のような答えになるが、エンコードしなければよいのだ。つまり無圧縮である。
圧縮しなければ、圧縮による画質の損失もない。

……しかし、それではあまりにもデータ量が大きくなりすぎる。
具体的に計算すると、いわゆる1080p60の映像データの場合、縦1080px、横1920px、1画素あたりRGBで3Byte、秒間60フレームであるので1秒あたり約373.25MB必要になる。3秒で1GB強だ。

これではいくら画質が良いと言っても現実的に扱えるデータ量ではない。

ということで、映像のエンコードという課題を解決するにあたっては暗黙に、「データ量が現実的に扱える範囲に収まること」という制約の存在がこれによりわかる。

「現実的に扱えるデータ量」とは何か

そして実は、「現実的に扱えるデータ量」、というのも少し定義が難しい。

現在広く用いられているH.264や、その次世代であるH.265、AV1といった映像エンコード形式はその系譜をたどるとH.261にたどり着くが、これはISDN回線を用いてビデオ会議を行うために策定されたものであった。
したがって、その「データ量」というのは人間がどれくらいまでの遅延ならばどの程度違和感なく会話できて、その遅延に収めるためにはアルゴリズムがどの程度の計算量であるから当時または将来のCPUの計算力を鑑みてエンコードとデコードでどの程度の時間がかかり、残った分がデータ転送に使える時間で、複雑な動きをするときにはより多くのデータ量を割いて画質を良くしたいので、そのデータ量の変動を吸収して映像を途切れることなく伝送するためにどの程度のバッファ量が必要、あるいは遅延の観点から許容されて…
といったようなモデル化がされているわけだ……が!

この記事ではインターネット回線を介さない記憶装置に格納されているデータを読みだして再生し、計算力もGPUないしCPUの再生支援なども活用するためデコードに係る計算量は心配いらない環境を対象と定めるので、そのレベルの話はしないこととする。

したがって、本記事における「現実的に扱えるデータ量」というのは「記憶装置に十分な時間の映像が記録できる程度のビットレート」ということになる。

例えば3時間の映像を記録した片面2層のBlu-ray Disc*5。 これは180分、10800秒の映像を50GB=50000MB=400,000Mbitに記録していることになるので、平均すると約37.04Mbpsのビットレートということになる。 これをH.264 high profileで記録しているので、H.264としてはかなりの高ビットレートだ。 しかし、BDはDVDの後継、すなわち映画を1枚のディスクに可能な限り高画質で収めるための規格なので、ディスクに収まり、人の手で交換できさえすれば「現実的に扱える」という条件を満たすと言える。

それでまあ、現代は1000GBのUSB3.2 Gen1接続のSSDが1万円前後で買えるわけだが、 冒頭に結論が書いてあるにも関わらずこの記事をわざわざこんなところまで読むような物好きな読者の皆さんは、 おそらくBDと同じビットレートを使って1000GBで60時間記録できます、ではいくら高画質とはいっても足りないのではないだろうか。

裏を返すと、これは1,000GB=1,000,000MB=8,000,000Mbitで何秒の動画を記録できれば十分ですか、という質問に変換できる。

といっても記録できればできるほど良いのは間違いなくキリがないので、一つの目安を示すとYouTubeH.264 1080p60fpsはだいたい4.5~5Mbps程度である。

ならばということで、僕個人としては目標平均ビットレートとして8Mbpsを使うことにしている。
それならば1TBあたり1,000,000秒、約277.78時間記録できるはずだし、ユーザのインターネット回線速度の都合もあってビットレートを高くしづらいYouTubeよりはさすがに良い画質を実現できるはずだからだ。

平均ビットレートが同じときにより良い画質を実現するには

というわけで目標平均ビットレートが決まったら、次はその範囲でいかに高画質を実現するかになる。

H.264が頑張っている動画圧縮の要素技術をざっくり用語だけ並べると、

  • 色空間をRGBからYUVに変換
  • 4:2:0にダウンサンプリング
  • マクロブロックに分割して各マクロブロックの動きベクトルを推定
  • 推定した各マクロブロックの動きベクトルから動き補償予測で生成した予測画像と実画像の差分を取る
  • 取った差分を離散コサイン変換で周波数成分に変換
  • 隣接するマクロブロックの対応する周波数成分の差分を取る
  • 高周波部分を捨てたり揃えたりして値の出現確率を更に偏らせる
  • 最後に算術符号*6エントロピー圧縮する

…という手順をざっくり踏んでいるわけだが、これらは非常に単純化して言うと要するに、「同じフレーム内で近い画素同士は似た色をしていることが多い。また、時間軸的に近いフレーム同士では似た領域がある*7ことが多い」という映像の性質を利用している。
この性質を利用して、「いま圧縮しようとしているフレームの各領域に最も似た、時間的に近い別のフレームの領域はどこか」を探して、あとはそれからの差分を計算するとよりデータサイズを小さくできる、ということである。

似た領域の探索を頑張れば頑張るほど、もっと似た領域を探し出せるので、同じ画質ならデータサイズを小さくできるし、同じデータサイズならより高画質にできる。 逆に言えば探し方を雑にすると、画質は悪くなるがエンコードにかかる時間を短くできる。

というわけで、同じソフトウェアエンコーダーを使う場合は、エンコードに長い時間を費やせば同じデータサイズでより高画質を実現できると考えてよい。ただしそれにも限度があり、使う時間を増やせば増やすほど、増やした時間に対しての画質向上の効果は減っていく。要するにコストパフォーマンスが悪くなっていき、度が過ぎると使った時間の割に絵がどう変わったのか人間には区別できなくなる。そうなったらもう、人間が受益者である以上それ以上の時間をかける意味はない。

ハードウェアエンコーダとソフトウェアエンコーダを比較する場合は、エンコードにかかる時間に制限を設けない同一ビットレートにおいてハードウェアエンコーダが実現できる画質はソフトウェアエンコーダのそれよりも絶対に悪くなると言ってほぼ間違いない。
なぜならばハードウェアエンコーダは圧縮処理の全てまたは一部をハードウェアとして実装して速度を稼ぐ代わりに、ソフトウェアエンコーダがやっているような隅々までの似た領域の探索はできないからだ。

ということで、画質を重要視するならばソフトウェアエンコーダ一択というのは現在も変わらない。

1passエンコードと2passエンコードも当然、2passエンコードのほうが良い画質を実現できる。
なぜならば2passエンコードは1pass目で映像の傾向を分析することで、2pass目で実際にエンコードする際により適切なビットレートの割り振りを行えるからだ。

と、ここまで書いたところでそろそろお分かりかもしれないが、映像のエンコードという課題を解決するにあたっての暗黙の制約2つ目として、「エンコードにどれだけの時間を費やせるか、待てるか」の存在がこれにより判明した。

そしてこれについて僕は、x264を使ってエンコードするならもうpreset veryslowの2passエンコードを使ってしまって良いと思っている。
僕の使っているデスクトップPCのCPUであるCore i9-9900K*8では、それでフルHDの映像を実時間の2~3倍程度の時間でエンコードできるからだ。

つまり、3時間の映像をエンコードするのに最大で9時間程度かかるということだが、それくらいならば寝ている間や仕事をしている間に動かしておけば終わる。

なんせH.264なんて今も現役のような顔をしているが、勧告されたのは2003年。21年前である*9
そんなのもう、重いプリセットを今のCPU計算力でごり押してしまえばいい。

画質の評価手法の節で出てきたVMAFを使ってプリセットを比較した下記記事でも、presetを重くすればそれだけVMAFの評点が向上していることがわかる*10

ただし、placeboプリセットは今でも激重だし、2つめの記事に書いてある通りvery slowに比べてむしろ画質が下がるという説もあるので使わないほうがよいだろう。

将来的なエンコード形式の話

今回はH.264に的を絞って述べたが、基本的にはH.265やAV1でも同じことが言えると思う。

  • 画質の良さとファイルサイズの小ささを取るならエンコードに時間をかける必要がある
  • エンコード時間の短さとファイルサイズの小ささを取るなら画質は妥協せねばならない
  • 画質の良さとエンコード時間の短さを取るならファイルサイズは大きくせざるを得ない

H.265やAV1、更にはその次の世代として勧告されたH.266は、理論上はそれぞれの前世代に比べ同等画質で30~50%程度少ないビットレートを実現するとしているが、実際にはその分エンコードの処理内容が非常に複雑化していて、非常に時間がかかるというのが実情である。 それを将来のCPU性能向上、GPUによる再生支援、ハードウェアデコーダ・エンコーダの実装に期待して策定、勧告していると考えてよいと思う。

YouTubeやDMMといった同じ映像データを大量のユーザにむけて配信する事業者はそれだけの計算量をかけてでもビットレートを低く抑えたほうが大きなメリットがあるのは理解できるが、いくら僕がかなりのパワーユーザ寄りとはいえ、個人でエンコードして個人で再生するような映像のエンコード形式をH.265やAV1、ましてH.266にする日が来るのかどうか……というと今はまだ想像できない。

まとめ

というわけで、結論としては冒頭にも書いた通り、フルHDH.264ならx264のpreset veryslowで8Mbpsの2passエンコードにしとけば、まあ十分でしょう。

実は5年前にもこういった画質vsエンコーディングネタの記事を書いたことがあるのですが、そのときは「ニコ動のアップロード容量制限である3GBギリギリになるようなビットレートでハードウェアエンコードしてしまえ」という結論でした。
というのも、その記事では自分で動画を制作することを想定していたので、間違えた場所を見つけてもすぐに修正できるように、エンコードにかけた時間が無駄になってやる気を失ってしまわないように、しかもどうせ数十Mbpsになるので結果に大した差は出ない、という意図込みでその結論にしています。
一方、今回はソース映像は完全に固定で存在し、また目標ビットレートを8Mbpsといった普通な値に定めた場合の話をしているため、ソフトウェアエンコードで時間をかけて*11CPUパワーでごり押しせよ、という結論なのでした。

更に余談ですがHDMIキャプチャなどからの映像を撮るときにはRTX 3060Tiに乗っているNVEncのH.264ロスレスプリセットを使ってSSDに記録しています。 こうすると映像の傾向にも寄りますが250~300Mbps、ファイルサイズにして2分半を5GB程度で色空間がYUV420に変換された以外は可逆な映像が撮れるので、それをx264のvery slowプリセットを使ってゆっくり画質良くエンコードするのが良いです。

*1:現実世界の光景を撮影して映像データ化するときに、レンズの収差やセンサーのノイズ、センサーとヒトの目のダイナミックレンジの差などによって現実世界の光景とは異なる画になる、という観点での画質はこの記事の対象範囲の外であることに注意

*2:NTT 技術解説 – 映像品質評価法電子情報通信学会知識ベース2群5編9章3節

*3:電子情報通信学会知識ベース2群5編9章2節

*4:入力が同じなら同じ出力になること 決定的アルゴリズム - Wikipedia

*5:以降BDと表記

*6:プロファイルによってはハフマン符号の場合もあったはず

*7:物が動いているように見えるということは、考え方を変えるとあるフレームに映っている物体は次のフレームでは少しだけ場所が変化しているということ

*8:あくまでベンチマークスコアベースになるが、Core i5-11600Kや Core i5-13420Hでも同等のCPU性能らしい

*9:なんならmain profileまでとはいえ、2004年発売のPSPが策定中のH.264に基づいて再生に対応している

*10:本当は自分でやったほうがいいのはわかっているんだけど面倒くさかった

*11:といってもたかが実時間3倍