アプリケーション:iotptalk

文書の過去の版を表示しています。


このページは執筆中です。誤った、意味のわからない記述がまだたくさんあります。

IoTPtalk:IPtalkによる作成字幕をインターネット配信に利用するためのデバイスとそのアプリケーション

文字起こしツールとしてIPTalkはまさしくデファクトスタンダードとして国内においては広く認知されています。技術の発達によって自動文字起こしもかなりの精度まだ向上しましたが、依然として人間の手直しや人力による字幕精度には及ばないのが現状です。例えば情報処理学会アクセシビリティ研究会において、juliusによる自動字幕(Thanks for 秋田先生)、UDTalkによる自動字幕サービスを取り入れていますが、いずれも最終的には人間の手直しをした上で字幕作成を行っています。

IPTalk開発者の栗田 茂明氏によってこのIPTalkが誕生してから2019年9月現在で、20年が経過しています。大学内のダイバーシティ推進では学生による字幕保障としてIPTalkをみることがよくありますし、大きな会議においても主導字幕ではIPTalkが本当によく利用されています。IPtalk開発の歴史は https://www.jstage.jst.go.jp/article/johokanri/59/6/59_366/_pdf を参照してください。

ユーザの様々な要望に答える形で、IPTalkには非常に多くの機能が含まれています。例えば会場内の字幕文字が小さくて見えない、なんて場合は、IPTalkのローカルネットhttp機能を使えばブラウザを通じて文字通訳を手元のスマートフォン等で閲覧することができます。また、カメラ画像に字幕を表示する、なんてこともIPTalkの機能で利用できます。

一方でこれを学会のインターネット配信側から技術的観点で見直してみると、必ずしもインターネット中継配信用途に最適化されているとは言えない状況です。(もちろん、それを想定して機能追加していないので当然ではありますが)何から何まで栗田氏におんぶにだっこではいけない、と思い。アクセシビリティ研究会10回分の知見から、インターネット中継に適切にIPTalkの字幕を入れるために必要な環境を開発することにしました。

主要なインターネット配信プラットフォームであるYouTube liveでは、リアルタイム配信用途の字幕に対して

  1. URLに字幕を投稿
  2. 埋め込み608/708

の2つの機能を提供しています。詳しくは https://support.google.com/youtube/answer/3068031?hl=ja を参照してください。いずれも字幕組み込みには有料ソフトウェアを利用しなければならないだけでなく、結構高価です。更にいうとIPtalkのように複数人がチームを組んで文字起こしをすることができるかわからず、どなたか詳しい人、教えてくれると嬉しいです。「URLに字幕を投稿」という方は、post methodでテキストを送ればいいらしいのですが、技術仕様が公開されておらず、youtube側に問い合わせを行っています。有料の専用ソフトウェアでは表示される取り込みURLをいれればそのまま送信できるらしいです。

映像に字幕を載せて送ってしまうのがこれまでのアクセシビリティ研究会のやり方でしたが、英字幕自動作成ソフトウェアの Web Captionerでは公式HELPでcaption窓をキャプチャしてOBSへ取り込む手法を提示しています( https://webcaptioner.com/help/integrations/add-captions-in-obs/ )。

以上のようにキャプショニング自体は歴史があり(この辺、塩野目先生ご教示いただけると嬉しいっす)、様々なソフトウェアがある一方で、インターネット配信を前提としたキャプショニングに関してはオープンで共通なプラットフォームシステムがありません。

これまでアクセシビリティ研究会では原則字幕表示用PCの画面をキャプチャして、それを配信PCで取得していました。機材をたくさんもってくれば全然OKなんですが、実は機材の搬送代金だけでも往復で6,000円程度かかってしまい、年間で6,000円x3 = 18,000円と以外に馬鹿にならない金額でした。この金額で招待講演を呼ぶことだってできるわけです。そこで最小の機材構成で理想的な字幕配信を実現するための構成を考えてみます。

まずは、どのような形で連携をしたいのか、最初に目標を次のように掲げます。

  • 中継ネットワークとIPtalkネットワークは別々にしたい
  • IPtalkの字幕はyoutube live の字幕保障対応を将来的に考えてテキスト情報として取得しておきたい。
  • macOSでも動作すること

インターネット配信を行うPCにIPtalkの字幕を取得する上で一つの課題は中継PCとIPtalkPCが同一ローカルネットに構成されていなければならない点にあります。これを解決するには同一ローカルネットワークに中継もIPtalkも入れてしまえばいいのですが、ジプシー的に様々な会場で行われる中継ネットワーク環境ではこの同一ローカルネット環境を容易に実現できない場合があります。そもそもIPtalkはローカルネットは必要でもインターネットアクセスは必須ではないため、アクセシビリティ研究会がよく字幕作成依頼をおこなうキャプショニングペガサスでは各PCのIPアドレスを固定にし、LANハブを利用して作業を行うことがほとんどです。また、中継PC側では現地インターネット環境を利用するにはリスク(事前確認、firewall等のシステム側の調整)の判断が困難であるため、ほとんどはモバイル回線を利用して配信を行っています。そうすると中継ネットワークとIPtalkのネットワークが別々になり、中継PCにIPtalkを入れておいても字幕をもらうことができません。

そこで、市販ルータの中でも特に小型かつクライアントモード(Wifiを通じてネットワークにアクセスし、LAN端末を接続可能にする機能)が利用可能なルータがいくつか市販されており、こちらを利用することで、モバイル回線にすべての端末をぶら下げることが可能になります。しかしここで一点懸念事項が生じます。中継とIPtalkが同一回線になることで、ルータ側の負荷がIPtalk分増えることです。もちろん大きな負荷ではありませんが、高性能ルータを使うのは運営継続性(金銭コスト、荷物の大型化コスト)から避けたいので、なるべく回線を切り離して運営できる方が好ましいです。

ここまでの話を一旦まとめ、中継PCがIPtalkの字幕を取得するためには次のようにすれば可能になります。

  • 中継PC(Windows)でIPtalkを利用し、IPtalkと同一ローカルネットワークでシステムを構成する

このような構成にすれば、中継PCとIPtalkの連携は可能になりますが、最初に示した目標を2つとも満たしていません。そこで一つアプリケーション及びデバイスを開発することにしました。

先に述べた通り、IPtalkにはhttpサービスを動作させることでクライアントからテキストを取得することができます。数秒おきにブラウザを強制リロードすることで、クライアント側は字幕内容を読むことができます。この手法は無駄な通信が生じるほか、字幕テキストをスクロール表示することができない問題があります。そこで、本研究ではIPtalkの通信プロトコルから直接テキストを受信することにします。

IPtalkはUDP形式でテキストを送受信しており、通信ポートを6711から100番ごとに班を振り分けています。基本的に複数班に分かれるほど大きなキャプショニングの現場に居合わせたことがないのですが、だいたいはA班(6711-6810)のポートが利用されています。中でも6711番が表示用ポートでここに表示用の文字列が表示されます。詳しくはIPtalkのマニュアル (http://www.nck.or.jp/shiryou/150923IPtalk_zentai.pdf )を参照してください。

マニュアルにはそこまで詳しく書いてないのですが、6711番からは字幕情報がテキスト情報のみ送信されてきます。xmlやjson等のいわゆるタグ情報は含まれていません。またテキスト情報は日本語が含まれるわけですが、文字コードがshift-jisにて送信されてきます。macOSではutf-8がデフォルトであるため、正しく閲覧するには文字コード変換をする必要があります。Windows10ではまだsjisが標準にようですが、すでにutf-8の設定ができているように文字コードの移行は待ったなしかなと思います。

まとめると

  • 6711番でUDPでテキストを取得できる
  • 送られてくるshift-jisをutfに変換する必要がある

先に述べたように、中継ネットワークとIPtalkネットワークを分離したいのですが、そのためにPCを二台利用するのは運用面から現実的でないので、実装するシステムは

  • Wifi機能がついた超小型IoTデバイスつかう

ことで問題の解決を試みます。

次に取得したテキストをどのような形で配信者が扱えるのかを考えます。取得用アプリケーションに配信機能を入れてしまえば一つのアプリケーションで完結しますが、近年ではOBS(Open Broadcaster Software)が非常に多機能であるだけでなく、近年のゲーム画面を配信しながらプレイヤーがコメントを入れていくいわゆる実況系動画が広く認知されたことで、大きく開発が進んでいます。著者もアクセシビリティ研究会当初からこのOBSを利用して配信業務を行っているため、このOBSからの配信を前提として研究を進めます。

OBSに字幕情報を取り込むには次のような手段があります。

  • テキストファイル読み込み
  • 画面キャプチャ
  • Syphonクライアント

任意のテキストファイルを指定することで、コンティニュアスにテキスト情報を画面内に表示することができます。様々なテキスト装飾が施せる柔軟性がありますが、このテキスト表示には読み手のユーザビリティに重要なスクロール機能がありません。

テキストを取得したアプリケーション上で画面に表示したものをそのままOBSの画面キャプチャを利用して、配信することができます。非常に柔軟性が高い機能なので、先に紹介したWeb Captioningでも紹介されている手法です。この手法ではアプリケーションの画面をまるまるキャプチャすることになるので、アプリケーション側の表示したくないもの(設定GUI等)も一緒にキャプチャされてしまいます。

最後に紹介するのがSyphonクライアントを利用する方法です。Syphon( http://syphon.v002.info )とはmacOSにてアプリケーション間で画像データを受け渡す通信プロトコルでVJやメディアアート界隈で広く利用されています。これをもちいることで、アプリケーション側からはOBSに渡したい画像データだけを送信することができます。また自分でコードを組めばアプリケーション上でスクロール処理も可能です。

以上のことからUDPプロトコルから取得したテキストデータをSyphonを利用してOBSにその画面を送信することにしました。

ではいよいよ実装です。今回作成する著者の慣れと、OS依存をなくすことからPCアプリケーションとしてはProcessing ( https://processing.org )を利用して実装しました。またIoTデバイスにはESP8266( https://www.switch-science.com/catalog/2500/ ) を利用しました。

ESP8266はWifiチップの名前で、それを扱い安くしたarduinoボードである ESP-WROOM-02開発ボード を利用しています。このボードに開発したプログラムを書き込んだものを以後IoTPtalkと呼びます。配信者側は具体的には次のステップで設定を行います。

  1. 配信用PCにIoTPtalkをusb接続
  2. コントロール用アプリケーション(IoTPtalkController)を起動
  3. IoTPtalkのシリアルポートを選択する。
  4. 必要に応じてWifiネットワーク設定(ssid, password)を変更してrestartする

上記手順にて、IoTPtalkがUDP(6711)を通じて受信したデータをそのままシリアル出力します。IoTPtalkにはインジケータLEDが備わっており、

  • Wifiネットワーク未接続:赤
  • Wifiネットワーク接続中:赤点滅
  • Wifiネットワーク接続済:緑
  • データ受診時:白色点滅

となっています。

Processingにて開発を行いました。起動時の画面は下記の通り。

このアプリケーションにてテキストサイズ、行間、スクロールスピードを設定します。画面に表示されているキャプション画面はそのままSyphonプロトコルを通じでOBS上から取得ができます。なおIoTPtalkController自体にもUDP通信機能があるため、IPtalkと同じネットワーク上にいれば画面上にIPtalkのキャプションがデバイスを接続しなくとも流れてきます。上記画像はUDPから直接取得しているところです。デバイス側から取得している場合は画面右上のアイコンがUSBアイコンに変わります。USB接続をしている間はUDPからのデータは表示されません。

  • /home/users/2/lolipop.jp-4404d470cd64c603/web/ws/data/attic/アプリケーション/iotptalk.1568439228.txt.gz
  • 最終更新: 2019/09/14 14:33
  • by baba