状態更新・状態遷移の難しさ
コンピュータのシステムの話で、単にキャッシュってめんどい、という話だが、情報科学を学んだときにあまり深刻に考えていなかったが重要な問題だと思うので述べる。
状態更新・状態遷移のシチュエーションと最新状態の参照について
データソースAと、Aを活用する（たとえば表示する）アプリケーションC
があり、ユーザーはCをある頻度で利用するとする。（たとえばツイートの蓄積されているサーバがAで、WEB版ツイッターのインターフェースがC）
もしいくらでもAへのアクセスが可能であれば、Cへのアクセスの度に随時Aへ取得リクエストをかければよい話だが、一般的にAは例えば外部のAPIであったり、DBサーバだったり、ファイルストアだったり計算サーバだったりする。はたして”いくらでもAへのアクセスが可能”だろうか。実はそのような場面は結構少ない。CとAが同じ物理サーバでかつ、参照コストがかからない（高速アクセス可能なローカルストレージを参照など）場合などであれば問題ないが、そうでない場合が多い。
そして至極当然のことだが、これらの対応のために、データソースAが返すべきレスポンスを蓄積して高速・低コストに返す「キャッシュB」が生まれることになる。キャッシュBを介すことで、大量アクセスに対応できたり高速にレスポンスできたり、そもそも静的に保存しているため計算コストが安く済むなどの利点がある。
しかし、キャッシュを導入するということは、キャッシュ保持時間＝更新頻度というものがついて回る。つまり”常に最新の値を取得できる”ということが無くなり、情報最新性への妥協であったり、時差を考慮したシステムの開発が必要になる。
概念として、そして巨大サービスにおいてそのようなものがあるのは学生のころから知ってはいた(DNSやWebブラウザのキャッシュなど）が、いざシステムを開発・運用するとなったときに、この問題は至る所で壁となる。
更新頻度≒更新遅延
一般的にデータの受け渡し・状態遷移の伝播は１段階ではない。多段階になり、そのホップ数が多いほど、更新頻度が低くなる。最新データの取得を希望する場合、更新遅延が長くなるともいえる。今回は主にこの、最新データの取得を希望する場合・リアルタイム性が求められるサービスをつくっている立場から述べる。
複数のホップ数があることをかみ砕くと、
１ホップ目、２ホップ目、の更新頻度がT1,T2,...Tn であった場合、最終的な最大の更新遅延はT1+T2+...+Tnとなる。最小の更新遅延は max(T1,T2,...,Tn)となり大したことないが、タイミングを正確に合わせない限り、最大の更新遅延を引くことは多々ある。ご覧の通りホップ数が増えるごとに最大の更新遅延はどんどん伸び、ユーザー体験は損なわれていく。（一方サーバ管理者はサーバ機能の細分化ができてうれしいことが多い）たとえば最新のニュース記事を見たいのに２０分後にならないと見られない、というようなことが起きる。
どのような場合に、更新頻度が長くなるのか、いくつか例を挙げる。
例１ 外部RSSを参照して、記事の情報を取得する
取得先RSSは静的なファイルではなく動的に生成する場合、レスポンスに時間がかかるし、何より先方のサーバに著しく負担をかけるためアクセス頻度を下げろという要求をされていることもある。
→更新遅延はあっても更新頻度は確保できる という場合もあるが、それすら妨げられる。→先方のシステムが悪いともいえる。
例２ 自社の記事管理CMSから、最新の記事５件を取得する
コンテンツ蓄積とともにDBは肥大化していくことや、低頻度のアクセスを想定した廉価なクラウドサービスを利用していることが影響し、高頻度でのアクセスは避けたい・低廉な仮想サーバのためレスポンスに数秒かかることが多々ある。それらの理由からバッファをもって５分単位での更新にするなど。
→DBの設計の難しさの話と、オンプレ至上主義の話につながるが、現実的に出会うことの多い問題である。そして安易に５分単位で更新時間を決めることの是非も・・
例３ いわゆるふつうのCDN
CDNはキャッシュそのものであるから当然ではあるが、CDNを介したデータ取得ということは、TTLが決められており、その事前設定した時間だけ更新頻度が遅くなる。ただ、CDNを使う目的はあくまでアクセスの分散であるから、別に更新頻度を下げる・古い情報の露出を許容しているからというわけではない。
→例えば誤った情報の修正・ネガティブキャッシュの存在など、キャッシュ機能が運用の邪魔をすることがあり、その場合キャッシュの開放（パージ）や、インデックスファイルのみTTLを短くするなどの方法をとるが、リアルタイム性を求めるサービスとCDNの相性の悪さがあることは主張したい。
例４ 大きなファイルを取得する・計算する必要がある場合
ちょっと毛色は違うが、大きなファイルを名前を変更せずに更新する事を考えると、リモートサーバから取得している途中はファイルとして破綻しているので、使い物にならない。なので最近のウェブブラウザの挙動でも見られるが、一時ファイルとして別名でダウンロードを行い、ファイル完成後にリネームを行い上書きすることが必要になる。ダウンロードにかかる時間が遅延時間に直結するのはもちろんのこと、この「ダウンロード中のアクセス」を正しく対応しなければ、システムのエラーにつながるのも注意したい。一方でサーバ（Linuxなど）の「リネーム」は”十分一瞬”に終了するからユーザーに影響を与えることはない、のは興味深い。”リネーム中にアクセスしたからファイル破損扱いになった！”ということは起きうるのかもしれないが、十分に無視できる事象といえる。
◆私の驚き
単に情報＝データを”すぐに”別の場所＝サーバから持ってくるというのがこんなにも困難なことだったのかということに驚く。そしてそれは世の中ほとんどすべてのサービスに影響するものになるから、もっとこれに関する学問やアーキテクチャの議論があっても良いのではと思う。いや、当然すでにあるのだろうけれども少なくとも学生の時にこんなこと考えもしなかった。
◆色々経験を経ての教訓
・システム（データフロー）をシンプルにすること。役割などの区別から、多段階での処理をしがちである。一般的に複雑な問題は分割せよと言われている。しかし更新遅延を考えるとそうも言ってられない。一番問題を簡単化するのは、データフローをシンプルにすること。
・あらゆる段階において高速なレスポンスを求めること。普通のサービスで異常が起きても無いのに数秒もかけてレスポンスしているのは異常だし、避けるべき。細かなアルゴリズムの工夫や無駄な処理の削減できることは多々ある。動画像処理やAIなどで計算時間がかかるものもあるが、かなり考慮したシステム設計が必要になる。
・キャッシュサーバの保持時間はあまやかしてはいけない
”キャッシュサーバだから保持時間が長いのは当然でしょ笑”というような甘えた設計では、多段階でデータの受け渡しをすることでかなりのボトルネックになってしまう場合がある。しっかりと処理能力を鑑みて、CPUにはがんばってもらって、できるだけ短い保持時間にするべきである。一見保持時間がいくら長くても良いだろうと思っていても、システムの遠いところで影響を与えることがある。
◆おわりに
かなり自分の関わっているプロダクト（コンテンツ管理とその表示WEBインターフェース、他社APIとの連携 など）を基準に偏った内容で、前提設定が足りない部分が多々あると思うが、具体例などはいくらでも出せるので、気になったことがあれば答えられる。
放送現場で使われる有線映像伝送方式・ケーブルの種類
4年半ほど働き、"相場"というものがわかってきて、そろそろ放送現場で使われている技術を語れるようになってきたので、今回、映像伝送方式についてまとめつつ紹介する。
無線・IPは今回含めない。前提として無線より圧倒的に有線のほうが安定するという考えのため有線接続は現場でもまだまだ多用される。IPは有線より方式が乱立しており、さらにIPネットワークの知識も必要で輻輳などの難度の高い障害対応が求められるため、特に流動性の高い映像現場においては有線接続がまだ幅を利かせている。
SDI (Serial Digital Interface)
THE 業界標準。なのにネット上に情報が少ない。
とにかく無劣化無圧縮な信号を銅線（*1同軸ケーブル）を用いて伝送する。
シンプルな接点が接触すれば映像が伝わるので、安定性が高い。加えて遅延もほぼ無く、伝送情報量が多くデジタルで劣化がない。何より100メートルほど伝送できるのでSDIで対応できない場面が少ない。超長距離伝送する場合を除いて、現場での利用率は圧倒的である。
解像度
規格によって周波数が違い伝送できる容量が異なる。地上波レベルはHD-SDIで伝送可能なので、HD-SDIが一番普及している。4Kを伝送するには12G-SDIが必要になる。
- HD-SDI 1.4Gbps の伝送帯域で、HD=1920x1080 を30フレームまで送れる。地上デジタル放送レベルではこれで十分。（地デジは*2 1440x1080 59.94i）
- 3G-SDI 2.9Gbpsの伝送帯域で、HDを60フレームまで送れる。
- 6G-SDI 5.9Gbpsの伝送帯域で、4K=3480x2160を30フレームまで送れる。
- 12G-SDI 12Gbpsの伝送帯域で、4Kを60フレームまで送れる。（BS4K放送は60fpsが基本）
伝送距離
規格とケーブルの品質による（同軸ケーブルは大きく分けて3C・5C等があり、ケーブルの太さと取り回しやすさのトレードオフになっている）が、HD-SDIでは約110メートル程度、12G-SDIでは70メートル程度まで伝送できる。現場回りでの配線は問題ないが社屋の端まで引っ張るには足りないため、リピーター（リクロック）を介したり、あきらめて光ファイバーでの伝送で対応する。最近は基本的には室間は光ファイバーでの伝送をするのが吉（そうなると中身はIPになることもある）
端子
BNCが多く使われる。取り外しには回転が必要で外れにくく非常に便利。
もっと多く普及しているテレビアンテナ用のケーブルに使われるF端子がすべてBNCに入れ替わればよいと思う。
マイナーな端子として、コンパクトに端子を設置するためにDIN・mini-BNC・Micro BNCというものがある。DIN以外はめったに見かけない。
また、BNCの中でも圧着方法は多彩で、それぞれ細かく性能（周波数帯による伝送距離など）が異なる。
音声
無劣化で16チャンネルの音声を伝送可能。
5.1ch=6chの音声とステレオ音声を合わせて伝送できるため8chまでは使われることがあるということもあり、8chまではサポートする機材がある。
HDMI (High-Definition Multimedia Interface)
民生用機材において圧倒的な普及率を誇るため、無視できない規格。SDIとHDMIが混在することが多々あり、*3互いの変換がまた問題となる。
多くのバージョンが存在するため、高解像度の映像を扱う場合はケーブル選定に注意が必要。音声や制御信号も含み、これ1本で多くのことに対応可能できる。
欠点は伝送距離が短いことと、SDIに比べると仕様が複雑であること、何より端子が19ピン・外れやすいなどで安定性が低いことである。
民生用のため著作権保護(HDCP)機能や、機器間の認証・信号が規定されている。
解像度
スタンダードHDMIでは1080iまで、ハイスピードHDMIでは1080pまで、さらに4K・8Kと規格に応じて高解像度・HLGに対応可能となる。
伝送距離
一般的に5メートル以内とされるが、光ファイバーで数十メートルに延長する商品も存在する。
端子
HDMI-Aという一般的な形式に対して、Mini HDMIと呼ばれる HDMI-C端子、Micro HDMIと呼ばれる HDMI-D端子が存在する。小型カメラの多くはMicro HDMI端子を備えている。
いくつかの端子種類が存在するため煩雑なうえ、対応端子によってはさらに接合部が不安定であるので、より確実な接続ができるHDMI-A端子が歓迎される。
音声
仕様上は8chまで対応できるらしいが2chまで対応する機材しかほとんどない。
光カメラケーブル（多治見・LEMO）
完全に業務用。電源やインカム、システムカメラの映像伝送に用いられる。電源・制御は銅線で、映像は光ファイバーで伝送する。各2本ずつ合計6本が束ねられており、このケーブル1本があればすべてが完結する。
200メートル以上は伝送でき、スタジオのシステムカメラとしてはもちろん、中継現場などで多く用いられる。接続部に光端子（フェルール面）があるため微小な汚れでも伝送に障害が発生する。
その他
放送業界では基本的には使われないがまだまだ存在する。
UVC(USB Video Class)
USBで映像を伝送する規格。もともとはWebカメラからPCに映像を送るためのものだったが、仮想WEBカメラ的に映像をPCに送るために、上記の映像規格をUVCでPCに入力する需要が増えており、変換コネクタが多く販売されている。
多くのブラウザや一般的なアプリケーションで扱うことができるため汎用性は高い。フォーマットはMJPEGが基本だがサポートされるフォーマットも増えている。
映像と音声が異なる仕組みで入ってくるため絵と音がずれることが多い。
音声はUSB Audio Class(USB Audio Class)。
DVI (DVI-D DVI-I DVI-A)
18-24のピンを用いて映像を伝送する。PCモニターでよく利用される。
フルHDから4Kまで対応できるが、アナログ信号も使うことがあり、互換性のため様々な端子がある。基本的にはDVI-Dを想定していればよい。音声は通さない。
Display Port （Thunderbolt)
8KまでのPCの様々な解像度に対応する。伝送距離が短い。音声は伝送できる。
HDMIと同じくバージョンが多数あり、ケーブルの選定が難しい。Thunderbolt端子がカバーするプロトコルにも含まれる。昨今のThunderbolt4対応のUSB Type-Cケーブル周りで普及が進んでいる。
VGA(D-SUB・RGB)
古いコンピュータはだいたい対応している、世の中で一番普及している映像ケーブル。15ピンの端子で 2048x1152 （フルHDよりちょっと大きいのでモニタとしては十分）まで表示できる。しかしアナログ。音声は伝送できない。
使わないので説明を省略
コンポジット S端子、RCA
SD画質までしか対応していない（規格が作られていない）ため、ほとんど見かけないが、端子がついているモニタなどは多い。余った端子を有効活用したいときには考えるがSD画質なので萎える。
コンポーネント端子 D端子(D1～D5)
D5はフルHDを伝送できるため一部現場で見かけることもある。端子などの機材がまったく存在しないので触ることはない。
動画ビットレート感覚
動画のビットレートは、動画視聴環境・満足度に大きく影響するものの、評価軸が画質となるため主観で判断するしかなく、それ故あまり語られることが少ない。
テレビのマスター機器の設定は地デジの仕様・MPEG2ノウハウの不足があり頻繁に変えられないことから難しいが、動画配信となるとH264であるし、しがらみもなく、ビットレートを任意に定めることができる。ただし、映像素材品質・映像素材種類・配信環境・エンコーダ圧縮性能・解像度・受信環境・求められる安定性をもとに適切なものを選ばなければならない。結局のところは自分の”ビットレート感覚”に頼らざるを得ない。
世の中のビットレート
まずは、世の中で流れている動画ビットレートの相場を知るべきである。ということで調べた世の中のビットレート（自分・拾ってきたもの）を以下羅列する。
実測：地上波TS MPEG2
BS11 18Mbps MAX 22Mbps
BS民放系 13Mbps MAX 15Mbps
BSプレミアム 15Mbps MAX 18Mbps
地デジ本放送 13Mbps MAX 16Mbps
地デジカラーバー 2.4Mbps
地デジムービングカラーバー 5.5Mbps
参考:BS4K・8K HEVC(H.265)
4K MAX 30Mbps
8K MAX 100Mbps
動画ウェブ配信 H.264 fullHD 30f
YouTube 9Mbps
Amazo Prime 16Mbps
ベースバンド
HDMI 60p 3.2Gbps
HD-SDI 60i 1.4835Gbps
自分のビットレート感覚は
HLSの技術的問題は別途述べるとして、基本的にはビットレートは低いに越したことはない。
ちなみに今自分の設定するH264 720p30F の配信サービスにおいては、QVBRでMAX 500kbps 1.5Mbps 2Mbps の3ストリームとしている。
主観ではあるが、2Mbpsほどあれば動きが相当激しくなければ十分の地デジを上回る画質となり十分であると考える。つまりは地デジレベルを目指さなければ1.5Mbpsくらいで充分。
（もし10Mbpsくらいで投げられれるならば、最高の画質になりそう）
これはエンコーダの品質が優れているからであって、市販のエンコーダやPCでの配信(OBSなど)では、同等の画質を再現するには+1Mbpsほど必要であると思われる。
受信環境の話
いわゆる”ギガ”の消費のためには低ければ低いほどいいが、一番重要なのは、動画が停止しないこと、バッファ状態にならないことである。実際の状況を想定すると、4G回線の非CA状態であれば10Mbps以上出る。ただし昼12時台や夕方18時台の混雑時間帯には2,3Mbpsくらいになることは想定され、さらに格安SIMの状況や通信制限状態(128kbps)もありうる。流石に128kbpsは無理なので、格安SIMが時間帯によっては際限なくスピードが落ちることを想定すると、500kbpsやそれより低いビットレートを用意することは重要と思える。さらに、そこまで基準を下げておけば、残念なWi-Fi環境などにおいても役立ちそうである。
今後の課題
先に挙げたビットレートを定めるための条件を改めてみて、まだ自分の中でさっぱり解決できていないこととしては、エンコーダ圧縮性能・画質の定量評価、解像度とビットレートの関係がある。画質の定量評価は、永遠の悩みだとはおもうが、解像度とビットレートの関係（同じ1.5Mbpsで360pと720pではどちらがいいのか、など）は、動画を見る画面の大きさにも依存するところがあり、まだ答えが出ていない。
WAVEファイルとラジオ 概要
Waveファイル、拡張子でいうと.wavは、PCM（パスル符号変調）でアナログ音声を最も単純にデジタル化した無圧縮音声ファイル形式であるので、今の時代において一般的には、”ただの音質が最高に良いファイル形式”という認識を持つ人が多くなっていると思う。
一方放送局では、テレビはさておき、ラジオではWaveのまま放送波に乗り、聴取者に届くため、常用するファイル形式である。そして放送に利用する上で必要な機能であるタイムコードやCue信号などを付加するBWFという拡張形式も存在し、実は奥の深いファイル形式でもある。
BWF
1997年にEBU (欧州放送連合)が仕様策定したこともあり、放送業界独自の技術と言って過言でない。また日本独自にBWF-Jという拡張形式も存在する。民放連の定めるラジオCM素材搬入基準は、BWF-Jである。
EBUによるBWFのドキュメント| https://tech.ebu.ch/docs/tech/tech3285.pdf
JPPAによるBWF-Jのドキュメント| http://www.jppanet.or.jp/bwf-j/jppa-1-2009_bwf-j_audio_file_format.pdf
2GBの壁
4GBの壁とも呼ばれるが、Waveは32ビット記述をされており、ヘッダ内にファイルサイズを示す部分があるため、32ビットで示せないファイルサイズになることができない。符号ありの整数として解釈されることも多く、その場合2GB程度までが限界となる。Waveはビットレートとサンプリングレートを自由に決めることができるが、一般的なレートにおいては、数時間の音声で２GBに達してしまう。よって限界を超える長時間番組をファイル化することが本来できないが、BWFにより、複数ファイルを同一音声として扱うことで対応する。またWAVE64という64ビットバージョンのファイル形式も存在し、問題は解決することができる。
今後、Waveのヘッダや、BWF(BWF-J)によるファイル構造の違いを調べ、いじっていきたい。
