基礎情報と言っている割には、面倒な話が多く「配信をこれから始めるつもりでまだ何も手をつけていない人」向けではないような気もするので、そのうち「配信体験サポートページ」みたいなものも作りたいな、と思うだけ思っている。
メンドクサイ話が山盛りだが、ようするに
とても面倒な話になるので、先に荒っぽい切り分け方をまとめておく。
さて、動きのある被写体を撮影すると（動画でなく静止画でも）必ずいくらかの「ブレ」が生じる。もちろん撮影距離や被写体の動きの速さにもよるが、おおむね1/64秒くらいのシャッタースピードだと「走っている人を撮影して手足や背景が軽く滲む」程度になる（2～3万円クラスのデジタルビデオカメラだと、もっとも遅い設定が1/30～1/60秒程度）。参考までにいつものドンブリ勘定もしておこう。たとえば、幅1200mm高さ900mmの平面（でなく球面でないとおかしいが無視：水平画角60度なら1mくらい先で、普通の体格の人を上半身だけ収めるとこんな感じか）を解像度1200*900のデジカメで撮影するとき、シャッタースピードが60分の1秒なら、被写体が60mm/s＝6cm/s＝0.216km/hで動くと、ちょうど1フレームの間にセンサー1つ分の動きになる（メカニカルシャッターを省きローリングシャッターのみを用いる場合、形にも歪みが出る：上と同じ条件で画面いっぱいの縦棒を横に動かすと、上端と下端で1ピクセルずれる）。速度が2倍or解像度（画素数）が4倍orシャッター速度が半分（＝露出時間が2倍）or距離が半分になると、1フレームの間にセンサー2つ分の移動が生じることになり、飛び越えられたセンサーには被写体からの光と背景からの光が半々に入ってきて、結果としてそのピクセルのデータがボケる（歪みも2倍になる）。
画像が滲まないようにシャッター速度を速くすると、センサーに当たる光の量が減る。また当然ながら、レンズから入ってくる光量が同じであれば、画素数が増えるほどセンサー1つ当たりの光量が減る。これを補うには明るい（F値の小さい）レンズを使えばよく、F値を1.4分の1にしてシャッター速度を2倍にするとだいたいトントンになる（明るいレンズという表現には語弊があるかもしれないが、レンズ自体が曇っているとかいう問題ではなく、絞り（口径比）を解放寄りにしたレンズのこと）。いっぽう、F値を小さくすると被写界深度（ピントが合う範囲）が狭くなる。このため、被写界深度を深めに取りたい固定フォーカスだと、明るいレンズと速いシャッタースピードの組み合わせを採用しにくい（手動フォーカスだと操作の問題が、オートフォーカスだと変な挙動（コンパクトデジカメのものでさえうっとおしい動きを頻発するのに）の問題がありトレードオフ）。また被写界深度はレンズの焦点距離にも影響され、焦点距離が短いと浅く（範囲が狭く）なる。このため固定フォーカスのWebカメラはなおさら接写に弱い傾向がある（画角を広く取ると被写界深度が深くなるので、広角レンズを採用して補っている機種が多い：もちろん、極端な広角レンズである魚眼レンズを考えてもわかるように、広角にしすぎると歪みやデフォルメ効果などの問題が生じる）。レンズの特性に関する計算式はオマケ3を参照。
実際の撮影ではフレームレートが一定でないのが普通である。これはおもに光量の都合で、暗いとカメラが勝手にシャッタースピードを遅くする（目安として、動く被写体とその残像が半透明化していたらシャッター速度の不足だと推測できる）。もちろん、制御部分を改造してムリヤリ高速シャッターで撮影しても、暗くて不明瞭な画像になる。根本的な解決は、撮影場所を明るくするか、明るいレンズを使うか、センサーの感度を上げるしかない（内部に取り込める光の総量はレンズの面積、センサーが受け取る光量は「素子あたりの面積」に左右されることに注意：同じレンズなら、センサー面積が大きく画素数が少ない方が「素子あたりの光量」が増える）。当然これらの対応には制限やトレードオフがあり、強い照明ほど扱いが難しくなるし、絞りを開くと被写界深度が浅くなるし、センサーの感度を上げるとノイズの問題が出てくる。照明を強くすることでフレームレートが上がるなら、光量がボトルネックになっているのだと推測できる。カメラの「最低照度」を明記してくれるメーカーもあるが、これはあくまで「撮影が可能な最低限の明るさ」なので、どの程度までなら実用的（あるいは快適）かは自分で試してみないとわかりにくい。
もう1つの要因として、カメラ内部の処理速度（多数あるセンサーから情報を集めて、画像の形式にまとめ、設定によっては圧縮して出力するのにかかる時間）がある。多くのカメラはベイヤー配列という規則でセンサーを並べており、たとえば総画素200万で実効画素160万のカメラ（センサーの端っこの方はノイズが多く使われないため目減りする）なら、画面の映像は赤色センサー40万＋緑色センサー80万＋青色センサー40万で構成される。これを指定解像度のYCbCr（俗にYUVとも：Yが輝度、Cbが輝度と青色の差分、Crが輝度と赤色の差分で、緑色は演算で求める）に変換するのだが、記録画素（＝出力の解像度）に対してセンサーの数が足りないので補間する（ベイヤー補間と呼ばれる）。さらに、YUVには色差だけ解像度を落とすオプションがあり、4:4:4（4ピクセルにつき、Yを4ピクセル分、Cbを4ピクセル分、Crを4ピクセル分の意）だと変更なし、4：2：2だとCbとCrを横2ピクセルで共有、4:2:0は特殊で実際には4：2：0と4：0：2繰り返し、となっている。webカメラに多いYUY422（YUY2とも）は、24ビットカラーの元データをピクセルあたり16ビットで記録する（当然劣化は生じるが、目に付きにくい劣化なので多用される）。これらの処理にどのくらいのマシンパワーが必要で、一般的なカメラがどの程度の演算リソースを持っているのか筆者は知らないが、通信帯域やパソコンの処理に余裕があるのに映像がどんどん遅れる現象が見られたら、または無圧縮にしたり解像度を下げたりすることでフレームレートが改善するならカメラ内部で処理が追いついていないのだろうと推測できる。
通信速度も無視できない。USB2.0の480Mbbsという理論値（というか、純粋に「ビットのレート」であって「スループット」でない）は制御データなどを含んでおらず、実装上の限界はせいぜい360Mbps、実際の機器で安定して使えるのは（他にUSB機器を使っておらずパソコンの性能や動作が良好だとしても）200～300Mbpsくらいである（白っぽい無圧縮画像は転送が遅くなる傾向がある）。たとえば解像度2048*1536で24bitカラー（YUV422）だと1枚50Mbitくらいになるから、1秒に3枚か、せいぜい送れて4枚くらいだろう（ただしもちろん、3fpsでデータを送るからといってシャッターも1/3秒に設定する必要はなく、速いシャッターで撮影してゆっくり送っても問題はない）。カメラ側で画像を圧縮（MJPGと呼ばれる形式が主流）してから送る方法もあり、もしボトルネックが通信速度であればフレームレートを上げられる（が、圧縮の負荷が生じるので、帯域と演算のどちらがキツいかという問題になる）。また、筆者の手元のwebカメラ（後述）でもオマケ1のリンク先サイトに掲載されている複数機種のデータでも、1000Mbpsオーバーなど「最初から送れるわけがない」レートを受け付けるものがあり、ドライバがそのモードに対応するかどうかと実際のフレームレートは一致しない。
たとえば筆者の手元のBSW32K11H（Buffalo製）は、2014年6月現在のカタログスペックで「2048×1536：15fps、1600×1200：15fps、1280×1024：15fps、640×480：30fps、352×288：30fps ※フレームレートは解像度とお使いの環境によって異なります」だが、640*480だと「光っている蛍光灯を直接撮影」したときで29fpsくらい、同じ部屋で普通に撮影すると10fps前後、照明が同じなら解像度を640*480より下げてもビットレートは改善しない（同じカメラで撮影したサンプル：解像度は320*240、圧縮済み）。ドライバに情報を表示させると「Video (2048,1536)[15.00fps(66.6666ms)](1132.46Mbps)」というモード（MJPG）があり、たしかに「2048×1536：15fps」なのだろうがそんなのUSB2.0で送れるわけがない。さらに、VLCで1280*1024の8fpsモードで録画を試みたところ、フレームが飛びすぎてファイルが作れなかった（リアルタイム表示はできる）。
この項はほかと比べてもさらにややこしいので、面倒な人はここまで読み飛ばそう。便宜のため、QXGA＝2048*1536ピクセル、1080p＝1920*1080（約2M）ピクセル＝フルHD、Full-Wide-XGA＝1366*768ピクセル＝HD、WXGA＝1280*800ピクセル、720p＝1280*720（約0.92M）ピクセル、XGA＝1024*768ピクセル、SVGA＝800*600ピクセル、480p＝854*480（約0.4M）ピクセル、VGA＝640*480ピクセル、360p＝640*360ピクセル、240p＝426x240ピクセル、という対応を確認しておきたい（覚える必要はまったくない）。
視聴する人の再生環境をまず考えよう。仕様の羅列なので、挫折した人は手動で次の段落まで読み飛ばして欲しい。2014年現在、液晶ディスプレイの主流はフルHD、ノートパソコンやローエンド液晶ディスプレイの主流はHDである（フルHDとHDであれば、後者の方が利用人口が多そう：なにしろ日本ではノートパソコンが人気だし、ローエンドディスプレイをメインにしている人もかなりいるはず）後者が多そう）。が、ストリーム動画を全画面表示で見る人は（少なくとも筆者が知る限り）めったにおらず、せいぜいが「大きなウィンドウ」（正味の大きさで、フルHDなら720p、HDなら480pくらい）だろう。小さいハードでは、タブレットPCの主流がXGA（iPad miniもこれ：miniでないiPadはQXGA）とWXGA、これらは全画面表示が普通だろう。動画サイトでは、Youtubeのデフォルトが360p、ニコ動は640x384（拡大して854x480）。
ようするに、せいぜい720p（1280*720）くらいがボリュームゾーンの上限で、この解像度で「きれいに」見えるのが望ましく、たいていの場合ピークは360p（640*360）周辺にあるだろう、ということになる。元の画像が滲んだりボケたりさえしていなければ、2倍くらいのデジタルズーム（というか拡大）をしても普通は問題ないので、360pくらいが無難かなと思える。
今度は撮影の都合から一般に上限となりそうなスペックを考えてみよう。もし24ビットカラー30fpsの動画を得たい場合、YUV422で送ったとしてVGAで150Mbps近く、480pで200Mbps近くになり、USB2.0で無圧縮のまま安定して送ろうと思ったらこの辺が限界だろう。Webカメラで一般的な「静止画でフルHD」くらいのカメラが効率的に撮影できるのもこのくらいの解像度になる。4：3アスペクトから上下を削って360pにしようと思うと640*480、左右に補助画面を入れて360pにしようと思うと480*360の元画像が必要で、やはりこの辺がホットスポットなのだろう。VGAか360pかの選択は、360pに対応するカメラが少ないため実質的にできない。とすると結局、640*480のVGAで撮影して、必要に応じて360pに加工するのがラクなのではないかと思える。
圧縮時のビットレート（後述）を考慮するには、真っ先に圧縮前の画質を確認しなければならない。フレーム単位の画像が最初からボケているなら、圧縮時にビットレートをいくら上げてもボケたままである。その切り分けのためにも、録画は生データ（帯域の都合でMJPGを使うのは仕方ないにしても）で行うのが望ましい（パソコンでリアルタイムエンコードすると処理が重くなるという都合もある）。フレームレートについては、ワンセグのテレビが15fpsなので、そのくらいあればまあ普通に見られるレベルだろう（繰り返しになるが、コマごとの画像がボケていなければの話）。生理学的には12fps前後がカクつかない下限らしく、おそらく多くのローエンドWebカメラは「明るいところで15fps」くらいを目安にチューニングしているのだろうと思う（「明るい」の基準がどこにあるかは別として）。元の画像が鮮明なら多少のフレーム落ちは後からデジタル処理で補えるはずなので、画質とフレームレートのどちらかを犠牲にしなければならないときは後者を優先的に落とそう。
この項は短いが言っていることはごく単純なのでまとめておこう。
動画の場合画像の方が重い（ただしオマケ2で触れるように解像度を下げるとかなり効いてくる）ため、帯域的には音声が128kbpsだろうと256kbpsだろうと大差なかったりもするのだが、まあ普通の音声でCBRジョイントステレオのmp3ならせいぜい192kbpsくらいにしておけばまず間違いはない。
音声単品の場合Ogg Vorbisが使えるのでもう少し節約でき、設定0.4（公称172kbpsだが、普通のファイルなら130前後にしかならない）でたいてい間に合う。もしあなたがドラマーorレコーディングエンジニアで、心血を注いだシンバルの音色にとことんこだわりたいなら設定0.5（公称192kbpsだが普通のファイルなら160kbps前後）でほぼ万全になる。設定0.4と設定0.5の差は、シンバルやビブラフォンやトライアングルなど金属を叩く楽器と、シンセの特殊な音色、歪み系イフェクタから（楽器アンプのキャビネットなどを通さずに）直接出した音くらいにしか影響しない（ようするに、たいていの曲ではシンバルだけケアすればOK）。
もちろん、動画の音声にOgg Vorbisを使うという手もあるのだが、CBRを原則とするaviとの相性が悪く、OGMコンテナなどもいまひとつメジャーでないため、2014年現在、動画にはCBRのmp3か、可能な環境ならAACを使っておくのが無難ではないかと思う。
少し話題が入り乱れるが、やはり先にまとめておこう。
小見出しはこれで最後なので、この情報で満足した人は、次の大見出しまで読み飛ばそう。
多くの環境で、小規模な配信なら一般家庭の普通のパソコンだけで可能である。もしネックになるとしたら上りの通信速度で、パソコンの演算速度は、リアルタイムでグラフィックイフェクトを使うとかCGをレンダリングしながら放送するとかいうのでなければ、普通は足りるだろう。
通信速度はたとえば、音声だけなら1本あたりせいぜい256kbps、720pの動画を2014年現在Youtubeが「標準画質のアップロード」としている画質でエンコードすると6Mbpsくらい、360p（640*360：0.23Mピクセル）なら1Mbpsくらいである。これに対し2014年現在、フレッツ光ネクストハイスピードタイプが「送信（上り）最大100Mbps」を謳っており、実効は地域や環境により10～50Mbpsくらい、フレッツADSLは5Mbpsを謳っており、実効は0.5～2Mbpsくらいのようだ。ADSLの方が変動が激しい傾向はあるが、どちらも理論上限に対して「酷い環境で1割、恵まれた環境で4割」くらいが相場。
ドンブリ勘定すると、音声単体の配信なら、ADSLでも条件次第（ただその「条件」が安定しないのは苦しいが）でなんとか、光回線なら余裕でこなせるだろう（1.5Mbbsの回線に130kbpsのデータを流すとして10人同時にぶら下がれる：少ないと思う人はUstreamの「人気の番組」でもネトラジの「番組表」でも見て、10人以上リスナーがいるチャンネルがいくつあるか数えてみよう）。動画の場合、光回線なら1Mbpsを10本くらいは上げられるが、ADSLはかなり厳しい（あとでまた触れる）。
参考までに、プロが使っているビットレートを紹介しておこう。ワンセグのテレビは使っている電波の限界レートが416kbpsで実装上は128kbpsが典型的（15fps最大解像度320*240）、DVD-VideoのMPEG-1モードが最大1.859kMpsでMPEG-2が9.8Mbps（NTSC方式の最大解像度720*480）、地デジの高精細（ハイビジョン）は限界レートが16.8Mbpsで実装上は8～15Mbpsくらい（典型的解像度は1440*1080）。さらに余談になるが、コンシューマ向けの製品だと、ビクターが「ライブストリーミングカメラ」を謳って発売したGV-LSシリーズは「最大5Mbpsのストリーム出力」らしく、最大で「H.264 High Profile(1920×1080) 5Ｍbps」の出力に対応している。
通信速度はローカルでも問題になることがあり、とくにUSBホストが1つしかないノートパソコンや小型デスクトップで注意が必要。これらの機器では、カメラをUSB接続してしまうと通信量が多いほかの機器（よりによって、ハードディスクとかサウンドカードとか、動画撮影に使いたいものが見事に当てはまる）を同時利用できないか、できても制限が生じるのが普通。ハードウェアをほかのホストやバスに分散（たとえば、PCIeでUSBホストを増設するとか、サウンドカードならオンボードサウンドを使うとか、ハードディスクならeSATAにするとか）できない場合、合計帯域を節約する工夫（たとえば、マイクつきのwebカメラで内蔵マイクを使う、内蔵ハードディスクの中身を外付けハードディスクなどに移して録音には内蔵ハードディスクだけを使うなど）が必要になる。
実は、自前での配信が（仕組みさえ適切に理解すれば）もっとも簡単である。VLCでもIcecastでも、とにかく好きなサーバソフトを動かしてアドレスを告知する（またはDDNSで追ってもらう）だけでよい。とくにVLCはWindowsでもPCUnixでも（筆者には関係ないがMacOSXでも）動いて、単体で録画も配信も再生もできて、なかなか優秀である（自分でやってみようとは思わないが、コンソールでの動画再生までできるらしい）。
上記作業のうちアドレス告知をサポートしてくれるのがShoutcastで、「ここにサーバを立てました」という情報を送るとリストに入れてくれる（もちろん、リストに登録せず配信機能だけ使うこともできる）。リスナーがものすごく増えて帯域が逼迫したら、ネトラジのような「データ配信まで手伝ってくれる」サービスの出番になる（仕様がわからないがおそらく、ローカルで賄える範囲は賄わせて、あふれた分を手伝ってくれるのだと思う：まったく未確認だが、公開されている仕様の断片から雰囲気的に）。
大幅に帯域を消費するリアルタイム動画では、視聴している人に配信を手伝ってもらうP2Pも用いられる（PeerCastなど）。ただし、この形式を「ストリーム1本分の帯域があれば運用できる」とするのは間違いではないものの現実的でなく、ルートサーバ（配信の根元）にはせめて数本のアップストリームを維持できる帯域がないと、最初の数人が上り帯域の乏しい（またはネットワークの都合でポートを空けられない）視聴者だったときにネットワークが破綻してしまう。視聴者側のコスト（専用ツール導入とかポート解放とか）が大きいのがネック。
とても強力なサーバを用意してユーザー間リレーなしの配信を肩代わりしてくれるサービスもあり、オンデマンド中心のYoutubeやリアルタイム中心のニコニコ生放送などが該当する。この方法なら、リアルタイムでも「ストリーム1本分」の上り帯域があればよいため、回線が貧弱な場合に便利だろう。オンデマンドなら、たとえナローバンドでも（アップロードに根気がいるだけで）利用は可能。
このページを作るにあたってWebカメラ（USBカメラ）の情報をいくつか集めたのだが、Youtubeに掲載された動画がたいへんわかりやすかった。売り込みをしたい人は明るい場所でゆっくり動き、ネガキャンをしたい人は暗い場所やコントラストが偏った場所（中心だけ極端に明るいとか）でピントを外す。
まあメーカーもだらしないけどねぇ。一桁fpsのHDモードや融通の利かないオートフォーカスを売りにするよりは、実用レンジのVGAあたりで「これだけ使えます」ってのを自前で動画にでもすりゃいいのに（もちろん常識的な照明で）。フレームレートの宣伝なんて、軽トラにY規格のタイヤ履かせて「300km/h仕様」とか言い張ってる（ものすごく急で長くて真っ直ぐな下り坂があれば300km/h出るかもしれないけど）のと変わらないレベルだし。
と思っていたらこんなページを発見、世の中捨てたもんじゃない。
真面目な話をすると、音声データは1階（モノラル以外なら2階）、動画データは3階（単色以外なら4階）のテンソルになる。つまり、ステレオ音声では時間とチャンネルに対応する音圧データ、カラー動画では時間とx座標とy座標と色（RGBなりCMYなり）に対応する光度データを、それぞれ収納している。このため、ある解像度(x,y)の無圧縮単色動画データは、ビット深度とサンプルレートと収録時間が同じ無圧縮モノラル音声データと比べてx*y倍の容量になる（ただし普通、音声データの方が圧倒的にサンプルレートが高い）。
ここでちょっとした計算をしてみると、たとえば、モノラル48KHz16bitのPCMは48*16 = 768kbps、単色16bit15fps40*30の動画は16*15*40*30 = 288kbpmである（オーバーヘッドのない無圧縮形式で記録した場合）。動画のサイズがやけに小さく感じられるかもしれないが、解像度が低いとサンプルレートの差が効く（大きな画像は画素数が100万とかいったオーダーになるからあんなに膨れる）。さらに、動画は次数が高い分圧縮効率も高い。実際たとえば、ポータブル機器用にエンコードした手元のファイル（ビデオは30fps320*240のXVID、音声はステレオ44.1KHzのmp3）を調べると、ビデオが380kbps程度の音声が128kbpsで合計512kbps程度である。この画像は2倍（画素数で4倍）拡大の640*480にしてフルHDのメインディスプレイで表示してもまあまあ見られるくらいの画質を維持している（少なくとも、BSW32K11Hで撮影した640*480ネイティブの無圧縮画像よりよっぽど鮮明）。
焦点距離＝f(mm）、絞り＝F、ピント位置＝s(mm)、許容錯乱円径＝d(mm)のとき、前方被写界深度＝(d * F * (s - f)^2) / (f^2 + d * F * (s - f))、後方被写界深度＝(d * f * (s - f)^2) / (f^2 - d * F * (s - f))となる（前方深度が撮影者から見てピントの手前、後方深度が奥）。またセンサーやフィルムの長さをLとすると画角θ＝2 * arctan(L / 2f)となる（単位はラジアン）。この式に、F2.8、ピント位置1m、許容錯乱円径=0.033mm、センサーサイズ24*36mm（対角線43mm≒1.7inch）と、各種焦点距離を当てはめてみよう。
| カテゴリ | 広角 | 標準 | 望遠 | ||||
| 焦点距離(mm) | 24 | 28 | 35 | 50 | 100 | 200 | 400 |
| 対角画角(度) | 84.1 | 75.4 | 63.4 | 46.8 | 24.4 | 12.36 | 6.19 |
| 水平画角(度) | 73.7 | 65.5 | 54.4 | 39.6 | 20.4 | 10.29 | 5.15 |
| ピント範囲(cm) | 87-118 | 90-113 | 93-108 | 97-103 | 99-101 | 100 | 100 |
| 被写界深度(cm) | 31 | 23 | 14 | 7 | 1 | 狭い | 狭い |
DirectShowではビデオキャプチャデバイス用に、カメラの制御に関するCameraControlと、画像の補正に関するVideoProcAmpというサブセットプロパティが定義されている。しかし、後者はカメラが内部処理に対応していなくてもDirectShowがソフトウェアでやってくれる（多分）から問題ないが、前者はハードウェアが対応していなければそれまでである。
チャチなカメラだと「イジれるパラメータが1つもない」なんてのが普通で、露出を最低限まで減らしてフィルタで誤魔化すなんていう技が使えずもったいない（チャチなカメラだからこそ裏技でカバーしたいのに）。マニュアル制御を受け付けるってそんなにコストがかかるもんなのかなぁ。
理解しなくても実害が小さい話なのでずっとトボけていたが、ストリームというのは（ローレベルな意味では）ぶっちゃけ「ビット列（ないしその通り道）」のことである（並びはおもに時系列だが、たとえばメモリ上にアドレスで並んだものもストリームではあるし、ファイルもストリームを持っている）。ハイレベルな意味でファイルとストリームを比較すると、ようするに、始点と終点が固定的に定義されているかどうかの違いで、リアルタイム配信では自然とストリーミングが用いられる（ライブストリーミング）。
オンデマンド配信（ここではコンテンツを前もって用意してある＝リアルタイム配信でないという意味）の場合、配信サーバと視聴者の間がファイル配信であるかストリーミング配信であるかは、コピーガードを仕込むつもりでなければ「最後までダウンロードし終わる前に再生を開始できるかどうか」という違いである（配信者と配信サーバの間は、（リアルタイム配信と違い）ストリームでやり取りするメリットがないので、普通はファイルだろう）。
だから、音声単品のオンデマンド配信でも、たとえば1曲が3時間くらいあるとか、たくさんの曲を分割せずに配信したいとか、視聴者の下り通信帯域が極端に乏しいといった事情があるなら、ストリーミング形式にするメリットはある。反対に動画のオンデマンド配信でも、低ビットレートで収録時間が短ければ、ファイル形式で十分である。さらにプログレッシブダウンロード（ようするに自動分割ダウンロード＋継ぎ足し再生）という方式もあり、配信にはファイルを用いつつ順次再生できる（プログレッシブアップロード（あるいはストリーミングアップロードとプログレッシブダウンロードの組み合わせ）ができたら、オンデマンドと準リアルタイムをシームレスにできて便利そうだが、筆者は実装を知らない）。
しかしまあ一般的に「データがデカくてもサクっと視聴できるサービス」はストリーミングに分類されており、サクっと視聴したいデカいデータというとたいてい動画なので、やっぱりあまり気にしなくてよさそうである。