SkyWayでChromeのバックグラウンドタブからのデータ送信が遅くなる現象について

はじめに

　表題の件について、現象は以前から認識していたのですが、ブラウザ側の問題と認識していて保留にしてました。

　TK (@TK11235)さんが開発している、ユドナリウムでもデータ送信速度が遅くなる現象が発生する様子で、ちょっと気になったので原因を調査してみました。

検証環境

・Windows 10
・Chrome 64
・SkyWay.js 1.1.5

データ送信（DataConnectionのsend）が遅くなる原因について

　ブラウザ側の仕様で、バックグラウンドタブの「setInterval」のウエイトが、最低1000msになるのが原因のようです。

　参考サイト：モダンブラウザのタイマー処理の制限をWebSocketを使って突破する(WebWorkersについて追記あり) (Kanasansoft Web Lab.)

　skyway.js内でデータ送信する際に「setInterval」を使用している箇所があります。
　ウェイトは1msを指定しているようなので、通常は数ミリ秒で送信されますが、バックグラウンドタブからの場合に、１秒間に1回しかデータがsendされないようです。

　そのため連続sendした場合にデータが溜まり、重くなるようです。

現象が発生する具体的なケース

　ユドナリウムの場合、プレイヤー間でPeer接続する場合に各種データを送信しあうと思うのですが、Peer接続される側のバックグラウンドタブ（または最小化状態）の場合、データ取得が少し遅れるようです。
　
　実際にユドナリウムを２つ開いて接続する事で、現象を確認できます。
（接続される側に、画像やチャットメッセージを少し登録して試すと体感できます）

　２つともフォアグラウンドタブの場合
　すぐに相手側のチャットメッセージが表示されると思います。

　接続される側（右側）がバックグラウンドタブ（または最小化状態）の場合
　チャットや画像が接続元（左側）に表示されるまで、約２~３秒掛かります。

　秒数的に、左側から右側のタブへ３回程sendしていると思われます。

　ちなみに私が作っているサービスでは、もっと遅延を発生させる事ができるのですがPC１台で再現させる手順が若干複雑なので省略します。

解決策案について

　SkyWay側の問題というより、ブラウザの仕様の問題とは思うのですが、skyway.js側で、なんらかの対策を入れて貰うと嬉しいので、対策を開発者コミュニティの方にお願いしてみたいと思います。

追記：
　SkyWayの開発者コミュニティでお願いした所、回答を頂けました。SkyWay側でサポートするのは難しいとの事ですが、対策方法等を教えて頂けました。また、私が実施した対策も書いてあるので、この問題で困った場合は、以下も参考にしてみてください。

support.skyway.io 

SkyWayの利用可能ドメイン指定とlocalhostでのデバックについて

はじめに

　SkyWayを使ったWebサービスを開発する際に、SkyWayのコンソールで「利用可能ドメイン」を指定すると思いますが、私は暫くドメインを跨いでの接続はできないと勘違いしていました。

　ドメインを跨いで接続できる事により、様々な方法でデバックできる事に気が付いたので、今回はその事について書きます。

SkyWayを利用した通常のWebサービスの動作イメージ

　はじめに、SkyWayを使ったWebサービスの動作イメージの簡単な説明をします。
　（Chromeのマーク＝ブラウザです）

　Step1　各端末がWebサーバにアクセス。HTMLやJavaScriptを取得。
　Step2　各端末がSkyWayのサーバーにアクセス。各端末のブラウザを繋げます。
　Step3　ブラウザ間で通信します。

　※実際にはもっと複雑ですが、大雑把にはこんな感じだと思います。
 

ローカルホストでの開発について

　開発時はローカルにWebサーバーを立てて、利用可能ドメインに「localhost」を指定して、開発するのが一般的だと思います。

その場合の動作メージは

　Step1　同一端末内でブラウザを２つ立ち上げ、ローカルWebサーバーにアクセス。
　Step2　各ブラウザがSkyWayのサーバーにアクセス。ブラウザ間を繋げます。
　Step3　ブラウザ間で通信します。

複数端末で、各自のローカルWebサーバーを使用してのデバック

　ここからが、私が最初気付かなかったデバック方法です。

　各端末が同一のAPIキーを指定していれば、それぞれのローカルWebサーバーのlocalhostに接続した状態でも、ブラウザ間で通信ができます。

　Step1　それぞれの端末で、各自のローカルWebサーバーにアクセス
　Step2　SkyWayのサーバーにアクセスし、ブラウザ間を繋げる
　Step3　ブラウザ間で通信
 
　この方法だと、Webサーバーを準備しなくても、複数端末を使ってのデバックが可能です。通常はこういったデバックが必要になるケースはあまり無いかもしれませんが、複雑な実装のデバックをする場合に、役に立つ事があるかもしれません。

ドメインを跨いでの接続

　SkyWayのコンソールの「利用可能ドメイン名」に、複数のドメインを指定すると別々のドメインにアクセスしたブラウザ間でも、通信が可能です。

　例えば、オンライン家庭教師のようなサービスを作る際に、生徒側がアクセスするドメインと、先生側がアクセスするドメインを別にするといった実装が可能です。

　また、生徒側のUIと、先生側のUIを、それぞれ別の形でも実装できます。

ドメインを跨いだ接続ができる事を利用したデバック方法

　前述のドメインを跨いで接続できる事を応用して
　ローカルホストと、Webサーバー間での接続もできます。

　接続イメージ

　Step1　２つのブラウザのうち、片方は外部のWebサーバーにアクセス
　　　　　もう一方はローカルホストに接続
　Step2　SkyWayのサーバーにアクセスし、ブラウザ間を繋げる
　Step3　ブラウザ間で通信

　※但し基本的には localhost からのアクセスは許可しない方が安全だと思います。
　※私は上記の形でデバックする場合、テスト用のWebサーバーを使用しています。

最後に

　こういった内容の記事を見かけた事がなかったので書いてみました。

　SkyWayを使ったサービスを開発している方や、今後SkyWay使ったサービスを開発してみたいと考えてる人のお役に立てれば幸いです。

　また何か気がついた点がありましたら、コメントかTwitterの方に連絡頂ければと思います。

SkyWayでSDPを覗いて対応Codecを確認してみました。

先日書いた記事の追記になります。

端末毎のCodecの確認方法について
SDPで判断できます。という情報をTwitterで頂きました。

SDP自体は何となく聞いた事があったので、なるほどと思い、早速確認してみようと思ったのですが、skyway.js の APIリファレンスを確認してもSDPが確認できそうな関数が見当りません。

JavaScript SDK APIリファレンス - SkyWay - Enterprise Cloud WebRTC Platform

ただ skyway.js を確認してみると「offer」や「sdp」のワードで大量にヒットします。
10,000行を超えるスクリプトなので、ちょっと見てすぐに理解できる代物では無さそうなのですが、とりあえず offerMessage や answerMessage を覗くと SDPを確認できる事がわかりました。

スクリプトのどの箇所のSDP確認するのが最適なのか判断できなかったのですが
以下の２箇所にコンソール出力処理を追加して確認してみました。

skyway.js(ver 1.0.1)の、Connectionクラス内（1,788行付近)

console.info("Connection HandleAnswer");
console.info(answerMessage.answer.sdp); 

skyway.js(ver 1.0.1)のMeshRoomクラス内（16,840行付近）

console.info("MeshRoom offerMessage");

console.info(offerMessage.offer.sdp);

※作ったサービスはMeshRoomを使っている為、上記の箇所で確認しましたが
　SFURoomやPeerで直接の場合だと、別の箇所で確認する必要があると思います。

ビデオ通話が可能なケースのSDPを確認

PC側 Chrome / Mobile側 Nexus9
※DevToolsでMobile側のConsoleログを確認しています。

Mobile(Nexus9)側で確認したログ （MeshRoom OfferMessageのSDP）
VP8 / VP9 / H264 の表記あり。Chromeの対応Codecが表示されていると思われます。

PC側(Chrome)で確認したログ（Connection HandleAnserのSDP）
VP8 / VP9 の表記あり。Nexus9の対応Codecが表示されていると思われます。

ビデオ通話ができないケースのSDPを確認

PC側 Sfari / Mobile側 Nexus9

Mobile側で確認したログ （MeshRoom OfferMessageのSDP）
H264の表記のみ。Safariの対応Codecが表示されていると思われます。

同時に skyway からエラーメッセージの出力されていました。

PC側(Safari)側では、Video/AudioのSDPメッセージ出力はされていませんでした。

結論

　SDPの読み方は理解していないのですが、予想どおりSafariはH264のみ対応だけれども、Nexus9はH264に対応していないため動作しないという事で合ってそうです。

　上記のような感じでSkyWayでもSDPは確認できるようですが、プログラムから対応Codecを判定する為には skyway.js の改造が必要になりそうです。
　skyway.jsはオープンソースなので、きっちり改造してプルリクを出してみたりしても良いのかもしれません。（私はそこまでやれるスキルと自信が無いですが）

　とりあえず、未対応Codecの場合はエラーが発生するようなので、skywayのエラーを拾えるようであれば拾って、未対応端末と表示する方針にしようかなと思っています。

最後に

　SafariのWebRTCがH264にしか対応しないと聞いたときは、よく分かってなかったのですが、色々とやっかいですね。

　現状だと、iOS端末とAndroid端末で、モバイル端末のブラウザ間でビデオ通話する場合は、Android端末がH264に対応している必要がありますが、AndroidはブラウザではH264に対応できない端末が多いらしいです。

　私はスマホアプリの開発経験がなかったりするのですが、スマホ対応は色々考えることが多く、更には機種差分もあったりして難しいですね。色々と全部ブラウザだけで実現できたら良いのですが、現状なかなかそうもいかないようです。

何か気になる点等がありましたら、コメントかTwitterの方に書いて頂ければ嬉しいです。

SkyWay(WebRTC)を使ってスマホとPCでビデオ通話するサービスを作った時にハマった箇所のメモ

　少し前に、iOS11のSafariがWebRTCに対応したので、iPhoneでのWebRTCの動作検証も兼ねて、前から作ってみようと思っていたSkyWay＋GoogleMapのサービスを作ってみました。 
 

~ 現場から中継お願いします！~

　パソコンで上記のページを開いて、QRコードをスマートフォンで読み込むと、パソコンとスマホでビデオ通話ができます。同時にスマートフォン側の位置が、GoogleMapで表示されます。現状は機能的にシンプルな感じですが、気まぐれに機能を拡張したいきたいと思っています。

　地図表示は調べれば大量にサンプルがあるので問題無く作れましたが、iPhoneでビデオ通話する部分の実装は結構苦労しました。作っていてハマった箇所と、それに対して実施した対策、未解決の問題について書いていきたいと思います。

最初に

・GoogleMapについては詳しく書く必要は無いと思われるので省略します。
・私はWebRTCの深い部分の知識は無く、SkyWay頼みで作っている感じです。

検証端末

パソコン側
　・Windows10 / Chrome 62
　・MacOS 10 / Chrome 62 / Safari 11

スマホ / タブレット
　・iPhone7(iOS 11.1.1 / Safari)
　・Nexus9 (Android 7.1.1 / Chrome)

ハマった箇所1: 同一デバイスでの複数のMediaStream

　Android(Chrome)の場合、一つのデバイスを複数のMediaStreamに利用できました。
　iPhone(Safari)の場合：一つのデバイスを複数のMediaStreamに利用できない様子。

　Android(Chrome)のみに対応していた時の実装

　　プレビュー用： MediaStreamConstraints = { video: true }
　　送信用： MediaStreamConstraints = { video: true, audio: true }
　　の２つのMediaStreamを作ってました。（そもそもこの方法が非効率？）

　以下のように修正したところ、動作するようになりました。

　　MediaStreamConstraints = { video: true, audio: true } で１つだけ作成し
　　プレビューと送信用の両方に使用するようにしました。
　（プレビュー用のVideoタグには、mutedを付けました。）

ハマった箇所2: MediaStreamConstraintsの指定

　SkyWayJSの話になりますが、MeshRoomにJoinRoomする際に、Audioのみを指定していると音がでませんでした。
（今回の作ったサービスは1対1の接続なのでMeshRoom使わなくても良いのですが、楽したい為にMeshRoom使ってます。Peerで直接繋ぐと大丈夫かもしれません。）

　対策として、使わなくてもVideoを指定する事にしました。
　修正前：
　　パソコン側：MediaStreamConstraints = { audio: true }
　　スマホ側： MediaStreamConstraints = { video: true, audio: true }
　修正後：
　　どちらも、 MediaStreamConstraints = { video: true, audio: true }

　この件については、SkyWayの開発者コミュニティに同様の問題の報告が上がっています。MeshRoomやSFURoomに接続する時に VideoとAudioを使ってる人と、Audioだけの人が混在すると上手く動作しないケースがあるようです。

　最初はスマートフォン側にはパソコン側の映像を表示しない方針で作っていたのですが、ダミーでvideoを送るくらいなら、映してしまおうと思い方針を変えました。

 ハマった箇所3: iPhoneでの音量調整

iPhoneの場合、Video / Audioタグを使った場合、Volumeを変更しても音量が変わりませんでした。そのためiPhoneの場合は、WebAudioを使うようにしてみました。

但しWebAudioも、Android(Chrome)とiPhone(Safari)で挙動が違うようです。
Androidの場合はVideo/AudioタグのVolumeで音量調整ができていたので、Safariの場合のみWebAudioを使う実装にしました。

気になる点として、iPhoneの場合はハードウェアキーでの音量調整ができません。
画面上のスライドバーでのみ音量調整が可能な状態です。

追記）iOS11.2で、Video/Audioタグを使った場合でも
　　　ハードウェアキーで音量調整ができようになったようです。

ハマった箇所4: TrackStartErrorの発生

　Nexus9にて、getUserMedia 時にエラーが発生し、プレビュー画面が表示されないケースが頻発しました。確認してみると、MediaStreamError(name="TrackStartError")が発生していました。

　エラーが発生している原因は不明なのですが、何度かリトライすると成功する感じなので、１秒毎にリトライ（５回まで）する事で対応しました。
　デバックして確認すると1～2回のリトライで成功する感じでした。

ハマった箇所5: アプリ内ブラウザ(WebView)での挙動

　LINE等のアプリから起動すると、標準ブラウザではなくアプリ内ブラウザ(WebView)で起動されます。その場合にgetUserMediaが動作しないケースがあるようです。

　・iPhoneのLINEの場合、そもそも getUserMediaが無いというエラーが発生。
　・AndroidのLINEの場合、権限が無いというエラーが発生。
　※Androidの場合は起動できるアプリもあるようです。

SafariのWebViewは、getUserMediaは未実装らしいですし、Androidの場合は、各アプリ毎に権限の設定がされていてユーザー側からは変更できないと思います。

どうしようも無いので、getUserMediaに失敗した場合は
「標準ブラウザを起動してください」と表示するようにしました。

ハマった箇所6: iPhoneのフリーズ

　iPhoneにてパソコン側から送られてきた映像をピンチアウト（２本の指での拡大）等をしてVideoタグがディスプレイの幅からはみでた場合に、iPhoneがフリーズする場合があります。(iOS側のバグと思われます）

この件については、SkyWayの公式サイトにも記述があります。
https://support.skyway.io/hc/ja/articles/236202427

　作っているサービスは、PC側から送られる映像は小さく表示していたので、暫くこの問題に気がつきませんでした。
　何度かフリーズさせてみた感じでは、PC側の映像の動かない状態で、左側にVideoタグがはみ出た場合に、フリーズする可能性が高いように感じました。仮想Webカメラ(MenyCam)を使ってテストする事が多いのですが、MenyCamの初期画面の場合にフリーズしやすい感じでした。

　スマホがフリーズしてしまうのは流石に致命的な問題なので、暫定対応として拡大/縮小ができないようにしました。

　この問題が完全に修正されるまで、怖くてサービスの公開はしづらい気がします。
　修正されたとしても、iOSのバージョンチェックして、古いバージョンは弾くような実装にしないとまずい気もします。

追記）iOS11.2でフリーズする不具合が修正されたようです。

未解決の問題1: 端末ごとの対応Codec

以下の４パターンのうち、最後のパターンはPC側に映像が表示されませんでした。

　１．PC側 chrome / Mobile側 iPhone　○
　２．PC側 chrome / Mobile側 Nexus9　○
　３．PC側 safari / Mobile側 iPhone　○
　４．PC側 safari / Mobile側 Nexus9　×

　これについてはコーデックの問題ではないか予想し、試しにMeshRoomの接続オプションで'H264'を指定してみたところ、パターン２とパターン４で表示されなくなりました。この事から、Nexus9がH264のエンコードに対応してないのでは？と思っています。（safariのWebRTCは、H264しかサポートしてないらしいです。）

　裏付けをとりたいのですが、対応端末がH264のエンコードに対応しているかわかる資料や、確認する為の方法を見つけることができませんでした。可能であれば、JavaScript上でチェックできるようにしたいです。

追記：時雨堂のVさんからコメント頂きました。SDPで確認できるとの事です。
　　　Vさんありがとうございました。

はじめまして。"対応端末がH264のエンコードに対応しているかわかる資料や、確認する為の方法を見つけることができませんでした。” こちらですがクライアント側で Offer を出したタイミングで SDP に H264 という文字列がなければ非対応と判断が可能です。参考になれば。

— V (@voluntas) 2017年11月21日

 追記２：上記について確認してみました。

iwatendo.hateblo.jp

未解決の問題2: Safariでのデバイス名称取得について

　マイクやカメラのデバイス名称の取得する為に、navigator.mediaDevicesを使用しているのですが、safariは未対応で名称取得できないようです。
　https://developer.mozilla.org/ja/docs/Web/API/Navigator/mediaDevices

　PC側で、仮想カメラ（MenyCam/CamTwist) や仮想マイク(NETDUETTO）を使いたいので、デバイス名称は表示したいんですよね。

未解決の問題3: アプリ切替時の映像表示

　現状、スマホで別のアプリに切替えて戻ってきた時に、パソコン側の映像が消える場合があります。ただ数十秒待ってると表示されるようになります。
　これについては、対策をこれから考えようと思います。

未解決の問題について

　未解決の問題１と２については、PC側はChromeを使えば問題無いです。

　Windowsユーザーの場合はSafariは利用できないですし、MacユーザーでもChromeは使えます。また、Safariは現状スクリーンシェアに対応していません。PCのスクリーンシェアをスマホに表示する事も考えているのでChromeの方が何かと都合が良いです。

　上記のような理由で、PC側のブラウザはChrome推奨としています。
　Safariでも使えなくは無いけれど機能制限あり。という方針で作ってます。

最後に

　SafariがWebRTCに対応したのがつい最近です。WebRTC(及びSkyWayの)Safari対応の資料や記事がまだまだ少ない状況なのでけっこう苦労しました。また、もっと良い実装方法もあるように思いますし、Safari側の修正や、SkyWayのSafari対応で変わっていく部分もあると思います。

　ただ、色々と試行錯誤した内容が残っているだけでも、これからWebRTC(SkyWay)を使ったスマホ向けサービスを作る人の参考になるかもしれないと思いましたので、書き残しておく事にしました。

何か気になる点がありましたら、コメントかTwitterの方に書いて頂ければと思います。

音声合成をボイスチャットで使う仕組みを作ってみました

グループ通話またはライブ配信する際に、チャット入力した文章を音声合成してマイクに流す仕組みを作ってみました。

基本的には、開発中のSkyBeje用に作ってみた仕組みですが、SkypeやDiscordの音声通話にも応用できると思います。

2020.04.30 追記 SlackやDiscordに応用する手順を書きました。

iwatendo.hateblo.jp

以下の３種類の音声合成を、ボイスチャットに使う仕組みを作ってみました。

・定番の音声合成ソフト「棒読みちゃん」
・株式会社エーアイのAITalk
・HOYA株式会社のVoiceText

 （注意）AITalk / VoiceTextについては、無料で試せるWebAPIを使いましたが、この２つは、商用利用禁止・二次利用禁止のWebAPIです。基本的には開発や検証目的として公開されているAPIとのことですので注意してください。詳細については、それぞれのWebAPIの利用規約を参照してください。

「棒読みちゃん」の音声をマイクに流す仕組み

棒読みちゃんの音声をマイク代わりに使う方法は、以下を参考にさせて頂きました。
棒読みちゃんをマイク代わりに使う : らいっちのPC奮闘記

棒読みちゃんのインストール方法や設定方法、仮想マイクデバイス（NETDUETTO）については、上記ページを参考にしてください。ちなみに上記ページはSkype用として説明されていますがDiscordにも適用できると思います。

SkyBejeとの連動については、棒読みちゃんの標準プラグインにある「クリップボード監視」機能を使ってみました。

SkyBeje側の設定

あとは、グループ通話のマイクデバイスに「NETDUETTO Driver」を選択します。

 ライブ配信する場合も同様で、マイクに「NETBUETTO Driver」を選択します。

これで自分のチャットの発言が、棒読みちゃんの音声でマイクに出力されるようになります。（ただし、他の人のメッセージの読上げはできません）

音声合成API(AITalk / VoiceText)を使ってボイスチャット

色々調べてたら、VoiceTextを再生できる棒読みちゃんのプラグインを作られている人がいました。（Voiceroid Talk Plusというプラグインも作っている人です）

Voicetext Talk Ver1.5.0.0:Wangdora Eve. - ブロマガ

最初、このプラグインでいけるかなと思ったのですが、プラグイン側で音声を標準デバイスに出力しているとの事で、棒読みちゃん側で設定したデバイスには出力できない仕様のようでした。

デバイス指定の他に、音声パラメータも指定したかったのでツールを自作しました。
github.com

詳細は上記のGitHubのページを見て貰いたいのですが、少しだけ補足です。

AITalk と VoiceTextには感情パラメータというのがあります。上記ツールではVoiceTextは感情パラメータを指定できるようにしたのですが、AITalkでの感情パラメータの指定方法が不明だった為、上記のアプリからは指定できません。(WebAPIからは指定できないのかもしれません）

他、SkyBejeは複数のアクターやアイコンを登録できて、切り替えながら発言することができます。アイコンごとに音声パラメータを設定できるようにしたので、喜んでいるアイコンに対しては喜んでいる音声パラメータを、怒ってるアイコンに対しては怒っている音声パラメータを設定するようなことができます。

現状の設定画面はこんな感じです。

チャット画面はこんな感じでアイコンを切替えながら発言できますが、同時に音声パラメータも切り替わって音声合成されます。 （右側はアイコン毎の音声パラメータです）

問題点や懸案事項

上記のプログラムを作る前から、AITalk / VoiceTextのWebAPIが「商用利用禁止」というは把握してたのですが、オープンソースとしてGitHubに公開するし、広告とかも入れないので、遊び用途なら問題ないと考えていました。

しかし、GitHubのReadMeを書くタイミングで、しっかりと利用規約を確認してみたところAITalk / VoiceText両方の利用規約に「無料でもウェブサイトに一般公開した場合は商用とみなす」的な記述があり、これは多分遊び用途で気軽に使っちゃダメなやつだ、と気が付きました（笑）

ただ、利用規約で曖昧部分もあって、判断に迷う部分があったので、そこは問合せてみようと思ってます。

また、これも後で気がついたのですが、Windowsのネイティブアプリの場合だと、APIキーの扱いに困ります。GitHubにコミットするソースにはAPIキーは含めないとしても、ビルド時にAPIキーをバイナリの中に含めてしまえば、逆アセンブルすればAPIキーが拾われてしまう可能性がありそうですし。。

上記のような問題もあって、個別にAPIキーを設定するようにしてるのですがAITalk（DocomoDeveloper Support）の場合は、サービスやアプリの単位でAPIキーを発行する感じで、個別に発行するようものでも無いようなんですよね。（VoiceTextの場合は、個人に対してAPIキーを発行している感じなのですが）

さいごに

と、まぁ色々と問題はあるのですが、ASP.NET用とか、社内で使うツールとかに応用できなくはないかもしれないと思い、プログラムはGitHubに置いておく事にしました。

最後まで読んでいただき、ありがとうございました。
ご質問やご意見がありましたら、お気軽にコメントしていただければと思います。

SkyWay Developer Meetup #1に参加してきました。

9月29日に上野で開催された、表題のイベントに参加してきました。
復習も兼ねて、各種資料やまとめのリンクを集めてみました。

以下、SkyWay Developers Meetup #1 で、発表時に使われたスライド資料です。

SkyWayの目指す世界

 SkyWayを使いこなすために

 LT : iOSでのSkyWay開発の勘所とTips

 LT : Skywayのビデオチャットを録画しよう。そう、ブラウザでね

 LT : SkyWay JS SDKの歩き方

以下のリンクから、LTの資料が見れます。
SkyWay JS SDKの歩き方

上記のLT発表者の leader22 さんのブログです。
Q＆A大会のメモも残ってて、素晴らしいです。

LT：SkyWay × cognitive service

感情が取れてる！ヽ( ･∀･)ノ #WebRTCSkyWay pic.twitter.com/adUYZE6mfE

— さっくる / Saki (@sakkuru) 2017年9月29日

Togetterまとめ

「SkyWay Developer Meetup #1まとめ」をトゥギャりました。 https://t.co/YBwP01U2Vn

— Yusuke Naka@SkyWay (@Tukimikage) 2017年9月29日

雑感

こういったイベントに参加するのは初めてだったのですが、非常に勉強になりましたし、良い刺激を受けました。SkyWayの開発者の方と直接を話をする事もできましたし、SkyWayを使ったサービスの開発者同士の繋がりも作れるイベントでしたし、もっと早くこういったイベントに参加すれば良かったな・・と、しみじみ思いました。

ちなみに私は岩手県に住んでますが、行く前は「岩手から参加するのは、きっと私ぐらいだろ～」とか思ってたのですが、他にも岩手から参加してる学生さんがいて、しかも立派にＬＴしてて驚きました。（内容も面白くて興味が湧くものでした）

次回も参加できそうであれば、是非また参加したいと思えるイベントでした。
ただ、時期にもよりますが、岩手から毎回行くのは色々と厳しい（笑）

前回のWebRTC Meetup Osakaでは、appear.inを使って、東京と大阪を繋いでたみたいですが、あんな感じで地方からも、もっと勉強会やイベントに参加できるようなったら嬉しいですね。

その為にも、もっとSkyWayを色んな人に知ってもらいたいですね。
同業者の知り合いに、私が作っているサービスを見せながら、SkyWay(WebRTC)を使うとこんな事ができるぞ～と布教はしているのですが、なかなか仕事には繋がりません。まぁ私が説明ヘタっていうのもあるのですが（笑）

その他、会場で頂いたSkyWayのシールをノートPCに貼ってみました。

中央のシールがちょっと斜めになってるのは、りんごマークを隠すように貼った為。
シールを貼る時に気がついたのですが、このロゴは空に道が続いてるのを表してるんですね。

さて、Meetupで刺激を受けてやる気が沸いてきたので、作ってるサービスの開発頑張ります！

SkyWayを使ったYouTube同期再生処理を実装

開発中のチャットサービスに、YouTubeの同期再生機能を実装してみました。

YouTube同期再生のテスト動画。ちょっと暗くてわかりづらいですが、３台のPCをSkybejeで繋いでいます。左上の一番小さなYouTubeの画面の操作で、各PCのYouTube動画が連動して再生・停止・シークしています。

YouTubeの同期再生テスト pic.twitter.com/g68k3zdLiF

— iwatendo (@iwatendo) 2017年9月14日

※テストに使わせて頂いた動画は、日食なつこさんの「水流のロック」です。YouTube動画の音は消してます。 

チャット時のBGMとして利用したり、オンライン家庭教師等やオンラインサポートのようなサービスでYouTube動画を使って説明したり、友人が接続したときにＭステの入場曲を流したりする用途に使用できればと思っています。

追記：YouTube Frame API は、基本的には商用利用禁止なようですね。
参考（YouTube商業利用のルール）

SkyWay + YouTube Player Api を使って実現してます。SkyWay(WebRTC)を使用するという事で、YouTube動画を再ストリーミングしている誤解する方もいるかもしれませんが、それぞれのクライアントが、YouTube動画サイトにアクセスしてます。再生する動画のURLや再生・停止情報をSkyWayのデータ通信で送り、疑似的に同期再生させています。

ざっくりとした処理の流れ

　・親ダイアログで、YouTube Player APIを使ってYouTube動画のイベントを拾う。
　・SkyWayのDataConnectionを使って上記のイベントデータをJSONデータで送る
　・各クライアントで、YouTube Player APIを使って同じ動作をさせる 

以下のようなYouTube動画の操作が同期できます。
　・再生開始／停止
　・再生位置の変更
　・再生速度の変更
　・ボリュームの変更（現状、Skybejeでは音量調整は未実装です） 

まだまだ問題点も多く、うまく同期しない場合があります。現状、親フレームのイベントを拾って処理してますが、きっちりと実装する前に、どういった動作仕様にするか悩んでて保留にしています。動作仕様は３パターンくらい考えていて 

（１）親のYouTubeフレームのでのみ操作可能、クライアント側は操作不可
　・現状はこの実装です。  

（２）親と全クライアントで操作可能にする。全ての操作を同期させる。
　誰か一人が停止ボタン押した場合、全クライアントの再生が停止するイメージ
　実装は面倒なのですが一応可能と考えています。エラー発生時の対応が難しそうですが・・。 

（３）表示開始のみ行い、動画の操作は各クライアント側で独立させる。
　　クライアント側は、動画が勝手に再生されるけど、後は通常通り

使うシーンによっても違うと思うので、親ダイアログ側のオプションで指定する方向でも考えてますが、シンプルにもしたいんですよね。。

以下のサイトから個人で開発中のサービスを試せるので良かったら試してみてください。

https://skybeje.net/　（PCのGoogle Chrome専用サービスです）

※YouTube Player APIはスマホだと自動再生できないらしいので、スマホ向けには同じような実装は多分できないと思います。