Chienomi

データ増大と大量のデータの維持

Live With Linux::hpc

序

本記事は現状で数十〜数百テラバイト規模のデータを維持している私が、データの維持と構成について考察するものである。

まずは簡単に前提となる「現状の」構成を説明しよう。

「マスター系」と呼んでいるのが、データを集約するストレージである。 8ディスクNASを2台用いて、3TBx8台のRAID5でiSCSIで提供する。 総容量は3 * 16で48TB、実容量は3 * ((8 - 1) * 2) * 0.9となり、37.8TBとなる。 (ReadyNASの仕様としてiSCSIで提供できるのは全容量の90%までとなっている)

「スレーブ系」と呼んでいるのがマスター系の複製ストレージである。 こちらはsingleで、3TBが2台、4TBが6台の30TBとなる。 マスター系の複製であるため、マスター系の残容量に関係なく、この30TBがデータを格納できる上限となる。

「サブ系」は解析用のデータを格納しているもので、4TB4台で2レッグミラーとなっており、総容量16TB、実容量8TBとなる。

「デグレード系」はマスター系のディスク故障によりデータを保存することができないために用意されたもので、6TBのディスクが2台のミラーである。

その他を含めると実容量では次のようになる。

  • Master 37.8TB / Slave 30.0TB
  • Sub 8TB
  • Degrade 6TB
  • Main Cache 1.92TB
  • Portable 2TB
  • Portable2 1TB
  • Processing Cache 480GB

さらに各マシンが保有している(本来Masterに乗せるべき)データは、最大で5TBである。 理論上、すべてのディスクが限界の状態であると仮定すると、Master/Slaveストレージは54.5TBがあれば全データを格納できる。 これは、8TBを8台のRAID5で構成したときに少し足りないが、実際にはすべてに限界までデータが載っているわけではないので格納可能だ。

大量のデータによって発生する問題

クラウドの利用不能

数十TBのデータをクラウドで保管するのは現実的ではないコストがかかる。

それだけでなく、その規模のデータだとデータアクセスそのものに凄まじい時間がかかるようになり、生きているうちに終わらないような状況になる。

オフラインで維持する必要があるということは、それだけのストレージ設備を自ら維持しなくてはいけないということだ。

コスト

仮に1万円のディスクを8台とすると8万円で、これにバックアップを含めると16万円になる。 この時点ですごい値段だが、ポイントは「2倍のコストがかかっている」だ。

しかし、このコストのかかり方は飛躍的に増える。

まず、1万円のディスクが1台だとする。 金額単位だと面倒なので、これを1とすると、バックアップを含めて2で良い。

次に1台で足りないから2台であるとする。バックアップでもミラーでも4である。 RAID5で3という選択肢もある。

これが4台になると、冗長性が必要になってくる。すると5でRAID5にして、バックアップは冗長性がなくて良いとすると9となる。 だが、5台のディスクを構成できるコンピュータは限られてくるため、2台目を用意するか、あるいはそれ用に割高なサーバーを用意することになる。 2台目を用意したとき、2台をまたいでRAID5を構成するのはあまり現実的な手段ではない。となると6台で3, 3に分けてそれぞれにRAID5を組み合計で4を構成する、という感じになる。

データ増加よりもディスクの大容量化が早ければよいのだが、そうでない場合はこのように様々な限界に到達し、コストがどんどんふくらんでいく。そして、増えた台数に大して増えた容量が少なくなるため、データの増大に従ってコストの増加量が増えていくのである。

HDDの故障

8台NASを使っていると分かると思うのだが、HDDが8台も稼働しているとかなりの頻度で故障する。 年に1〜2台は壊れるし、たとえNAS用やサーバー用のディスクを使っていたとしても、この問題は運に左右される。

データ損失の可能性についてだが、8台に達するとRAIDは6でも不十分である。 復旧時の負荷で壊れることがあるからだ。

安全を考えると、「故障してもデータを読み出すことができる」という冗長性を確保しつつ、バックアップを取るのが望ましい。 数の上では冗長性は高まっていないが、稼働率と利用量が異なることから、バックアップ系統とRAIDの同時故障はなかなかない。

しかしこれは、せいぜい16台で運用しているから言える話で、もっと台数が増えるとさらなるバックアップが必要になったりする。 そして、台数が増えるごとに冗長性を確保するために必要な台数はさらに増え、結果的に故障率が上がるためトータルの冗長性・可用性は大して向上しないまま故障頻度は増えるという悪循環を抱えることになる。

可能ならば少ない台数で運用するほうがずっと安定するのだ。

バックアップと復元の困難さ

だいたい15TBのデータがあるとして、これをフルバックアップしようとすると2日(48時間)はかかる。 実際にやってみると分かるが、48時間ダウンせず、エラーにもならずに安定して転送・書き込みを行う、というのは結構難しい。

50TBとなると約1週間かかる計算だ。

じゃあ故障したディスク1台だけ入れ替えたらどうか…と思うかもしれないが、RAID5のパリティの再計算で8TBもあると途方もない時間がかかる。だいたいの場合、まっさらにして転送したほうが早い。 ちなみに、Btrfsだとリバランスにかかる時間は凄まじいのでやめたほうがいい。しかも、リバランス時に書き込みをミスって壊れることが結構あるので、Btrfsのリバランスは危険行為だ。

故障頻度は高いのに交換は困難、というのはものすごく面倒だ。憂鬱になる。

手元のデータ

2013年から2017年にかけて、ユーザーデータ増加量は年間約2TB程度であった。 このユーザーデータは、データ解析のために自動収集されるデータを除外し、人間のアクティビティによって発生するデータである。 つまり、この間に約10TBのデータが発生した。

2017年にMasterが故障したため、ここからデータの増加をできるだけ抑えるようになった。 また、アクティビティ自体の変化によってユーザーデータの生成量が減った。 2017年から2019年にかけて、データ増加量は年間500GB程度であった。

2019年にDegrade系を追加したことで、2019年のデータ増加量は1TB程度となった。2020年はもう少し多いが、2021年は大幅に多い。2021年に大幅に多いのは、ゲームをするようになってゲームキャプチャのデータが増えたためである。

データ増加には耐えられない

データ増大の問題

「年間約2TB」と言ったが、この間データ生成元は基本的に更新していなかった。 だが、現在のデータはそうではない。

まず、動画だが当時はFHD, 30FPSであった。 現在は4k, 60FPSになっているため、データ量としては8倍になっている。 しかも、映像自体が精緻になった関係で実際のデータ量はさらに多い。

また、写真に関しても約12Mpxから48Mpxと4倍になっている。 しかも10ビットになっている関係でデータ量はさらに大きい。 もっとも、この問題に関してはNikonの一眼が非常に大きいデータを吐くため以前から存在はしていた。あまり使わなかったのでそこまで大きな問題でもなかったが。

他にもいろいろあるが、トータルで生成されるデータ容量は10倍くらいにはなっている。 そうなると、「年間20TB」とかいう話になるし、このインフレは今後も続くのである。

そこで現実的な対応として、データそのものを小さくする、ということを考えなくてはならない。 これはごく普通の話で、テレビ放送でもデータ量の増加に対応してそれをいかに圧縮するかありきで考えなくてはいけないし、ウェブでも圧縮がないと成立しない部分もある。

動画

圧縮の最有力候補は動画である。 データ自体が大きいのもあるが、視覚上、時間さえかければ割と小さくできるからだ。

特に、デスクトップキャプチャ、つまりCGを含むコンピュータ上で生成された連続的な画像に大しては、libvpxによるVP9圧縮がかなり有効であり、大幅にサイズを削減することができる。 libx265を選択しないのは、こうしたデータに対してlibx265で強く圧縮すると特に文字周辺にゴーストが出やすいからだ。

具体的には、Radeon Reliveによって録画されたFHDのゲームプレイは、およそ30000kb/s程度であるが、libvpxによるVP)であれば4000kb/s程度まで圧縮しても劣化を感じないレベルである。 ここまで極端な圧縮が可能であるという点は非常に評価でき、ゲームプレイ、アニメーション、そしてデスクトップキャプチャはlibvpxによる圧縮によってサイズを大きく減らすことができる。

だが、これはかなりの問題がある。 Ryzen7 3700Xにおいて、libvpxによるVP9圧縮は2FPS程度であり、60FPSソースであれば1/30に過ぎない。 Ryzen9 5950Xであればもう少し速いが、それでも5FPS安定して出すのは難しい。

このことから、圧縮を実現するために非常にパワフルなコンピュータを、非常に長い計算時間回す必要があり、かなり大変なのだ。

だが、以前は(A10 7870Kを使っていたときは)このような動画圧縮は動画が生成されるペースよりもずっと遅いために「計算時間を省くために容量を用意する」という選択をしたが、現在においては容量を用意することは困難なサイズであり、計算力を確保するほうが現実的だ。

カメラで撮影した動画においては、libx265によって圧縮するほうが良い。 この場合、VP9のデスクトップと比べるとかなりサイズは大きくなり、ソースに対する圧縮率もそこまでは高くない。だが、1/2〜1/4程度にはなるため、ディスクの要求数を大幅に下げることができる。

問題は、ソースによって適切なセッティングが大きく異なる可能性が高いことだ。 特に夜間の撮影に関しては、かなり高いビットレートを確保しないと明らかにデータを失ってしまう。 安全なセッティングでバッチを回すとなると、そこまで大きな削減にはつながりにくい。

より効果的な削減を考えるならば、AV1、もしくはVVCを考えたいところではあるが、現状のlibaomはRyzen9マシンを用いても動画データの生成より速く処理することはできない。 また、VVCに関してはオープンな実装(x266)がまだだ。

VP8とVP9の比で、必ずしもVP9がひどく重いわけではない(重いが、VP8がそもそも重かった)のに対して、AV1(libaom)は比較にならないほど重く、プロセッサの進歩によってなんとかなるレベルではない。 ハードウェアAV1エンコーダがあれば解決する可能性はあるが、それはストリーミングレベルの圧縮(つまり、30000kb/sといったレベル)においてVP9を使うよりは品質が良い、というような話であり、アーカイブするためであればlibvpxで時間をかけるよりも良いということはないだろう。

こうした方針によって、10倍に増加したデータを2〜4倍程度に抑えられれば、データが爆発することを抑制できる。 重要なのは、この抑制によってストレージの容量増加を間に合わせることだ。

音声

音声データに関しても、Opus(libopusenc)によって品質を維持したまま圧縮が望める。 しかし、相対的に音声データは小さいので、この圧縮はあまり意味がないかもれしない。 また、個人的には音楽に対しては完全なデータで残したいので、FLACのままだ。

こうした特別なこだわりがない場合、Opusは現状、十分に現実的な圧縮を提供してくれる。 スピーチの場合64kbps/Channel, 音楽の場合128kbps/Channel程度で極端にシビアではない聴取において十分なクオリティを保つことができる。

静止画

画像は基本的にJPEGだろう。 このデータは、JPEG自体の最適化と、AVIFもしくはHEIFを用いた変換が考えられる。

画像データは決して小さくないため、効果は大きいが、アーカイブとしては十分ではない。 というのも、画像は劣化を感じることがあるのと、アーカイブするような画像は拡大して見ることがあるため、劣化を検出する機会が存在するためだ。 動画を静止して一部分を拡大するようなことは稀だろうが、それと比べると画像の劣化はシビアだ。

具体的な仮定のために参考データを出そう。 私が撮影した次のような風景写真がある。

IMG20211113170133.jpg JPEG 3000x4000 3000x4000+0+0 8-bit sRGB 3.81174MiB 0.000u 0:00.000

heif-encとavifencをデフォルトで用いてエンコードするとこんな感じになる。

592K IMG20211113170133.avif  1.6M IMG20211113170133.heic  3.9M IMG20211113170133.jpg

AVIFの圧縮が非常に光る。また、普通に見る分には視覚的な劣化も感じることはない。 これなら、記念するようなものでなければアリにも思える。動画と比べれば負担も小さい。

だが、別の問題もある。手元で試したところ、ViewniorではJPEGの表示に0.21秒、AVIFの表示に1.56秒、HEIFの表示に2.56秒かかった。一方、PixはJPGで1.76秒、AVIFで2.04秒と違いは小さい。(HEIFは非対応)

画像は検索性が悪いため、素早く表示することが非常に重要になる。Pixの場合サイズが小さくなったことにより、NASに置く場合むしろ良い結果をもたらすかもしれないが、Viewniorでは明らかに遅く、実用的ではない(特にHEIFは、非常に遅く、AVIFよりかなりサイズが大きいことからあまり良いところがない)。

だが、問題をごっちゃにしないほうが良い。

  • アーカイブは、できるだけ小さいサイズながら、劣化を知覚できないレベルに抑えたい
  • 検索性は、一覧しやすく、サイズが小さく素早く処理できるほうが良い
  • 交換性に関しては、アーカイブクオリティで交換することはまずないので、再度JPEGに変換するなどすれば十分である

だから次のような処理をすれば良いということになりそうだ。

ALBUM=${PWD:t}
for i in *.jpg
do
  avifenc "$i" "${i:r}.avif"
done
mkdir -v "../../photo-thumb/$ALBUM"
mv *.jpg "../../photo-thumb/$ALBUM/"
cd "../../photo-thumb/$ALBUM/"
mogrify -resize 360x360 *.jpg
jpegoptim *.jpg

AVIFのサイズが十分に小さいこと、サムネイルのサイズが小さい上にjpegoptimにかけると非常に小さくなることからこれでもサイズの削減にはなる。 具体的には、例の写真ではオリジナルサイズが3,996,901バイトであるのに対し、AVIF+サムネイルJPEGのサイズは642,593バイト。容量は約16%に削減されている(=約84%削減された)。

これで、素早く表示でき、検索に向いたサムネイルから目的の画像を見つけ、じっくりみたいならAVIFの画像を開く、ということが可能だ。

一方、PNGをロスレスで圧縮する価値はあまりない。 FHD2枚分のデスクトップキャプチャPNGが207,000バイト、AVIFロスレスでは1,890,790バイトとかなり大きくなってしまっている。HEIFロスレスはもう少し小さいが、もとのPNGよりは大きい。 なお、pngquantで圧縮したところ79,615バイトと小さくなったのでこれはまだ選択肢に入るかもしれない(quality=40-65)。 だが、そもそもデスクトップキャプチャがそんなに巨大なものではないので、よほど量がない限り不要な処理だろう。

その他

それ以外のデータは、ほとんどが必要となる計算量や、実用性の低下を受け入れられるほどの効果はない。

例えばxzによる圧縮は非常に大きな圧縮効果をもたらすが、テキストファイルやコードなどを直接読めなくなるのは弊害が大きいし、その割にそもそものデータサイズが巨大化することは少ないため、割に合わない。

システムログなどを大量にストックしているのであればxz圧縮するとサイズは削減できるが、一般的にこのようなファイルは最初から圧縮されているため、これを伸長して再度圧縮する価値はあまりない。

試算する

現在、8TBのNAS用ディスクは約2万円であるため、8ベイNAS1台あたり16万円ほど。 ReadyNASでRAID5だとこれで50.4TBになる。これは3TBによるNAS2台分(37.8TB)よりも大きく、現在のデータを十分に格納可能だ。

仮にMaster系を1台に削減するとして、Slave系は必要になる。 現在の中でSlaveに回せるディスクの合計は34TBであり、8TBを2台追加すれば足りそうだが、従来のSlave系ディスクはそろそろ寿命な時期なので、結局同じ量を必要とするだろう。

すると、倍で32万円である。 この台数になると突然死するディスクが出ることがあるため、スペアディスクが1〜2台必要だ。Slaveは容量的には7台で足りるため、仮にスペア含めて16台、32万円であるとしよう。

故障率からいうと年に2〜4万円程度の追加出費が発生する。保証によって交換される場合もあるため発生しつづけるというわけでもないが、必要なスペアの数が増えたりするためある程度は増加する。

「継続的にある程度のコストが発生しつつ、更新や修復にはまとまった金額が必要になる」ということで負担が大きいのがおわかりいただけるだろうか。

ファイルシステム

NAS1台に収まる場合はなんでも良いが、NAS2台になるとLVMではストライピングでしか分散できないため、現実的にはBtrfs一択である。

Btrfsはディスクの容量が異なる場合でも最大限容量を活用してくれる。

NAS1台の場合でも、Btrfsによるsend snapshotは非常に効率的なバックアップを可能にするため、データ容量が多い場合のストレージはBtrfsを選択するのが無難である。条件にもよるが、耐障害性も高い。

なお、ディスク故障に対する冗長性はBtrfsで確保するよりも、RAID層で確保するほうが良い。 BtrfsのRAIDは障害からの復旧がかなり遅く、RAID5/6に関しては復旧自体が怪しい。 Btrfs自体を冗長化することでファイルシステムの部分的破損を含むダメージでもファイルを読み出せる、という利点があるのだが、Degradedなら即座にデータをバックアップした上で再構築するという運用であれば、素直なRAIDのほうが優れている。

この場合、RAIDはBtrfsの関知するところではなく、Btrfsが利用するブロックデバイスが冗長化されたものであるようにするということである。NAS2台を使う場合、meta mirrorが良いだろう。

Linuxシステム(ReadyNASを含む)であればMDで、マザーボードに備わっているFakeRAIDを使うのも悪くない。

データの保持・維持について考える

基本的な考え方は、できればディスク1台、難しくてもディスク2台で済むようにデータそのものを抑制することである。 4台までなら極端に難しいわけではないが、それを越えると飛躍的に難しくなる。

普通に使っていて越えそうなのであれば、データに対する戦略性が必要だ。 例えば計算時間を割り当てて空間を削減するのもそうだし、そのために計算力を確保するという点でもそうである。 また、そもそも不要なデータを無闇に保持しないということも大事で、取得時に選別するか、あるいは取得後に選別しやすいようにするかを予め考えておく必要がある。

現在のディスク容量との兼ね合いとしては、一般にユーザーアクティビティによって生じるデータ(例えばカメラによる写真や動画)は、変換による質的損失は発生するにしても、保持すること自体によってストレージが不足するようなものではない。 現在、最も手頃な6TBディスクが1TBあたり1750円程度だが、実は6TBでも2500円程度のNAS〜ストレージサーバー向けの東芝MNは16TBでも2500円程度とほぼ変わらない。現状、価格のブレも合わせると極端に安い製品を除外すればだいたい2300〜2500円あたりがHDDの価格であり、16TBまでは(純粋な値段は置いておいて)割と安定した価格であると見ることができる(18TBはさすがに高い)。 16TBを1台でも、8TBを2台でも、16TBが現在の目安となるが、16TBを使い切れるほどのデータを生成する人はそう多くはないだろう。

では何がデータを増大させるのかというと、まずマルチメディアデータを無劣化、あるいはそれに近い状態で保持しようとすることだ。 ある程度の品質までは効率的に削減できるのだが、ある程度以上になると知覚困難なわずかな差のために非常に大きなデータを必要とするようになっていく。 この点において適正な評価を行い、データを削減することは不可欠である。

もうひとつは、外部から与えられるデータだ。 特に、TVを録画したものや、ダウンロードした動画は容量が大きくなりやすく、非常に速く増大する。 実際、私の手元のDegradeストレージは、配信頻度の高い特定の配信者の動画が大きな容量を占めている。

こうした収集は簡単にデータにアンコントローラブルな増大をもたらすので、きちんと方針を立ててコントロールすることを心がけることが必要だ。

なお、単純にインターネットからのデータ収集可能量自体は、5年前と比べると著しく減っている。 ひとつは、オープンなインターネット交流自体が大幅に減ったということもあるが、それよりも大きいのがウェブにおいてデータの取得を許さない傾向があることだろう。

わかりやすいのがTwitterで、Twitterは以前は比較的オープンなウェブであったが、現在はログインなしには情報を見せないものになっている。 メディアタイムラインも以前はログインなしで見ることができたが、現在ログインなしのメディアタイムラインは有効なものではなく、そこから画像を取得することはできない。 また、そもそもTwitterは非常にメジャーなブラウザでのみ動作を許可するスタンスであり、マイナーブラウザでの閲覧を許容しない。実際、私はNetSurfというブラウザを使ってTwitterを使っていたら凍結されたことがある。 さらに、公式のウェブクライアントを用いた場合でも通信量に結構厳しい制限があり、Puppeteerなどでデータを取得するのも現実的ではない。

※ データソースのURLが既知であれば取得することは可能であるため、PuppeteerでURLを収集し、別のツールでダウンロードするようなことは可能である。ただし、そもそもスムーズにタイムラインをたどることができればの話だが…

YouTubeも、最近はサードパーティのプレイヤーアプリですら約56kb/sのスロットリングを課せられてしまうため、再生もできない。 これはシンプルな実装のウェブブラウザで、マルチメディア再生は外部プログラムに渡すことで実現しているようなもので再生することもできないという意味になる。

こうした事情があり、仮に無軌道な(無作為の)データ収集を行った場合、収集可能なデータ数は大幅に減っているだろう。 それは、データ単体のデータ容量が増加することにより、データ容量が減っているとは限らないという問題はあるが、現実的にどうしようもないほどのデータが集まってくることは起きにくくなった。

いずれにせよ、過剰なデータ増大がどれほどコストと手間(とストレス)がかかるものかということを認識した上で、必要とするデータが多いほどに相応の戦略性が求められる。

まとめ

  • ディスク数が増えると故障頻度が増え、維持の手間もコストも飛躍的に増大する
  • 大量のデータは取り扱いが難しく、バックアップひとつとっても非常に時間がかかる
  • 増加しつづけるアーカイブを維持するには、冗長化した上でデータを新しいストレージに更新していくことが継続的に必要で「手入れ」が不可欠
  • ディスク1台に収まらないデータの維持は簡単なことではない
  • ディスク数増の負担は大きいので、データ生産量を上回る前提でデータを圧縮してディスクの要求そのものを削減することは不可欠
  • データ削減は動画をVP9/H.265によって圧縮するのが効果的
  • デスクトップキャプチャ, ゲーム, アニメーションにはVP9のほうが良い
  • libvpxを用いたVP9エンコードにはかなりのCPUパワーが要求される (並列処理も必要となる)
  • 写真を撮る頻度が高い場合、AVIFによる圧縮と小さいサイズのJPEGのサムネイルを生成するのが効果的
  • 音声圧縮は多くの場合必要ないが、音声データの量が多いのであればlibopusによる圧縮が良い
  • その他のデータはピンポイントな要件がない限り、圧縮は必要ない
  • 冗長化されたブロックデバイスをBtrfsデバイスにするのが扱いやすい
  • 冗長化の必要性は台数によるが、バックアップは常に必要である
  • データ量が多い場合、そもそもデータをストアするためにマシンパワーが必要になる

なお並列圧縮する場合、一旦SSDに書き出してから出来上がったものをHDDに転送したほうが良い。でないと激しい断片化が発生し、I/Oパフォーマンスも低下する。

せっかくなので何か書いてみる

今回新しく写真について言及した。

効果があるかどうかはどの程度写真を撮るかによるが、前述の「アーカイブはAVIFで、サムネイルをJPEGで」という戦略に基づいて簡単なユーティリティを書いてみた。

Photoutilsは実際に私がローカルで使っている写真ストレージ環境に合わせて書かれたユーティリティだ。

photocompress.zshは同階層にphotoディレクトリとphoto-thumbディレクトリがあり、photoディレクトリは直下にアルバムが配置され、一方photo-thumbはby-album下にアルバムが配置されることをイメージしている。

これはカテゴリによってアルバムのリンクを生成する(/dev/diskのように)ことを想定したものである。

AVIFへの変換はかなり時間がかかるので、裏で気長に処理するのが良いだろう。 1フレームですらここまで時間がかかる、というのがAV1の利用困難さを表しているのだが。

phototagユーテリティはアルバム直下にある.tagsテキストファイルを取り扱う。 .tagsは1行あたり1タグの形式だ。

phototag-update.rbは.tagsをQDBM形式のデータベースに変換する。 QDBMとOjの組み合わせで非常に高速だ。 「grepでいいじゃん」の類なので微妙かとも思ったが、実際やってみるとアルバムが増えても圧倒的な高速さ(というか、一瞬すぎて知覚出来ない)なのでやはりあったほうがよかった。

実は当初、KVSガチ勢の本気を見せつけるべくTkrzwで書いていたのだが、Tkrzw-Rubyにkeys相当のメソッドがなく効率が悪かったので断念した。

tkrzw-rubyはmakeすると

/usr/include/ruby-3.0.0/ruby/internal/stdalign.h:93:1: エラー: template with C linkage
   93 | template<typename T>
      | ^~~~~~~~
tkrzw.cc:38:1: 備考: ‘extern "C"’ linkage started here
   38 | extern "C" {
      | ^~~~~~~~~~
make: *** [Makefile:213: tkrzw.o] エラー 1

とか言われるが、tkrzw.ccの

#include "ruby.h"
#include "ruby/thread.h"

を

extern "C" {

より前に持ってくればビルドできる。

videocompress.zshは割と細かく気を使ったものになっている。 Nemo Actionから呼び出すphotoutils.zshは典型的なパラメータセットを指定できるようになっている。

圧縮の効果測定

動画 ゲーム動画のVP9

Furiというゲームのプレイ動画

% du Furi
24303016    Furi

圧縮後 (24.65%)

% du -s .
5992804 .

ゲームプレイ動画に関しては、発生ペースも速く(長時間の動画になりやすく)、ソースが非常に高いビットレートであるのに対して圧縮の余地が大きいため、圧縮は必須である。

参考までに、原神のFHDプレイ動画を変換したもののビットレートは以下の通り。 Radeon ReLiveのビットレートはおよそ30000kb/s固定であるため、ソースは30000kb/sと仮定してサイズ比も示した。

1714 kb/s (5.71%)
1965 kb/s (6.55%)
1431 kb/s (4.77%)
3011 kb/s (10.04%)
2639 kb/s (8.80%)
3955 kb/s (13.18%)
3689 kb/s (12.30%)
6888 kb/s (22.96%)
1830 kb/s (6.10%)
3320 kb/s (11.07%)
3685 kb/s (12.28%)
1913 kb/s (6.38%)
3560 kb/s (11.87%)
3340 kb/s (11.13%)
5243 kb/s (17.48%)
4184 kb/s (13.95%)
8310 kb/s (27.70%)
6100 kb/s (20.33%)
5382 kb/s (17.94%)
5114 kb/s (17.05%)
2471 kb/s (8.24%)
5543 kb/s (18.48%)
6137 kb/s (20.46%)
5473 kb/s (18.24%)
8289 kb/s (27.63%)
7031 kb/s (23.44%)
6379 kb/s (21.26%)
6192 kb/s (20.64%)
6351 kb/s (21.17%)
4099 kb/s (13.66%)
1482 kb/s (4.94%)
6715 kb/s (22.38%)
6452 kb/s (21.51%)
7022 kb/s (23.41%)
4110 kb/s (13.70%)
4335 kb/s (14.45%)
1974 kb/s (6.58%)
9311 kb/s (31.04%)
7651 kb/s (25.50%)
6064 kb/s (20.21%)
3848 kb/s (12.83%)
4567 kb/s (15.22%)
8210 kb/s (27.37%)
8363 kb/s (27.88%)
7915 kb/s (26.38%)
3629 kb/s (12.10%)
5054 kb/s (16.85%)
10233 kb/s (34.11%)
9536 kb/s (31.79%)
9565 kb/s (31.88%)
3529 kb/s (11.76%)
7358 kb/s (24.53%)
11980 kb/s (39.93%)
4920 kb/s (16.40%)
3603 kb/s (12.01%)

最大圧縮は4.77%、最小圧縮は39.93%、平均は17.73%である。 だいたい1/5くらいのサイズになる、と考えるとインパクトは非常に大きい。 (libvpx-vp9でフレームレート/サイズ変換はなし、CRFは42)

動画 カメラ撮影のH.265

ドラムを叩いている動画

% du .
17829624    .

圧縮後(6.5%)。定点カメラで動きが非常に小さいため、ものすごい圧縮率になった。

% du .
1159676 .

家で軽く撮った動画。ソースからして量はあまりない。

% du .
922400  .

圧縮後(56.35%)。アクションカメラのように動きが激しいソースの場合、画質を維持しようとすると時間がかなりかかる上にほとんど圧縮できないことが多い。 この動画はそれほど動きがあるわけではないが、それでも最後のほうはソースのビットレートを越えてしまった。

% du .
519860  .

容量的には非常に割合が大きい動画だが、画質を気にするのなら無条件に変換すれば良いわけではない。

要求される画質がそれほど高くない場合は(libx265の場合なら)CRF25から27程度で圧縮をかけ、また画面全体での動きが小さい場合はCRF値はハイクオリティな値のままでも圧縮すると効果が大きいので圧縮するとし、一方夜間の暗い動画や動きが激しい(カメラ自体を振り回すような)動画、画質を大事にしたい場合はあえて触らない、といった判断のもとに変換を行うことになる。

なお、libvpx-vp9も極端に低いビットレートでは非常に粗いが、FHD/30fpsで10Mbpsを越えるようなものであればlibx265との画質はいい勝負になる。

写真

189枚の写真(12Mpx)があるディレクトリを選択した。

% du .
597444  .

圧縮後AVIF (13%)

% du .
78188   .

サムネイルと合わせると14.3%ほどになった。

% du .
7312    .

写真が占める容量はあまり大きくないかもしれないが、画質にこだわった場合でも大幅な圧縮が可能なため、積極的に取り組んでみてもいいかもしれない。 圧縮の負担も動画よりは小さく、手軽だ。

しかし問題は「容量があまり大きくない」ことだろう。 私だとまぁまぁやっても100GB圧縮できるかどうか…というところであり、動画と比べてインパクトは相当小さく、「必須」というほどでもない。