差分
このページの2つのバージョン間の差分を表示します。
両方とも前のリビジョン 前のリビジョン 次のリビジョン | 前のリビジョン 次のリビジョン両方とも次のリビジョン | ||
アプリケーション:iotptalk [2019/09/14 14:26] – [IoTPtalkController] baba | アプリケーション:iotptalk [2019/09/24 13:31] – [まとめ:実現したシステム] baba | ||
---|---|---|---|
行 5: | 行 5: | ||
====== IoTPtalk:IPtalkによる作成字幕をインターネット配信に利用するためのデバイスとそのアプリケーション ====== | ====== IoTPtalk:IPtalkによる作成字幕をインターネット配信に利用するためのデバイスとそのアプリケーション ====== | ||
+ | {{ : | ||
===== 背景 ===== | ===== 背景 ===== | ||
行 15: | 行 16: | ||
一方でこれを学会のインターネット配信側から技術的観点で見直してみると、必ずしもインターネット中継配信用途に最適化されているとは言えない状況です。(もちろん、それを想定して機能追加していないので当然ではありますが)何から何まで栗田氏におんぶにだっこではいけない、と思い。アクセシビリティ研究会10回分の知見から、インターネット中継に適切にIPTalkの字幕を入れるために必要な環境を開発することにしました。 | 一方でこれを学会のインターネット配信側から技術的観点で見直してみると、必ずしもインターネット中継配信用途に最適化されているとは言えない状況です。(もちろん、それを想定して機能追加していないので当然ではありますが)何から何まで栗田氏におんぶにだっこではいけない、と思い。アクセシビリティ研究会10回分の知見から、インターネット中継に適切にIPTalkの字幕を入れるために必要な環境を開発することにしました。 | ||
+ | 以下、参考までにアクセシビリティ研究会最初のころは、字幕保障を中継にいれるために画像をそのままキャプチャしていました。下記のような構成図となり、多くの機材が必要となることがわかります。 | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | 字幕保障の現場的な概要は http:// | ||
===== インターネット配信におけるキャプショニング ===== | ===== インターネット配信におけるキャプショニング ===== | ||
主要なインターネット配信プラットフォームであるYouTube liveでは、リアルタイム配信用途の字幕に対して | 主要なインターネット配信プラットフォームであるYouTube liveでは、リアルタイム配信用途の字幕に対して | ||
行 23: | 行 29: | ||
映像に字幕を載せて送ってしまうのがこれまでのアクセシビリティ研究会のやり方でしたが、英字幕自動作成ソフトウェアの Web Captionerでは公式HELPでcaption窓をキャプチャしてOBSへ取り込む手法を提示しています( https:// | 映像に字幕を載せて送ってしまうのがこれまでのアクセシビリティ研究会のやり方でしたが、英字幕自動作成ソフトウェアの Web Captionerでは公式HELPでcaption窓をキャプチャしてOBSへ取り込む手法を提示しています( https:// | ||
- | 以上のようにキャプショニング自体は歴史があり、様々なソフトウェアがある一方で、インターネット配信を前提としたキャプショニングに関してはオープンで共通なプラットフォームシステムがありません。 | + | 以上のようにキャプショニング自体は歴史があり(この辺、塩野目先生ご教示いただけると嬉しいっす)、様々なソフトウェアがある一方で、インターネット配信を前提としたキャプショニングに関してはオープンで共通なプラットフォームシステムがありません。 |
===== 中継PCとIPtalkの連携 ===== | ===== 中継PCとIPtalkの連携 ===== | ||
行 42: | 行 48: | ||
* ただしインターネットアクセスはモバイル回線とし、ローカルネットは https:// | * ただしインターネットアクセスはモバイル回線とし、ローカルネットは https:// | ||
- | このような構成にすれば、中継PCとIPtalkの連携は可能になりますが、最初に示した目標を2つとも満たしていません。そこで一つアプリケーション及びデバイスを開発することにしました。 | + | このような構成にすれば、中継PCとIPtalkの連携は可能になりますが、最初に示した目標を2つを満たしていません。そこで一つアプリケーション及びデバイスを開発することにしました。 |
===== IPtalkからテキストをもらうには ===== | ===== IPtalkからテキストをもらうには ===== | ||
行 76: | 行 82: | ||
==== Syphonクライアント ==== | ==== Syphonクライアント ==== | ||
- | 最後に紹介するのがSyphonクライアントを利用する方法です。Syphon( http:// | + | 最後に紹介するのがSyphonクライアントを利用する方法です。Syphon( http:// |
以上のことからUDPプロトコルから取得したテキストデータをSyphonを利用してOBSにその画面を送信することにしました。 | 以上のことからUDPプロトコルから取得したテキストデータをSyphonを利用してOBSにその画面を送信することにしました。 | ||
行 97: | 行 103: | ||
となっています。 | となっています。 | ||
+ | |||
+ | デバイスの筐体及び内部に利用しているESP8266の外観を下記に示します。 | ||
+ | {{: | ||
==== IoTPtalkController ==== | ==== IoTPtalkController ==== | ||
行 104: | 行 113: | ||
このアプリケーションにてテキストサイズ、行間、スクロールスピードを設定します。画面に表示されているキャプション画面はそのままSyphonプロトコルを通じでOBS上から取得ができます。なおIoTPtalkController自体にもUDP通信機能があるため、IPtalkと同じネットワーク上にいれば画面上にIPtalkのキャプションがデバイスを接続しなくとも流れてきます。上記画像はUDPから直接取得しているところです。デバイス側から取得している場合は画面右上のアイコンがUSBアイコンに変わります。USB接続をしている間はUDPからのデータは表示されません。 | このアプリケーションにてテキストサイズ、行間、スクロールスピードを設定します。画面に表示されているキャプション画面はそのままSyphonプロトコルを通じでOBS上から取得ができます。なおIoTPtalkController自体にもUDP通信機能があるため、IPtalkと同じネットワーク上にいれば画面上にIPtalkのキャプションがデバイスを接続しなくとも流れてきます。上記画像はUDPから直接取得しているところです。デバイス側から取得している場合は画面右上のアイコンがUSBアイコンに変わります。USB接続をしている間はUDPからのデータは表示されません。 | ||
+ | {{: | ||
+ | ===== まとめ:実現したシステム ===== | ||
+ | IPtalkがWindwos対応のみである点、IPtalkのテキスト取得に対する互換性のある別手法がないため、本研究ではOSを問わず、IPtalkからのキャプションをテキスト形式で取得可能なシステムを、PCアプリケーション及びIoTデバイスで実現した。これにより従来字幕取得及び発表者のスライド取得に利用していたVGA/ | ||
- | + | {{ : | |