Ustreamのモニタリング指標

自己もしくは誰かのライブ中継をモニタリングする場合についての考察です。

Ustreamを中継している現場で一番困るのは「ちゃんと中継できてる?」のか把握できないことです。潤沢な回線がありPCパワーも有り余っていれば折り返しの映像や音声を見る事はできますが、それでも大抵の現場は戦場ですからあまり冷静にモニタリングすることはできません。

UstreamモニタリングTEST画像

また、多くの場合は戻り回線を確保できず不安を抱えながら中継を続けることになります。特に少人数(多くは一人か?)でやることも多いUstreamではどのようにして中継品質を現場フィードバックしたら良いのでしょうか?
この命題は別にUstreamに限った話ではないのですが、放送局等の「伝統的な中継」では組織対応が原則なため、どこかに問題があればすぐにチェックが可能です。それに対してここ10年ほどの技術革新で一人で歩きながら動画中継ができるようになり(Macworld Expoがあったころは会場で勝手にやってました)、Ustreamやニコ生の登場で爆発的に普及した「パーソナル中継」 では事実上「垂れ流し」にするしかありません。(”垂れ流れ”ていることが確信できるならば問題はないのですが、意外な見落としがあったり、急変があるので楽観は危険です)

もちろん10年前と違い今は21世紀でソーシャル・ネットワークが発達しており、中継の末端にまでダイレクトにメッセージを戻す事が可能ですが、実のところあまり有益な形でのフィードバックはできていません。一つには送出者が知りたい時に知りたい情報(状態)を知る事ができないという問題があります。

ありがちなやりとり

  • 送:Ust見えてますか?
  • 受:見えてますよ〜

まあこれでも最低限「中継が全く見えていない状態ではない」ことは確認できます。ただ、なかなか誰も応答してくれなかったりすると「ひょっとして全然見えてない?」とかいやな考えが頭を過ります。

ある程度視聴側の人材の協力が望める場合は、この種の確認の「プロトコル」を定めておくのが良いでしょう。映像・音声・通信に関してそれぞれ5段階程度の評価基準を定めておいて「品質:555、良好です」「品質:535、音声が途切れます」「品質:244、映像なしですが音声ありです」などと報告をあげます。

以下の指標はあくまで 参考ですが

符号
映像
音声
通信
1
全く出ない
全く聞こえない
全く通信がない
2
時々動く
時々聞こえる
時々流れる
3
半分ぐらい動く
半分ぐらい聞こえる
半分ぐらい流れる
4
時々止まる
時々止まる
時々切れる
5
全く止まらない
全く途切れない
全く切れない

のような指標を使うわけです。

これだとどれかに”3″が混じるようだと要注意、4とか5中心ならとりあえずOKとなります。これはあくまで「出るか」「出ないか」での指標ですので「中身の品質」は問題にしていません(映像は若干踏み込んでいますが)。

特に音声関係の問題は別途伝える必要があります。

  • 「音声が小さい」「大きい」
  • 「歪んでいる」
  • 「ノイズが乗っている」「ハムが乗っている」
  • 「マイクが吹かれている」
  • 「音がこもっている」
  • (ステレオ時)「片chがOFF」「逆相」
  • 「大統領、ピンマイクがONです」

映像に関しても

  • 「暗い」「明るい」
  • 「ホワイトバランスが変」
  • 「Zoom見切れてます」
  • 「カメラが天を見上げてます」「地を〜(ry」
  • 「アスペクト比設定が変です」
  • 「カメラ前のおっさん邪魔です」

などは別途知らせる必要があります。
通信に関しては、通常はあまり視聴者側では(送出側でも)チェックしないと思いますが、TCP Monitor Plus(Windows)などを常用することで、おおよそのビットレートやバーストの加減を知る事ができます。 Ustreamの場合CDN経由で大規模サーバクラウドに接続されるため、個々の視聴者の不調=送出側の不調 ではないのですが、複数のフィードバックを得ることで「もしかしたら送出側の上り回線が不調?」かもしれないことをあぶり出せます。

例えば、

  • 「品質:222、絶不調です」
  • 「品質:111、全くダメです」

という報告がいっぱい上がっていても

  • 「品質:444、問題ありません」

という報告が一件あれば、送出側の問題ではなくCDNかサーバクラウド側の問題ということになります。

次に中身の品質に関してですが、

映像に関してはそもそもどういう品質(設定)で送出しているのか判りませんし、マシンパワーが足りているのかも不明です。またソースの品質も不明です。このため「映像自体の品質」に関してはフィードバックしてもあまり意味がありません。 ですが、マシンパワーまたは回線帯域の不足で、大きな動きがあると画面が止まるなどの問題があれば、フィードバックすることで改善できる可能性があります。マシンパワー不足ならば「いらない常駐を切る」「ブラウザでの返りのモニターをやめる」「GUIを切る」「エンコーダマシン上で遊んでいるのをやめさせる(実話)」などが考えられます。帯域の場合も「不要な通信を削る」「自動アップデートを止める」などが考えられます。また「カメラの動きを抑える」ことは帯域不足時に最も求められることです。

音声のレベルに(音量)に関しては一番問題が複雑です。レベルマッチングが正しく、キャリブレーションの取られた環境ならば、マージンの範囲で「何dB上げる」とかできますが、「上げると歪みまくる」とか、そもそも「OFFマイク過ぎだから」とかでブーストできないこともあります。また「レベルは振れるが音量感がない」なんて場合もありコンプレッサーを挟みたくなります。実際今より回線が細い時代には常にコンプレッサーとEQは使用していましたが、最近は面倒になったのと同時に結構レートが高く取れるようになったので省略してしまっています。うちでWaveSpectraなど使ってモニタリングしているのはその辺の名残です。

ただUstreamの場合も映像寄りの設定にすると、音声のサンプリングが22.050KHzなんて場合も出て来ますので、不要帯域をフィルタでCutしたり明瞭度を高めるイコライジングを施したりすることで聞き易い中継を作れると思います。また逆にFMチックな積極的なコンプレッションで音造りなどするのも面白いかもしれません。

以上のすべての前提は「安定した環境で視聴できる人が的確なフィードバックを返す」ことですが、そういう活動を啓蒙するのと同時に「これを機械的にやれないのか?」とか思うわけでいろいろ試行錯誤を始めています。一番いいのは良く言われるように「自分のコピーロボットを自宅に配置する」ことですが まずパー@ンやドラ@もんをどうやって確保するかが問題になります。

トラックバックURL: http://meteor.blog.avis.jp/archives/185/trackback

コメント

(必須)

(必須)
(メールアドレスは公開されません)