重い仕事を極端に軽く作る

以前は配信の仕組みを組むとなれば、媒体の枠組みを入れ、変換の道具を継ぎ、前に頁のサーバーを立て、そのうえで互いの版に意見を持つ部品の連なりを維持する必要があった。設定を一行変えるのは、爆発物を解くような心持ちだった。ここでの提案は逆である。実行物は一つ、起動すれば動き、外部の依存は一切ない。

Go で書かれ、もともとは一つの規約の名を冠した企画から育った。対応する規約が増えるにつれ、古い名では野心を収めきれなくなり、名を変えた。この来歴が、小ささと広さの両方を説明する。同じ実行物がサーバーでも動き、一枚の基板の機械でも動く。多くの媒体の束がそう名乗れない点だ。

網の意味での媒体の振り分け

最も巧みな立ち位置は、これを土台ではなく媒体の振り分けとして置いたことだ。流れはカメラから RTSP で入ってくる。見る側は都合のよい形を選べばよい。閲覧ソフトで遅れを小さくする WebRTC、見返しのための HLS、その規約を待つ相手へ渡す RTMP。同じ源で、規約は見る側の端で選ばれ、源には触らない。

監視の集約が最も光るときだ。家の複数のカメラを一つの実体へ送り、机の機械や携帯で閲覧ソフトを開けば見られる。利用者側の道具も、カメラごとの設定も要らない。自分で行う直播も同じくらい自然で、送る道具が流し込めば、見る人への配分はすでに片付いている。

入場の確認、記録、道ごとの振り分けは、支払いの段や足し物ではなく設定の項目として揃っている。しかも全体が一枚基板の等級の機械に収まる。本番の機能を趣味道の装置で、という組み合わせはあまり見ない。

設定は区分を持つ一つの書類で、説明書を開かなくても読める。道には名前があり、規約は道ごとに入れ切りでき、既定の値は最初の試験にほとんど何も足さなくて済むほど妥当だ。これは聞こえより重い。媒体の環境が腐るのは、道具が悪いからではなく、半年後に五つの動く部品をどう繋いだか誰も覚えていないからだ。

より大きな仕組みの一部としてもよく振る舞う。振り分けは本来そこに置かれる。一つの規約しか話さないカメラはここで揃えられ、別の一つしか話さない見る側はカメラに触れずに扱え、記録は両端を変えずに横で走る。どれもその場で解ける小さな問題で、連なり全体を建て直す理由にはならない。

基盤の道具も軽くあれるという証明だ。一つのファイル、一つの設定、依存は零、重い仕事を軽々と運ぶ。ここでの単純さは稚拙ではなく、複雑さと向き合った後に残るものだ。

期待の置き方を正す

まず一つの境目を書く。合うかどうかを決めるからだ。これは流れを受け入れ配るもので、変換はしない。カメラが出す形を見る側が解けないなら、設定をどう変えても直らず、連なりに処理の工程を足す必要がある。もう一つは規模で、非常に大きな相手への配分は内容の網や群れの後ろに置くべきで、その荷を小さな実体に押し込むのは設計の読み違いになる。

初めて試す人への実務的な助言。まず道を一つだけ開き、あるカメラや一度の送信が本当に届くことを確かめ、そのあとで入場の確認と記録を足す。この種の道具での行き詰まりは、たいてい全部を一度に埋めてから、どこが違うのか分からなくなることから来る。

その範囲の中では、ほぼ最も安い答えだ。家の見守り、区域内の配信、互いに譲らない二つの道具の間の規約の調べ。どれも一つのファイルを起動すれば片付く。開かれた許諾で無料、机の上の環境から低電力の ARM の機械まで揃い、手入れは活発で、説明も詳しい。取得一回分の代価で、より凝ったものを建てる前に一度試す値がある。