次世代パッケージ管理システムあれこれ

パッケージ管理システムとは

Windowsのパッケージ管理システム

Windowsでは馴染み薄いけれども、早い話が「アプリケーションをインストール・アンインストールする際に各種ライブラリなどの依存関係をいい感じに処理してくれるシステム」のこと。

パッケージ管理システムでアプリケーションのインストールなどをするようになると「アプリケーションの配布ページにアクセス→ダウンロード→インストール」という3つの手順が「パッケージインストールコマンドを打つ」という1つの手順だけで済むようになるので非常に楽。

Windowsの場合はユーザの見かけ上は馴染みが薄いだけでWindows8以降ではMicrosoft StoreからインストールできるUniversal Windows Platform(UWP)アプリはパッケージ管理システムを経由してインストールされていると言って間違いないはず

それ以前にもChocolateyやScoopなどのWindows向けパッケージ管理システムは存在しており、プログラマを代表とする情報技術者は使っている人が多いと思う。

Macのパッケージ管理システム

MacユーザであればMacPortsやHomebrewはほぼ当たり前のようにインストールするパッケージ管理システムなのではないかと。

ハードウェアに依存しているけれどもPOSIXな設計のOSとして情報技術者にも人気が高い。

現在のパッケージ管理システムの問題点

現在のパッケージ管理システムには大きな問題点が1つある。

それは導入しようとするアプリケーションの依存関係にライブラリの更新が必要な場合、依存するライブラリは上書きアップデートされるというもの。

もしこのライブラリが下位互換を持たないとき、他のアプリケーションが古いライブラリを使用している場合、他のアプリケーションが動作不能に陥る可能性がある。

依存するライブラリの理想としては完全な下位互換があるべきだけど、例えばPythonやRubyなどの非後方互換性は有名で、更新によるアプリケーションやサービスの沈黙を経験した人は少なくないはずだ。

次世代パッケージ管理システムはこの問題点を解消すべく動き始めた。

4つの次世代パッケージ管理システム

現在の次世代パッケージ管理システム開発は競争の状態にあり、代表的なものに「Nix(Guix)」「AppImage」「Flatpack」「Snappy」がある。

Nix(Guix)

次世代型パッケージ管理システムと言っても、その言及は思ったよりも古く、固有名詞のパッケージ管理システム名として正式に最初に登場したのは2004年の「Nix」だった(Guixは2012年に登場したNixのGNU実装)。

インストール先とバージョン管理

Nix(Guix)の最大の特徴はインストールするパッケージは/usr/binなどへ一意にインストールされるわけでなく、その固有のディレクトリにインストールされるということ。

これはバージョン違いの同一アプリケーションパッケージであっても同様で、例えばPython2.xとPython3.xは別の固有ディレクトリへインストールされる。

これらの管理はパッケージ毎にハッシュ値が与えられており、ユーザは任意にバージョンをローカルでロールバックできる。

パッケージのアンインストール

ユーザがパッケージをアンインストールしようとするとNix(Guix)はハッシュ値を元に問い合わせ依存関係のないバージョンのライブラリパッケージのみアンインストールする。

マルチユーザ

パッケージは固有のディレクトリへインストールされるので管理者権限が必要なく、各ユーザは安全(セキュアという意味でなく)にパッケージをインストールできる。

欠点

各バージョンのパッケージが固有のディレクトリへインストールされるということは、つまりそれだけ多くのストレージを消費するということに他ならない。

パッケージファイルはバイナリファイルなので、テキストベースでできているプログラムソースコードのような差分バージョン管理は難しく、各バージョンのパッケージを丸々バックアップする他ない。

例えば、ソースコード管理定番のGitもイメージファイルなどの大きなバイナリファイルは差分管理しているわけでなく、Git LFSによって丸々バックアップしている。

ただ、昨今のストレージ容量の進化を見ると大きな問題になりにくいとは思うが、組み込みなどストレージ容量に限界があるときは大きな問題になるだろう。

ちなみに正式にMacもサポートしている点は着目すべきかも知れない。

AppImage

AppImageは正確に言うとパッケージ管理システムではない。しかしそのシステム上、次世代パッケージ管理システムと似たような振る舞いができるので取り上げる。

名称の変移

最初期の言及はNixと同様に2004年と古く、当時「Kilik」と呼ばれた。2011年には「PortableLinuxApps」と改称し、2013年に「AppImage」と改称した。

改称しても開発自体は一貫として行われている。

インストールしない

AppImageの最大の特徴はLinuxシステムから見て、インストールしていない状態でアプリケーションとして扱えることにある。

2011年の「PortableLinuxApps」という名称から判るように設計思想としてはポータブル向けのもので、USBメモリなどで持ち運んで様々なLinuxディストリビューションで扱えることを目的としている。

インストールが必要ないので当然ながらマルチユーザにも対応している。

ライブラリを同梱する

通常のアプリケーションはLinuxディストリビューション毎に最適化されたバイナリパッケージが必要であるが、Linuxディストリビューション毎にアプリケーションの動作させるために必要なライブラリのディレクトリが微妙に違ったり、ライブラリのバージョンが適合していない可能性がある。

AppImageはLinuxシステムから見てインストールしないという振る舞いをするため、そのアプリケーションを動作させるために必要なライブラリを同梱させ、上記の障害を回避するように努めている。

ただ例外もある。それは例えばX Windows Systemなど多くのLinuxディストリビューションへまず導入されているであろうライブラリ群は同梱しないことがある。

AppImageのバージョン管理

AppImageはそれぞれが非常に独立性の高いパッケージなので、バージョン管理はパッケージバイナリをまるごとディレクトリなどで分類させることが現実的な管理方法となる。

これをバージョン管理というには些かスマートさに欠けるが、次世代パッケージ管理システムの多くもパッケージバイナリをバージョン毎にまるごと保存する手法が取られているのでコンセプトとしては非常に近い。

AppImegeと次世代パッケージ管理システムの最大の違いはアップデートさせるシステムやバージョン管理するようなツールがないこと。

多くの読者も感じているだろうが、AppImageはWindows界のインストールを必要としないアプリケーションのアップストリーム運用に近いものとなる。

欠点

欠点はNixと同様にバージョン毎にパッケージが独立して存在しているのでストレージ容量を圧迫するということ。

Nixと比較してもライブラリを同梱するという方針もあり、Nixよりもパッケージサイズが大きくなる可能性が高い。

更にアプリケーションの拡張子による関連付けができないので、MP4を選択したときにAppImageな動画プレイヤを候補表示するといったことが難しい。

Flatpack

Flatpackは実行環境を隔離して動作させる仮想環境を用いたパッケージ管理システム。

アプリケーション専用

Flatpackの最大の特徴はアプリケーション専用だと言うこと。このアプリケーション専用とは事実上GUIアプリケーション専用のようなもので、より大衆的なユーザビリティを目指して開発されているような印象を覚える。

サンドボックスとランタイム

Flatpackは実行環境を隔離して動作させる仮想環境を用いたパッケージ管理システムで、パッケージインストールに伴うLinuxシステムや他のアプリケーションへの影響を最小限に留めることができる。

サンドボックス上で動作するアプリケーションは、ライブラリとコマンドが内包されたランタイムを参照して動作する。

このランタイムは例えばPython2.xとPython3.xなどの違いを持ち、Flatpackは適切なランタイムを選択しアプリケーションを適切に動作させる。

インストールとアップデート

Flatpackのインストールとアップデートもランタイムを参照し、必要なランタイムがインストールされていなければリモートリポジトリへ問い合わせ、リモートリポジトリに必要なランタイムが存在しなければインストールやアップデートを実行しない。

アプリケーションの安定動作を考えるのであればFlatoackは非常に良い設計思想を持つということになる。

バージョン管理とOSTree

FlatpackのリポジトリはOSTreeで実装されており、OSTree側のバージョン管理機能で古いビルドを呼び出すことができる。

これは他の次世代パッケージ管理システムのように固有のディレクトリへアプリケーションのバイナリを保存しておくという手法ではないので、ストレージ容量的には有利だ。

ただ正直なところ、ここまで大衆的なユーザビリティを目指して開発されているのにも関わらずバージョン管理だけは従来通りのOSTreeのコマンドを打たなければならないのは少々釈然としないけど、大衆的なユーザはそこまでアプリケーションのバージョンを行き来しないので別に良いのかも知れない。

GitもGUI関連は最近やっとまともになってきたので時間が経てば解決する問題かも知れない。

Snappy

昨今人気の高いLinuxディストリビューションUbuntuを開発しているCanonicalが推している次世代パッケージ管理システム。

最近のCanonicalのSnappyに言及した文書には「Snaps」と表記してあるので、もしかしたらSnappyからSnapsに改称したのかも知れない(改称した宣言が見当たらないんだけど・・・?)

Snappyのサンドボックス

SnappyもFlatpackと同様にサンドボックス内でアプリケーションを動作させる設計。

Snappyにはアプリケーションを動作させるためのライブラリ群もパッケージ内に含まれており、その点で言えばAppImageのアプローチに近い。

ただし、AppImageのようにLinuxシステム上からインストールされていないという振る舞いではないので、拡張子からの関連付けは可能。

チャンネル

Snappyの特徴として「チャンネル」と呼ばれる複数のリポジトリの存在がある。

これは難しいことは何もなく、内容は「stable(安定版)」「candidate(安定版の候補)」「edge(非安定版)」「beta(betaテスト版)」ということで、既存のパッケージ管理システムにも似たようなリポジトリ群を用意している場合が多々あるので迷いは少ないかもしれない。

これらのリポジトリの同一名アプリケーションは切り替えて使用することが可能。

ちなみにGUIからもチャンネルの切り替えができるので大衆的なユーザビリティも考えられている。

バージョン管理とリビジョン

Snappyは古いパッケージをリビジョンとして管理しており、リビジョンを指定することによって古いパッケージをインストールすることが可能。

範囲

SnappyはFlatpackよりも扱う範囲が広く、アプリケーションのみでなくライブラリやLinuxカーネルまで扱う範囲として考えられている。

同様の範囲を持つのはNix(Guix)で、Snappyはこれまで考えられてきたパッケージ管理システムの良いとこ取りをしようという意図が感じられる。

欠点

例に漏れずストレージ容量を圧迫する傾向がある。

そして最大の問題として挙げられているのは移植性の問題。

Snappyは現在多くのディストリビューションをサポートしているが、事実上安定して動作しているのは本家本元のUbuntuのみであり、他のLinuxディストリビューションでは何かしらの問題を抱えている状況がある。

SnappyはUbuntuで使うのであれば非常に良くできており、コマンドもわかり易く快適なパッケージ管理が行えるが、Ubuntuだけしか上手く使えないという現状がどう変わっていくのか注視していく必要があると思う。

色々書いたけれど

つまるところ、次世代パッケージ管理システムは安定した依存関係の解消と、その解法にバージョン管理システムを選択しているというのが特徴。

それぞれに微妙な特色と差異があり面白く、これらの知識を得ると使い慣れた既存のパッケージ管理システムが古く感じて「そうなんだよね依存関係の兼ね合いでシステムが汚れちゃったりとかさぁ・・・」みたいな不満が出てしまう。

次世代のバージョン管理システムは提案から数えると15年以上はずっと検討されている題目で、最近やっとユーザが使えるシステムとして動き始めた段階。

練れ親しんだAPTやRPMやPacmanなどが、もしかしたらMacPortsとHomeBrewみたいな関係性になるかも知れないと思うと少し胸が熱くなるのはボクだけだろうか?

蛇足

当初この話題、グルドンへ思いっきり連投してやろうかと思ったけれど、ふと冷静になり「間違いなく長文になってマストドンでやる話じゃないw」と自重してブログにすることにした経緯がある。

文章の作りとかそういうの無視して書きたいことを書き殴ったので乱文乱筆だったでしょうが、ここまでお付き合い頂き感謝しかないです。

もしこの話題にご興味があればどうぞグルドンで話しかけてやって下さい。皆さんはどのパッケージ管理システムを応援しますか?

ではでは!

動画ファイルバックアップのための圧縮形式を考える

ことのはじまり

「そう言えばグルドン系YoutubeやBackspace.fmで動画のバックアップに関する話題が出ていたな」と思い出し「バックアップと言えば圧縮だよね」と各種圧縮形式でMP4動画を圧縮してみました。

圧縮する動画ソース

圧縮する動画ソースは手元に残っていたWakazo VLOG #016にしてみた(ボクは動画のバックップを取らない派)。

動画の情報というのは、定番のFFmpegの下記コマンドで確認できるので覚えておくと重宝すると思う。

ffmpeg -i INPORTFILE

下記の情報は見易く加工しています。

  • Wakazo VLOG #016
    • コンテナ mp4
    • ファイルサイズ 6.502GB
    • 再生時間 00:17:17.63
    • ビットレート 50132 kb/s
    • オーディオ形式 aac
      • 周波数 48000 Hz
      • チャンネル stereo
      • ビットレート 128 kb/s
    • ビデオ形式 h264
      • 解像度 3840x2160
      • ビットレート 49996 kb/s
      • フレームレート 30 fps

ということで色々実験していきましょう。

ZIP(Info-ZIP ver 3.0)

ハフマン符号化を利用した古典的な圧縮形式。

32bit版と64bit版があり、32bit版にはファイルサイズ4GBまでという制限があるので、動画のバックアップを考えるとZIPでは64bit版の一択。

ファイルサイズ 実行時間
6.424GB(98.79%) 6分54秒479

ファイルサイズの98.79%とは圧縮前の動画ソースの6.502GBを100%として見た場合の大きさ。つまり圧縮前の動画ソースのから1.21%小さくなったということ。

ボクの環境ではZIP圧縮だと1分あたり約1GB処理できるようです。

ファイルサイズがそこまで小さくなっていない理由は、そもそも殆どのメディアコーデックは既にハフマン符号化による圧縮処理が入っており、似たようなアルゴリズムを重ねてもあまり意味ないというのが理由です。

そして個人的に巨大ファイルをZIP圧縮すると書庫が壊れ易いという経験則もあったりするので、動画ファイルのバックアップにはああまり向かないという印象があります。

bzip2(bzip2 ver 1.0.6)

bzip2はWindows界隈ではあまり有名じゃない圧縮形式だと思います。

bzip2はハフマン符号化に加えてブロックソートや先頭移動などの圧縮アルゴリズムを採用した圧縮形式です。

ファイルサイズ 実行時間
6.370GB(97.97%) 26分17秒947

圧縮前の動画ソースのから2.02%の圧縮ですが、実行時間が物凄く伸びてます。

これはbzip2圧縮が遅いのではなく、アルゴリズムが単純なZIP圧縮が速いと考えた方が良い。

書庫機能は無く、複数ファイルを扱う場合はtarなど書庫形式でひとまとまりにしてからbzip2で圧縮する必要がある。

7zip(7-Zip ver 16.02)

LZMAと呼ばれるアルゴリズムを採用した圧縮形式。Windows界でもそこそ有名。

ファイルサイズ 実行時間
6.343GB(97.55%) 101分46秒810

複雑な処理をしているため一気に実行時間が100分超え(※環境による。ドリキンさんなら半分以上速い)。

100分超えで2.45%の削減が効率良いのか?というのは人それぞれの価値観によるところだとは思う。

xz(XZ Utils ver 5.2.4)

こちらもLZMAを活用した圧縮形式。

7zipはWindows界で多用されていますがxzはLinux界で多用されているLZMAな圧縮形式。

bzip2などと同じく書庫機能は持たず、複数ファイルを扱う場合はtarなど書庫形式でひとまとまりにしてからxzで圧縮する必要がある。

ファイルサイズ 実行時間
6.358GB(97.77%) 110分29秒669

xzもやはりLZMAを使っていため100分越えの実行時間となってしまった。

まとめ

ファイルサイズ 実行時間
動画ソース 6.502GB
ZIP 6.424GB(98.79%) 6分54秒479
bzip2 6.370GB(97.97%) 26分17秒947
7zip 6.343GB(97.55%) 101分46秒810
xz 6.358GB(97.77%) 110分29秒669

今回はすべてデフォルト設定のまま圧縮してますので、高速設定や高圧縮設定にすると特に同じLZMAを活用している7zipとxzは逆転する可能性がある。

総評

やはり当然ながらギガバイト単位のメディアファイルを圧縮すると物凄い時間が掛かることがわかった。

実は物凄い時間が掛かることは実験前から既に推測できていたことで、実際の数字がどのようなものになるのか?を見たかったという気持ちが大きい。

グルドンでの言及通り、基本的には「バックアップストレージ容量の節約を考えるのであれば生データ保存やZIP圧縮という選択肢は無い」ですし「圧縮すると解凍にも時間が掛かるので頻繁に古いファイルを引っ張り出す人は生データのままバックアップした方が良い」です。

今回の実験で得られた知見としては「マルチメディア編集のバックアップと実用の間を取るなら、そこそこの速度で2%圧縮を実現しているbzip2は使い易いかも」ということでしょうか。

編集した動画を寝ている間にアップロードしておき、平行して動画クリップをbzip2圧縮するというソリューションが想定できます。

たかが2%圧縮といっても、動画クリップが100個200個になってくると生データと比較してギガバイト単位で変わってきますので、ストレージを節約したい方は検討してみると良いかも知れません(1TBの動画クリップがあったら約20GBも節約できる)。

ちなみにbzip2をWindowsで扱う一番手っ取り早い方法は「7-Zip」をインストールすることです。7-Zipはbzip2の圧縮解凍に対応しています。

LZMAに関しては長期保存向けと考え運用すると良いかも知れません。

以上です。何かのお役に立てれば嬉しく思います。

プログラミングを学ぶ上で重要なたった3つのこと

はじめに

ボクはいわゆる「プログラミングができる人」です。

ただこの表現だと「物凄く高度なプログラミングができると勘違いされる」ので、IT業界で長らく使われているスラングの「アマグラマ」と自称することが多いです(プロと対比してアマ)。

そんなアマグラマなボクが今までプログラミングを学んで実践してきた中で重要としてきた3つのことを今回ご紹介したいなと思います。

プログラミングは手段である

プログラミングに興味のある人々は多くの場合「プログラミングしてみたい」と発言することが多いです。

プログラミングに興味を持ったことは大変素晴らしいことですし「じゃあやってみようぜ!」とボクも強くプログラミングへの参加を奨めます。

しかし、プログラミングを始めるのにあたって重要なことは「プログラミングは手段である」という現実です。

「プログラミングは所詮目的を達成するための手段」であって、プログラミングすること自体が目的ではないのです。

自分が得たいサービスがあるからこそ手段としてプログラミングするのであって、物凄くプログラミングするのが面倒くさいサービスならお金を支払ってサービスを得るのも手段の1つです。

サービスを得るためDIYするという手段と、サービスを得るためお金を支払うという手段には優劣がありません。その時その時の環境・状況によって適した手段があるだけなのです。

なのでプログラミングをするときは先ず「どんな目的のためプログラミングという手段を選択するのか?」を考えなくてはならないわけです。

この目的とは例えば就職に活かすため、普段の業務のため、既存のサービスに納得いかず自分専用にカスタマイズされた自分だけのサービスを作るためなどなど色んな目的があります。これらを実現するための手段としてのプログラミングなのです。

汚いプログラミングコードを受け入れる

はじめのうちはプログラミングに馴れていなくて、アナタの記述するプログラミングコードはいわゆる「スパゲッティなコード」で、プロが記述するような美しいコードは絶対に書けません。無理です。諦めましょう。

プログラミングには作法がありますが、それへ対して厳密すぎるほど従う必要は一切ないです。

何故ならアナタの目的は厳密にプログラミングすることではないはずなので、目的が達成されさえすればプログラミングコードの汚さなど些細な問題でしかないからです。

プロはプログラミングによってお金を貰っています。プロの目的の中には様々な理由によって美しくプログラミングするということも含まれていますが、アマグラマなうちはそこまで気をつけなくとも良いのです。

そして何よりプログラミング学習を実践し、ある程度考えた通りのサービスを作れるようになってくると「ここはもっとまとめられるんじゃないか?」とか「もっと高速化できるんじゃないか?」とか「新機能を増やしやすくできるように書けるんじゃないか?」とか考えるようになるとプログラミングコードは美しくなっていきます。

つまり、改善するという目的を達成する段階になってやっとプログラミングコードの美しさは考慮したら良いのです。

取り敢えず動くものを

前述から再三言っているとおりにアナタの目的はプログラミングによってサービスを得ることであってプログラミングすることではありませんし、美しくプログラミングコードを記述することでもありません。

取り敢えず目的を達成するサービスがあれば良いはずなので例えばプログラミング学習Webサイトを上から順番にナンバリング通りにやる必要もないです。

取り敢えず手を動かして、もし知識不足で手詰まりし続きのプログラミングができない状態になったときにググって調べれば良いのです。

単純な単機能サービスであっても取り敢えず動けば嬉しいですし、サービスが動いたことは自信にも、繋がりモチベーションも上がります。

アナタが思い描いたサービスのうちのたった1つを先ずはプログラミングしてみて最低限動くようにし、徐々に機能を増やせば良いのです。

プログラミングなんてこんなもの

プログラミングには堅苦しく小難しいイメージがつきまといますし、今まで手を出して来なかった人も大体は堅苦しく小難しいことに躊躇してきたのだと思います。

しかし、実際は結構プアにプログラミングというものは実践可能で、よりプログラミングに詳しくなるタイミングというのは手詰まりしたときなのです。これはきっと“プロ”グラマな方々も同じでしょう。

こんな理由から前述のたった3つを実践するだけで今日からアナタもプログラミングができる人の仲間入りでアマグラマになれるのです。

DJI Telloのための検証と実験

Special Thanks

この記事は@Cohtaroさんに検証用のDJI Telloで撮影された無編集動画を提供して執筆した記事です。

CohtaroさんのYoutubeも是非よろしくお願いします。

はじめに

きっかけ

今回の記事を執筆しようと思った理由がDJIからリリースされた200g以下のトイドローンTelloの動画の解像度が1080pに満たない720pであることで「これってもっと高画質に出来るのでは?」と興味を持ち、グルドンの中でTelloの無編集動画を募集したところ@Cohtaroさんが気前よく提供してくれたので実行へ移すことにした。

とりあえずはTelloのスペックを貼っておく。

スペック

  • 動画 720p(30fps)
  • 重量 80g
  • 速度 8m/s
  • 通信 100m
  • 飛行 13分

グルドンで主流の中型〜大型ドローンと比較するとスペック不足が否めないが、今回の検証で少しでもマシになればと思う。

前提条件

今回は前提条件としてFFmpeg(もしくは一部でImageMagick )によるフィルタリングを実行していく。
入手方法は上の公式ページからダウンロードするかパッケージ管理ツールで行う。

brew install ffmpeg #Mac
sudo apt-get install ffmpeg #Debian系orWSL(Ubuntu)

※Windowsはコマンドラインでインストールしなくて良いと思う。どうしてもと言うならWSL経由だと管理が楽だし今回の記事のノウハウを実行しやすい。

アップスケーリング

やはり先ず気になるのが解像度の低さ。せめてFullHDくらいの解像度は欲しい。
FFmpegにはいくつかのアップスケーリングアルゴリズムがあるので、それらを試していく。

Nearest neighbor(ニアレストネイバー)

詳しい話はググってもらうとして最もポピュラーな拡大アルゴリズム。
いわゆる「ペイント」の拡大方法で、画素を単純に増やす。

ffmpeg -i INPUT.mp4 OUTPUT1.png
convert OUTPUT1 -scale 1920x1080 OUTPUT2.png

※FFmpegでNearest neighborなアップコンバート面倒だったのでImageMagick使ちゃった(苦笑)

bilinear(バイリニア)

編集ソフトの拡大アルゴリズムに「高速」や「低品質」があるなら大抵はコレ。
多くの場合は単純に拡大するだけでなくアンチエイリアスのように中間色を生成してエッジを滑らにしている。

ffmpeg -i INPUT.mp4 -vf scale=-1:1080:flags=bicubic OUTPUT.mp4

bicubic(バイキュービック)

bilinearに続きポピュラーなポピュラーな拡大アルゴリズム。
事実上bilinearの置き換えとして運用されており、編集ソフトの拡大アルゴリズムに「高速」や「低品質」があるならbicubicの可能性がある。

ffmpeg -i INPUT.mp4 -vf scale=-1:1080:flags=bicubic OUTPUT.mp4

差がわかりにくいので拡大したものを上記3つを並べる。
順番は左からNearest neighbor(左)、bilinear(中)、bicubic(右)。

bilinear(中間色補完)とbicubicの差がわりにくいけれど、bicubicの方がわずかに階調表現良い傾向にある。

spline(スプライン)

スプライン曲線を利用した拡大アルゴリズム。
比較的高速でそこそこの品質を得られるがボケた印象になりやすい。
アニメのような階調の少ない映像に向くとされる。

ffmpeg -i INPUT.mp4 -vf scale=-1:1080:flags=spline OUTPUT.mp4

area(エリア)

面積平均法とも言われる事実上の縮小専用アルゴリズム。

ffmpeg -i INPUT.mp4 -vf scale=-1:1080:flags=area OUTPUT.mp4

縮小専用な理由は面積を基準にするため拡大するとNearest neighborとほぼ変わらないため。
Nearest neighbor(左)とarea(右)の比較を貼っておきます。

lanczos(ランチョス)

bicubicよりも高度なアルゴリズムを用いておりbicubicより高品質。
編集ソフトの拡大アルゴリズムに「低速」や「高品質」があるならlanczosの可能性がある。
シャープネスが強く出る傾向があり、よくsplineと比較されるのでソースに合った選択をすると良いはず。

ffmpeg -i INPUT.mp4 -vf scale=-1:1080:flags=lanczos OUTPUT.mp4

よく比較されるbicubic(左)、spline(中)、lanczos(右)の比較を貼っておきます。

高精度な端数処理

FFmpegにはaccurate_rndというより高精度な端数処理できるオプションが存在します。

試しにsplineにaccurate_rndを付加したものとlanczosにaccurate_rndを付加したものを生成しました。

  • spline+accurate_rnd
ffmpeg -i INPUT.mp4 -vf scale=-1:1080:flags=spline+accurate_rnd OUTPUT.mp4

spline(左)、spline+accurate_rnd(右)

  • lanczos+accurate_rnd
ffmpeg -i INPUT.mp4 -vf scale=-1:1080:flags=lanczos+accurate_rnd OUTPUT.mp4

lanczos(左)、lanczos+accurate_rnd(右)

高精度な端数処理オプションを付加することによってコントラストが良くなります。

アップコンバート総評

720pから1080pというそこまで大きな無理のないアップコンバートだったので品質はそこそこ確保できたのではないかと思う。

個人的にはlanczos+accurate_rndが良さげな印象を覚えたけれど、このあたりは個人個人の好みが反映されるので絶対的な基準はない。

ノイズリダクション(ノイズ除去)

Telloというドローンの価格帯から考えて低品質なカメラやエンコーダが使用されている可能性は否定できず何らかのノイズが発生していると踏んでノイズリダクションを試してみた。

ただし、ノイズリダクションは画像が平坦化しやすくなるため上手く使わないと逆に画質低下を招くので取り扱いには注意が必要

debloc(デブロック)

ブロックノイズを除去するフィルタ。作用としてはソフトフォーカス系フィルタに近いがエフェクトのブラーやガウスとは違いブロックノイズを検知して実行する。

上手く使えば細かなブロックノイズを除去し、画像の鮮明感が増す。

ffmpeg -i INPUT.mp4 -vf scale=-1:1080:flags=bilinear -deblock 3:3 OUTPUT.mp4

物凄く違いがわかりにくいので比較画像を貼っておきます。

よく比較して貰えれば指や背景の建物のジャギー感が抑えられているのがわかると思います。

High Quality DeNoise 3D(ハイクオリティーデノイズ3D)

時間軸方向のノイズを除去するフィルタ。ザラザラとしたチラつくノイズを除去する。

反面、時間軸に作用するデノイズフィルタは強くかけすぎると残像感が出てしまう。

ffmpeg -i IINPUT.mp4 -vf scale=-1:1080:flags=bilinear,hqdn3d OUTPUT.mp4

こちらもわかりにくいので比較画像を。

deblocと同様にある程度のジャギー感を抑えることが出来る。

ノイズリダクション総評

Telloが生成する動画はやはりというか一見して気付きにくいノイズが発生しており、ノイズ除去を行うことによって鮮明感をある程度は回復させられることがわかった。

Telloが生成する動画のノイズ除去のコツは欲張らず弱くノイズ除去することのように思います。

歪み補正

Telloでもう1つ気になる点と言えば時より現われるブレたような歪み。

どのような歪みが発生しているのかをわかり易くしたものを貼っておく。

輪郭線が表示されているけれどもこの輪郭線が歪みで、だいたい3〜6pxくらいの歪みが発生する。

歪み総評

対処法なのだけれど結果から言えば全て失敗した。

パッと見からもわかるけど、歪みの傾向からこの歪みは「ローリングシャッター現象」と考えられ、他の表現では「コンニャク現象」とも表現されている。

全て失敗とは言ってもFFmpegで可能な手法だと全て失敗しただけであって有償ソフトの中には「ローリングシャッター現象補正」を備えるものもあるので、そちらを試しいてみるのも良いのではないかと思う。

(FFmpegによる)対処に失敗したとは言え、Telloのローリングシャッターを、視覚的に解析した画像はネット上に存在しなかったので記録として残しておく。

おわりに

久々に低画素なソースで遊ばせて頂き、2000年代初頭かのようにワクワクテカテカしながらDJI Telloの検証と実験をしました(VHSからどうやってDVDに焼くかとかニコニコ動画用のエンコとかそんな感覚だった)。

カラグレの検証と実験をしても良かったんですけど、おそらくは皆さん編集時に色々と色彩まわりは試すのではないかと考え、ちょっとマニアックなアップコンバートやノイズリダクションの検証と実験を中心にさせて頂きました。

今回はTelloのソースで検証と実験をしていますが、普通に他のドローンやアクションカムへも応用が効く内容なんじゃないかな?と考えています(グルドンには1080p派の人も居るので4K化に応用が効く)。

惜しむべきは歪み補正なんですが、FFmpegにローリングシャッター関連のフィルタは存在せず、実はプログラマブルに解決しようと思えばできるんですが今回の検証と実験とは方向性が違うなと思ってやめました。

最後に「ボクの考えた最強のTelloアップコンバートワンライナー」を置いて締めます。

ffmpeg -threads 0 -i INPUT.mp4 -vf scale=-1:1080:flags=lanczos+accurate_rnd, -deblock 3:3 OUTPUT.mp4

こんな長いエントリにお付き合い頂きありがとうございました!

児童向けプログラミング学習について

前提として

ボクは現在31歳となり、いわゆるパソコン教育を受けた第1次世代にあたる人間です。

小学生のころから学校教育の場でパソコンに触れましたが、両親の職業的理由もあり、家庭には既にパソコンが導入され、学校以外でもパソコンに触れる機会がありました。

当時のパソコン教育は正直手探り状態という印象が強く、小学生のうちはビデオゲームに教育ソフトによって学習が進行され、中学生以降はMicrosoft Officeを中心に学習するというスタイルでした。

中学生以降のMicrosoft Officeを中心に学習するという形態はおそらく社会が求めたより実務的に近いように組まれたカリキュラムである可能性が高く、教師による授業は教師自身の業務の中から得たノウハウを紹介する形態であり、ついには中高生である期間の内にパソコン学習のためのテキストが配布されることはありませんでした(小学生時代の最初期はカリキュラム選定に迷走していたのかいきなりLotus 1-2-3をやらされたこともある)。

その中で悪名高いワードアートやExcel方眼紙のバッドノウハウを学ぶという機会もあり、パソコンのパワーユーザが多いグルドン民の皆さんが聞くとクラクラと眩暈するような授業が普通でした。

・・・いや「パソコンの授業があるだけマシ」と仰るかも知れませんが(笑)

もしかしたら「バッドノウハウ継承してゴメン!」と仰って頂ける方が居るかも?(30代が学生なら40代は新任教諭)。

児童向けプログラミング学習の現状

パソコン教育が時代の変貌でIT教育となり、現在ではプログラミング教育となっています。

表現の変更がなされたことによりカリキュラムも大幅に見直しがなされているのか、文科省関連の資料を引いてみると、ボクの時代よりも改善されていることがわかります(良くも悪くも表現の変更がないと見直さないのは日本の悪い癖ですが)。

特にボクの時代では一切説明のなされていなかった「社会とコンピュータの関わり」や「コンピュータの動作」の説明が必須として扱われているのが非常に好印象です。

これらの見直しはコンピュータ市場の広がりから関わる人口も増え、より良いカリキュラムの選定がなされたものと思われます。

更に「プログラミング的思考」としてフロー方式の思考学習がなされているのもボクの時代とは大きな違いです。

現在のプログラミング学習について総じて言えることは「想定していたよりも凄く良い」ということです。

現在のプログラミング学習に足りないもの

現在のプログラミング学習に足りないもの、それは「保護者の参加率」です。

保護者の参加率は悲しくなるくらい低く、ほとんどの保護者は「学校教育としてプログラミング学習をしてもらえている」ということに満足をし、現状子供たちがどんなプログラミング教育を受けているのか?を知らない

現代の保護者は家庭内で国語や算数の疑問質問には応じることができても、プログラミングに関する疑問質問に応じられないということへの危機意識が低く、より良いプログラミング学習とするための力が全くないのです。

現状のプログラミング学習の良いところ、悪いところの切り分けができず、プログラミング学習について意見することもできない、非常に危うい状況にあることに気付いてない。

保護者は今こそプログラミングを学ぶべき

現在の保護者世代はボクと同じ30代前後が占め、中途半端なコンピュータ教育を受けた世代です。

カリキュラムは二転三転をし、学校によってはビデオゲームするだけの授業となり果て、Microsoft Officeのバッドノウハウを継承し、社会とコンピュータの関わりを一切説明しない、そんなコンピュータ教育を受けた世代です。

こんな悪い教育を受けた我々の世代が、悪い教育を受けたことを理由として我が子からの疑問質問に応じることを放棄するのは本当に良いだろうか?と同世代の親の皆さんへ投げ掛けたい。

我が子から「今日学校でScratchで○○を作ったよ」と言われアナタたちは何と応じるのか?
我が子から「else if構文がわからないんだけど」と言われアナタたちは何と応じるのか?

我が子からのこういった言葉に応じられず「今の時代プログラミング教育は重要です」と考え、あまつさえ口にしているとするのなら無理解・無責任にもほどがあるとボクは言いたい。

練習問題

学校教育で広く採用されているプログラミング教材にScratch というものがあります。

詳細はScratchのWikipedia に詳しいですが、プログラミング教育を受ける児童のほとんどが経験する教材だと思われます。

そこでプログラミング学習を受ける児童を抱える保護者へ対してScratchで解く練習問題を示し、プログラミングの初歩理解をして頂くということを考えました。

ただ、練習問題と言っても小難しいものではなく1つのゲームを作って頂きます。

Pong

まずは動画観てどんなゲームか掴んで頂きたいのですが、このレトロなゲームは「Pomg(ポン)」と呼ばれているタイトルです。過去に日本でも「テレビテニス」という名称で販売されたこともあるビデオゲーム初期を語るには外せないタイトルの1つです。

続いて実際にプレイしてみましょう。今回の教材のScratchでPongを作成された方が入るのでScratchのPongへアクセスして頂ければプレイできます。

そしてScratchの学習について参考になるWebページとしてScratchで始めるプログラミング教育 - @IT があり、動画ではScratch 2.0入門 (全19回) - ドットインストール がありますのでお役立てください。

Pongを作成する意義

今回の練習問題Pongは例で出しているものを完全再現する必要はありません。Pongゲームとして最低限の体を成していれば良いでしょう(パドルでボールを打ち返せる程度)。

ボクがPongをプロラミングの練習問題として推す理由はプログラミングの基礎的な処理の殆どが含まれているからです。

一部を挙げるのであれば、四則演算、繰り返し、条件分岐、入出力、自動化など多くの処理がこのシンプルなゲームに含まれています。

そして昨今話題のAIも、いわゆる対戦CPUとして実装することが可能で、初歩的なAIの理解に役立ちます。

何よりPongの実装を真に理解すると、例えばシューティングゲームやマリオのようなアクションゲームなどは単なる応用にすぎず、プログラミングできるものは大幅に増えるでしょう。

そういうこともありボクはプログラミングに興味のある方へPongを推します。

最後に

保護者がプログラミングの基礎を理解することで、きっと子供たちとの会話の範囲も広がると思います。

やはり子供はビデオゲームが好きで、今回のPongは原始的なビデオゲームで、Pongの実装の理解は子供がプレイする現代のビデオゲームの実装の理解に繋ります。

子供がビデオゲームをプレイしてるときに保護者が言うわけです。

「知ってるか?最強の対戦CPUは簡単に作れるんだ。バトルゲームなら敵を無敵にすりゃ良いし、レースゲームならコースの真ん中や最短を走らせれば良いし、野球ゲームならバットがボールを追従すりゃ良い。
でもそんなゲームは面白くない。本当に面白いゲームはプレイヤが苦労して頑張ったときにギリギでリ負けてくれる対戦CPUがあるゲームなんだよ。このゲームがどうやって面白く作られてるか一緒に考えてみようか?」

これをするには保護者が少なくともプログラミングの基礎を理解しておかなければなりません。家庭内学習というものはやはり保護者の基礎理解があってできるものだと思うのです。

この記事が皆さんのお役に立てれば嬉しく思います。

BS PodcastのショーノートだけをGithHbから取得

GitHub

今現在リアルタイムでBackspace.fmライブを聴いていますが、そう言えば過去回でBackspace.fmのたいていのテキストコンテンツはGithHbで管理していると言っていたような気がしたので調べてみると以下を発見した。

GitHub - drikin/backspace
https://github.com/drikin/backspace

そのときに確か「アーカイブを聴くときはショーノートをこれで読んでる」なんていう話をグルドン民のどなたかがしていたような記憶がおぼろげにあるのでちょっと便利にしようとか考えた。

つまりは見出しどおりなわけで、普通にdrikin/backspaceからcloneしちゃうとBackspace.fmのソースなども一緒に管理するハメになり、ボクとしてはコレはコレで結構有用なのだけれど、そういうの抜きでショーノートだけ欲しい人にとっては出来ればショーノートだけ欲しいと考えてるのではないか?と思った。

ショーノートだけを得る

今回のスクリプトはすでにGit環境を構築してる方向けです。

まだGit環境を構築してない方向けのGit環境構築の仕方、UNIX/Linux系のターミナルの使い方はボクが解説するよりもインターネット上に存在する他の専門記事のほうがずっと有用なのでそちらを参照ください。

以下のワンライナーをbackspaceディレクトリを生成したいディレクトリで実行することでショーノートだけを管理できるようになります。

git clone https://github.com/drikin/backspace/ && cd backspace && git config core.sparsecheckout true && echo _posts/ > .git/info/sparse-checkout && git read-tree -m -u HEAD

以後ふつうにbackspaceディレクトリ内でpullするとショーノートだけ引っ張って来てくれます。

以下に各要素の解説を載せておきますので適宜カスタマイズするなり自作スクリプトに組み込むなりしてください。

git clone https://github.com/drikin/backspace/  # drikin/backspace/からclone
cd backspace # backspaceディレクトリへ移動
git config core.sparsecheckout true # parsecheckoutを有効化
echo _posts/ > .git/info/sparse-checkout # 保持するディレクトリ登録
git read-tree -m -u HEAD # 保持しているディレクトリ以外削除

何かの役に立てれば嬉しく思います。

ブログとしての運用に耐えうるのか?

専門サービス使わなくて大丈夫なの?

やはり気になるのは、プロバイダが提供する100MBの無料ホームページをブログ(もしくはランディングページやポートフォリオなど用途に合わせ)として運用しようとすると「それに耐えられるの?」という疑問は湧くのが普通だと思います。

結論から言ってしまうと「たぶん大丈夫!たぶんね!」って感じでしょうか。

たぶんと強調している理由がサーバの強さはプロバイダの力の入れ具合いに依存するので、ほぼ活用されなくなっているホームページスペースのサーバが強力なモノか?と言われたら苦笑を浮かべるしかないわけでドリキンさんクラスの超ビッグなアルファYoutuberだとアクセスが集中してたぶん鯖落ちするんじゃないかな?とは思うんですが、ボクくらいの吹けば飛ぶような存在だとたぶん大丈夫です。

100MBって少なくね?足りるの?

動画が数GBある時代で100MBはぶっちゃけ少ないです。

画像や動画などのメディアファイルをそのままプロバイダのFTPサーバへ保存すると速攻で100MBなんて飛ぶのでメディアを掲載する際はYoutubeのリンクを貼ったりする運用にしましょう。

例えばYoutubeなら下記のような感じでリンクさせることができます。

重いファイルは外部サービスとしておくことでホームページスペースの容量節約とプロバイダサーバに無駄な負荷を与えずに済みます。

ちなみにこのブログの雛形のサイズは700KBくらい。1投稿あたり20KB未満なので、そこそこ長期にブログを運用することは可能です。

専門サービスの利点

そもそも専門サービスの利点は「デザインどうしようか?」とか「容量どうしようか?」とか「負荷どうしようか?」とかそういうのをユーザがあまり考えずに利用できることなんですよね。

まぁだから専門サービス側は広告を表示したりして投資分をペイしようとしたりしてるわけですが。

そういうのが面倒くさかったり、広告が表示されても良いのなら専門サービスを使うべきですし、今回プロバイダが提供する100MBのホームページスペースで遊んでいるのは単に無料で付いてきてるなら活用しないと勿体無い気がするというだけなので深い意味はそこまであません。

1つの興味として

今ではボクはふと思い立ったタイミングで個人サーバを気軽に立てちゃう程度の知識と腕が付きましたが、コンピュータで遊びはじめた当初はやっぱり個人サーバって敷居が高かったんですよね。料金的にも運用のノウハウ的にもです。

ただやっぱりホームページを運用したいという興味があって、全てが揃っている専門サービスだとあまり学習も進まなくて、敷居が高くなく、お金があまりかからない良い感じのものは無いか?となったときに、こういうプロバイダが提供しているホームページスペースはなかなか良かったのです。

まっさらなホームページスペースへHTMLやCSSを直打ちしてホームページを作って遊んでボクはWebのフロントエンドを学びました。

プロバイダの中にはいわゆるCGIを許可してくれているところもありましたから、サーバサイドの触りくらいまでは学習できて、これがあったから今こうやって再びホームページスペースで遊べているのは間違いないです。

事の発端

なんでこんなことを始めたのか?と言えば前回の記事 の前に@Blank71 君がブログに興味があるようなことを話ていて、そこでボクが「Blank君ならブログサービス使うよりも静的サイトジェネレータの方が良い」と薦めたからなんですよね。

「Blank君なら」と薦めた理由がグルドンという環境もありますし、よりコンピュータへの理解を深めてくれたらなと思って薦めたのです。コンピュータに興味が出てる年齢的にもボクとそう変わらないですし、このまま行けばボク程度のレベルには直ぐ追い付くだろうなと。

Blank君自身からは話は聞いてないですけど、たぶん今の子たちがWebサイトを運用しようとして出てくる情報がAWSとか小難しくお金がかかりそう(クレカ登録必須)な情報ばかりで混乱しちゃってるんじゃないかな?だから手を出せず仕舞いになってるんじゃないかなと邪推してるわけです。

それならプロバイダの無料の100MBホームページスペースを活用したらどうか?と思い、言葉だけで説明しても理解しにくいので行動で示してみた次第です。

どうBlank君?こんな感じでプロバイダのホームページスペースって活用できるんだよ。

学生じゃなくても興味のある方は気軽にプロバイダのホームページスペースを活用してみて欲しいです。

ホームページスペースの活用

グルドンでも語ったのだけれど・・・

少し前にFFFTPの開発がストップしたという情報はキャッチしていて、本日下記のような情報更新があった。

それに対してボクもコメントを付けたのだけれど

というわけだ。

つまりどういうこと?

「こういうことだ」と言う説明だけでは不親切なので、簡単に説明すると、今実際に皆さんに見てもらってるWebページがボクのトゥートの中で触れていたプロバイダが提供する100MBの無料ホームページスペースに静的サイトジェネレータHexoを利用して生成したブログっぽいものというわけです。

見て頂いているとおり、パッと見の違和感も何もなく極普通のブログっぽい感じが出ていますが、PHPやPerlなどのサーバサイドでは何も動いていない静的なWebページとして生成されています。

もともとこの静的サイトジェネレータはWebページ制作の省力化と、そこから派生してGithub Pagesでブログやランディングページを公開が簡単に行なえるということで人気が再燃しました。

言ってみればモダンなホームページビルダーなわけで、大きなくくりでは昔懐しいテキストサイトでやっていることと殆ど変わらないと言えます。

ホームページスペースの再評価

今回のことで何がしたかったかと言えばホームページスペースの再評価です。

ボクは今回ブログ形式の静的サイトを生成しましたが、グルドンではVLOGが流行しているので、今まで作成したVLOGのランディングページやポートフォリオをプロバイダが無料で提供する100MBのホームページスペースで公開するのは普通にアリだと思うわけです(そもそも無料で付いてきているのに現在ではほぼ活用されてないわけですし)。

その1つの手法として静的サイトジェネレータHexoを使っただけであって、別にAdbee DreamweaverとかAdbee Muse、それこそホームページビルダーを使っても良いわけです。

ホームページスペースではこういう遊び方もあるんだよというご紹介でした。