アプリケーション:iotptalk

差分

このページの2つのバージョン間の差分を表示します。

この比較画面へのリンク

両方とも前のリビジョン 前のリビジョン
次のリビジョン
前のリビジョン
最新のリビジョン両方とも次のリビジョン
アプリケーション:iotptalk [2019/09/14 14:30] – [インターネット配信におけるキャプショニング] babaアプリケーション:iotptalk [2019/10/30 15:43] – [インターネット配信におけるキャプショニング] baba
行 1: 行 1:
 <WRAP center round alert 60%> <WRAP center round alert 60%>
 このページは執筆中です。誤った、意味のわからない記述がまだたくさんあります。 このページは執筆中です。誤った、意味のわからない記述がまだたくさんあります。
 +  * このプロジェクトのポイント
 +    * IPTalkもテキストをOS依存なく受け取りたい。http方式の取得は嫌。
 +    * できればIoT化しちゃってもいいのかも。
 +    * ファブリケーション可能なものとして公開する
 </WRAP> </WRAP>
  
 ====== IoTPtalk:IPtalkによる作成字幕をインターネット配信に利用するためのデバイスとそのアプリケーション ====== ====== IoTPtalk:IPtalkによる作成字幕をインターネット配信に利用するためのデバイスとそのアプリケーション ======
  
 +{{ :アプリケーション:unadjustednonraw_thumb_1753f.jpg |}}
 ===== 背景 ===== ===== 背景 =====
  
行 15: 行 20:
 一方でこれを学会のインターネット配信側から技術的観点で見直してみると、必ずしもインターネット中継配信用途に最適化されているとは言えない状況です。(もちろん、それを想定して機能追加していないので当然ではありますが)何から何まで栗田氏におんぶにだっこではいけない、と思い。アクセシビリティ研究会10回分の知見から、インターネット中継に適切にIPTalkの字幕を入れるために必要な環境を開発することにしました。 一方でこれを学会のインターネット配信側から技術的観点で見直してみると、必ずしもインターネット中継配信用途に最適化されているとは言えない状況です。(もちろん、それを想定して機能追加していないので当然ではありますが)何から何まで栗田氏におんぶにだっこではいけない、と思い。アクセシビリティ研究会10回分の知見から、インターネット中継に適切にIPTalkの字幕を入れるために必要な環境を開発することにしました。
  
 +以下、参考までにアクセシビリティ研究会最初のころは、字幕保障を中継にいれるために画像をそのままキャプチャしていました。下記のような構成図となり、多くの機材が必要となることがわかります。
 +
 +{{ :アプリケーション:従来のシステム構成図.drawio_.png |}}
 +
 +字幕保障の現場的な概要は http://www.tsukuba-tech.ac.jp/repo/dspace/bitstream/10460/938/1/Kyozai008_PEPNet-Japan_001.pdf を読むと結構わかります。
 ===== インターネット配信におけるキャプショニング ===== ===== インターネット配信におけるキャプショニング =====
 主要なインターネット配信プラットフォームであるYouTube liveでは、リアルタイム配信用途の字幕に対して 主要なインターネット配信プラットフォームであるYouTube liveでは、リアルタイム配信用途の字幕に対して
行 25: 行 35:
 以上のようにキャプショニング自体は歴史があり(この辺、塩野目先生ご教示いただけると嬉しいっす)、様々なソフトウェアがある一方で、インターネット配信を前提としたキャプショニングに関してはオープンで共通なプラットフォームシステムがありません。 以上のようにキャプショニング自体は歴史があり(この辺、塩野目先生ご教示いただけると嬉しいっす)、様々なソフトウェアがある一方で、インターネット配信を前提としたキャプショニングに関してはオープンで共通なプラットフォームシステムがありません。
  
 +【メモ】2019年9月24日に塩野目先生と少しネットミーティングさせてもらい、お話伺いました。下記のキャプショニングアプリケーションを教えてもらった。UDトークは比較的健聴者の人も使う。字幕保障もできるが、文字起こし全般で使われる印象。
 +
 +  * まあちゃん
 +  * http://barrierfree.nict.go.jp/topic/service/20150313/page4.html
 +  * https://capti3.info.a.tsukuba-tech.ac.jp/capti/tmp/index.html
 +
 +【メモ】CHI2019の論文で翻訳作業のためのインタフェースのモダリティに関する論文を発見。キャプショニングとは異なるが、完全マニュアルからCAT(Computer Aided Translation)に移行しつつあり、そのためにどのような構成操作があって、どのようなインタフェースが良いのかを39カ国のペアにアンケート調査している。https://dl.acm.org/citation.cfm?id=3300461
 ===== 中継PCとIPtalkの連携 ===== ===== 中継PCとIPtalkの連携 =====
 これまでアクセシビリティ研究会では原則字幕表示用PCの画面をキャプチャして、それを配信PCで取得していました。機材をたくさんもってくれば全然OKなんですが、実は機材の搬送代金だけでも往復で6,000円程度かかってしまい、年間で6,000円x3 = 18,000円と以外に馬鹿にならない金額でした。この金額で招待講演を呼ぶことだってできるわけです。そこで最小の機材構成で理想的な字幕配信を実現するための構成を考えてみます。 これまでアクセシビリティ研究会では原則字幕表示用PCの画面をキャプチャして、それを配信PCで取得していました。機材をたくさんもってくれば全然OKなんですが、実は機材の搬送代金だけでも往復で6,000円程度かかってしまい、年間で6,000円x3 = 18,000円と以外に馬鹿にならない金額でした。この金額で招待講演を呼ぶことだってできるわけです。そこで最小の機材構成で理想的な字幕配信を実現するための構成を考えてみます。
行 42: 行 59:
     * ただしインターネットアクセスはモバイル回線とし、ローカルネットは https://www.tp-link.com/jp/home-networking/wifi-router/tl-wr902ac/ こんな感じのクライアントモードを備えたルータで構成する。     * ただしインターネットアクセスはモバイル回線とし、ローカルネットは https://www.tp-link.com/jp/home-networking/wifi-router/tl-wr902ac/ こんな感じのクライアントモードを備えたルータで構成する。
  
-このような構成にすれば、中継PCとIPtalkの連携は可能になりますが、最初に示した目標を2つとも満たしていません。そこで一つアプリケーション及びデバイスを開発することにしました。+このような構成にすれば、中継PCとIPtalkの連携は可能になりますが、最初に示した目標を2つ満たしていません。そこで一つアプリケーション及びデバイスを開発することにしました。
  
 ===== IPtalkからテキストをもらうには ===== ===== IPtalkからテキストをもらうには =====
行 76: 行 93:
  
 ==== Syphonクライアント ==== ==== Syphonクライアント ====
-最後に紹介するのがSyphonクライアントを利用する方法です。Syphon( http://syphon.v002.info )とはmacOSにてアプリケーション間で画像データを受け渡す通信プロトコルでVJやメディアアート界隈で広く利用されています。これをもちいることで、アプリケーション側からはOBSに渡したい画像データだけを送信することができます。また自分でコードを組めばアプリケーション上でスクロール処理も可能です。+最後に紹介するのがSyphonクライアントを利用する方法です。Syphon( http://syphon.v002.info )とはmacOSにてアプリケーション間で画像データを受け渡す通信プロトコルでVJやメディアアート界隈で広く利用されています。これをもちいることで、アプリケーション側からはOBSに渡したい画像データだけを送信することができます。
  
 以上のことからUDPプロトコルから取得したテキストデータをSyphonを利用してOBSにその画面を送信することにしました。 以上のことからUDPプロトコルから取得したテキストデータをSyphonを利用してOBSにその画面を送信することにしました。
行 97: 行 114:
  
 となっています。 となっています。
 +
 +デバイスの筐体及び内部に利用しているESP8266の外観を下記に示します。
 +{{:アプリケーション:img_2385.jpeg?400|IoTPtalkの筐体とESP8266}}
  
 ==== IoTPtalkController ==== ==== IoTPtalkController ====
行 104: 行 124:
 このアプリケーションにてテキストサイズ、行間、スクロールスピードを設定します。画面に表示されているキャプション画面はそのままSyphonプロトコルを通じでOBS上から取得ができます。なおIoTPtalkController自体にもUDP通信機能があるため、IPtalkと同じネットワーク上にいれば画面上にIPtalkのキャプションがデバイスを接続しなくとも流れてきます。上記画像はUDPから直接取得しているところです。デバイス側から取得している場合は画面右上のアイコンがUSBアイコンに変わります。USB接続をしている間はUDPからのデータは表示されません。 このアプリケーションにてテキストサイズ、行間、スクロールスピードを設定します。画面に表示されているキャプション画面はそのままSyphonプロトコルを通じでOBS上から取得ができます。なおIoTPtalkController自体にもUDP通信機能があるため、IPtalkと同じネットワーク上にいれば画面上にIPtalkのキャプションがデバイスを接続しなくとも流れてきます。上記画像はUDPから直接取得しているところです。デバイス側から取得している場合は画面右上のアイコンがUSBアイコンに変わります。USB接続をしている間はUDPからのデータは表示されません。
  
 +{{:アプリケーション:pasted:20190914-143346.png}}
  
 +===== まとめ:実現したシステム =====
 +IPtalkがWindwos対応のみである点、IPtalkのテキスト取得に対する互換性のある別手法がないため、本研究ではOSを問わず、IPtalkからのキャプションをテキスト形式で取得可能なシステムを、PCアプリケーション及びIoTデバイスで実現した。これにより従来字幕取得及び発表者のスライド取得に利用していたVGA/HDMIキャプチャが簡素な構成から可能となった。以下に実現したシステム構成図をしめす。なお、このページでは説明していませんが、[[アプリケーション:slidecapture|SlideCapture]]っていうアプリケーションも合わせて作成しました。これは、発表時の様子をカメラで一括で取得し、スライド部分のみをhomograpy変換で歪みを直してsyphonにてOBSに送信するアプリケーションです。これによりスライドキャプチャ自体も単一のカメラから可能になりました。
  
- +{{ :アプリケーション:実現したシステム構成図.drawio.png |}}
  
  
  • /home/users/2/lolipop.jp-4404d470cd64c603/web/ws/data/pages/アプリケーション/iotptalk.txt
  • 最終更新: 2020/01/05 08:46
  • by baba