SkyBeje開発記スマートフォン用の表示で見るSkyBeje開発記SkyWayを使ったブラウザ間通信アプリを開発していますこの広告は、90日以上更新していないブログに表示しています。2018-02-15ChromeのIndexedDB(2.0)に、限界までデータを登録してみましたIndexedDB開発しているサービスでIndexedDBを使用しているのですが、現状のChromeの場合、どのくらいまでの容量を登録できるのか、また限界までデータ登録した場合、どのような動きになるのか不明だった為、検証してみました。2.0とはブラウザに実装されているデータベースです。(日本語訳)IndexedDBに限界までデータを登録してみましたIndexedDBに、大容量データを登録できるサイトを作成して検証しました。https://skybeje.net/indexeddb_limit_test/一応ソースはGitHubに置きました。https://github.com/iwatendo/Indexeddb_limit_testこんな感じです。エラーハンドリングについてのメモ上記を作っていて、気がついた点のメモです。・データ登録できなかった場合、DBRequest側のエラーは発生しない。・データ登録できなかった場合、DBTransactionの「onAbort」が呼ばれる。DBTransaction.errorに「QuoteExceededError」がセットされます。・一定容量を超えると、IndexedDBにデータ登録できなくなる。・IndexedDBに登録できるデータ量は、環境によって変化する。・1つのサイトで限界までIndexedDBに登録しても、他サイトに影響は無い様子。検証内容の詳細ストレージの容量が関係するらしいので、4台のPC(うち一台はタブレット)で、ストレージを確認しつつ検証しました。最初に登録したサイトの12GBのデータは残ったままで、合計24GBのデータ登録できことになります。念の為Dドライブを外して試しましたが結果は同じでした。Toolsで確認しようとすると、以下のようなメッセージが表示され、ブラウザがクラッシュする場合があるようです。※メモリ8GBのPCに、128MB×50件=6.4GBのデータを登録して確認した時に発生。IndexedDBの保存先についてのメモWindowsの場合、以下の場所に保存されるようです。Chromeで開発していますがその場合の保存先は、以下の場所になるようです。C:\Users\(ユーザー名)\AppData\Local\Temp\vscode-chrome-debug-userdatadir_9222\Default\IndexedDB※数値部分は環境によって変わるかもしれません。IndexedDBの手動削除について前述のフォルダの下に、更にサイト毎にフォルダが生成されます。http(s)_(URL)_(port番号).indexeddb.leveldb一定サイズを超えるバイナリ(ArrayBuffer等)の場合は、blobに保存されます。blobデータが消えない現象が発生しました。仕方ないのでChromeを落とした状態で、手動でフォルダ(.leveldbと.blobの両方)を削除してみたところ、特に問題なく削除できました。推奨はできませんが、同じような現象が発生した場合に、手動で削除してみても良いかもしれません。さいごにIndexedDBに大容量のデータを登録しても大丈夫かな?という漠然とした不安があったのですが、今回の検証で、まぁ大丈夫そうという印象になりました。他のブラウザでは検証してないですが、少なくてもChromeの場合は安定動作する感じです。いうわけで、今後もIndexedDBをガンガン使っていきたいと思います。Toolsで確認できるようになったみたいです。21:58ChromeのIndexedDB(2.0)に、限界までデータを登録してみましたTweet広告を非表示にするもっと読むコメントを書く2018-02-09SkyWayでChromeのバックグラウンドタブからのデータ送信が遅くなる現象についてSkyWayはじめに表題の件について、現象は以前から認識していたのですが、ブラウザ側の問題と認識していて保留にしてました。(@TK11235)さんが開発している、ユドナリウムでもデータ送信速度が遅くなる現象が発生する様子で、ちょっと気になったので原因を調査してみました。1.1.5データ送信(DataConnectionのsend)が遅くなる原因についてブラウザ側の仕様で、バックグラウンドタブの「setInterval」のウエイトが、最低1000msになるのが原因のようです。Lab.)skyway.js内でデータ送信する際に「setInterval」を使用している箇所があります。ウェイトは1msを指定しているようなので、通常は数ミリ秒で送信されますが、バックグラウンドタブからの場合に、1秒間に1回しかデータがsendされないようです。そのため連続sendした場合にデータが溜まり、重くなるようです。現象が発生する具体的なケースユドナリウムの場合、プレイヤー間でPeer接続する場合に各種データを送信しあうと思うのですが、Peer接続される側のバックグラウンドタブ(または最小化状態)の場合、データ取得が少し遅れるようです。実際にユドナリウムを2つ開いて接続する事で、現象を確認できます。(接続される側に、画像やチャットメッセージを少し登録して試すと体感できます)2つともフォアグラウンドタブの場合すぐに相手側のチャットメッセージが表示されると思います。接続される側(右側)がバックグラウンドタブ(または最小化状態)の場合チャットや画像が接続元(左側)に表示されるまで、約2~3秒掛かります。秒数的に、左側から右側のタブへ3回程sendしていると思われます。ちなみに私が作っているサービスでは、もっと遅延を発生させる事ができるのですがPC1台で再現させる手順が若干複雑なので省略します。解決策案についてSkyWay側の問題というより、ブラウザの仕様の問題とは思うのですが、skyway.js側で、なんらかの対策を入れて貰うと嬉しいので、対策を開発者コミュニティの方にお願いしてみたいと思います。追記:SkyWayの開発者コミュニティでお願いした所、回答を頂けました。SkyWay側でサポートするのは難しいとの事ですが、対策方法等を教えて頂けました。私が実施した対策も書いてあるので、この問題で困った場合は、以下も参考にしてみてください。08:52SkyWayでChromeのバックグラウンドタブからのデータ送信が遅くなる現象についてTweet広告を非表示にするもっと読むコメントを書く2018-02-07SkyWayの利用可能ドメイン指定とlocalhostでのデバックについてSkyWayはじめにSkyWayを使ったWebサービスを開発する際に、SkyWayのコンソールで「利用可能ドメイン」を指定すると思いますが、私は暫くドメインを跨いでの接続はできないと勘違いしていました。ドメインを跨いで接続できる事により、様々な方法でデバックできる事に気が付いたので、今回はその事について書きます。SkyWayを利用した通常のWebサービスの動作イメージはじめに、SkyWayを使ったWebサービスの動作イメージの簡単な説明をします。各端末がWebサーバにアクセス。HTMLやJavaScriptを取得。各端末がSkyWayのサーバーにアクセス。各端末のブラウザを繋げます。ブラウザ間で通信します。※実際にはもっと複雑ですが、大雑把にはこんな感じだと思います。ローカルホストでの開発について開発時はローカルにWebサーバーを立てて、利用可能ドメインに「localhost」を指定して、開発するのが一般的だと思います。同一端末内でブラウザを2つ立ち上げ、ローカルWebサーバーにアクセス。各ブラウザがSkyWayのサーバーにアクセス。ブラウザ間を繋げます。ブラウザ間で通信します。複数端末で、各自のローカルWebサーバーを使用してのデバックここからが、私が最初気付かなかったデバック方法です。各端末が同一のAPIキーを指定していれば、それぞれのローカルWebサーバーのlocalhostに接続した状態でも、ブラウザ間で通信ができます。ブラウザ間で通信この方法だと、Webサーバーを準備しなくても、複数端末を使ってのデバックが可能です。通常はこういったデバックが必要になるケースはあまり無いかもしれませんが、複雑な実装のデバックをする場合に、役に立つ事があるかもしれません。ドメインを跨いでの接続SkyWayのコンソールの「利用可能ドメイン名」に、複数のドメインを指定すると別々のドメインにアクセスしたブラウザ間でも、通信が可能です。オンライン家庭教師のようなサービスを作る際に、生徒側がアクセスするドメインと、先生側がアクセスするドメインを別にするといった実装が可能です。生徒側のUIと、先生側のUIを、それぞれ別の形でも実装できます。前述のドメインを跨いで接続できる事を応用してローカルホストと、Webサーバー間での接続もできます。アクセスは許可しない方が安全だと思います。※私は上記の形でデバックする場合、テスト用のWebサーバーを使用しています。最後にこういった内容の記事を見かけた事がなかったので書いてみました。SkyWayを使ったサービスを開発している方や、今後SkyWay使ったサービスを開発してみたいと考えてる人のお役に立てれば幸いです。何か気がついた点がありましたら、コメントかTwitterの方に連絡頂ければと思います。08:30SkyWayの利用可能ドメイン指定とlocalhostでのデバックについてTweet広告を非表示にするもっと読むコメントを書く2017-11-23SkyWayでSDPを覗いて対応Codecを確認してみました。SkyWay先日書いた記事の追記になります。端末毎のCodecの確認方法についてSDPで判断できます。いう情報をTwitterで頂きました。APIリファレンスを確認してもSDPが確認できそうな関数が見当りません。確認してみると「offer」や「sdp」のワードで大量にヒットします。SDPを確認できる事がわかりました。スクリプトのどの箇所のSDP確認するのが最適なのか判断できなかったのですが以下の2箇所にコンソール出力処理を追加して確認してみました。offerMessage");console.info(offerMessage.offer.sdp);※作ったサービスはMeshRoomを使っている為、上記の箇所で確認しましたがSFURoomやPeerで直接の場合だと、別の箇所で確認する必要があると思います。Nexus9※DevToolsでMobile側のConsoleログを確認しています。Chromeの対応Codecが表示されていると思われます。Nexus9の対応Codecが表示されていると思われます。OfferMessageのSDP)H264の表記のみ。Safariの対応Codecが表示されていると思われます。エラーメッセージの出力されていました。PC側(Safari)側では、Video/AudioのSDPメッセージ出力はされていませんでした。結論SDPの読み方は理解していないのですが、予想どおりSafariはH264のみ対応だけれども、Nexus9はH264に対応していないため動作しないという事で合ってそうです。改造が必要になりそうです。skyway.jsはオープンソースなので、きっちり改造してプルリクを出してみたりしても良いのかもしれません。(私はそこまでやれるスキルと自信が無いですが)とりあえず、未対応Codecの場合はエラーが発生するようなので、skywayのエラーを拾えるようであれば拾って、未対応端末と表示する方針にしようかなと思っています。最後にSafariのWebRTCがH264にしか対応しないと聞いたときは、よく分かってなかったのですが、色々とやっかいですね。現状だと、iOS端末とAndroid端末で、モバイル端末のブラウザ間でビデオ通話する場合は、Android端末がH264に対応している必要がありますが、AndroidはブラウザではH264に対応できない端末が多いらしいです。私はスマホアプリの開発経験がなかったりするのですが、スマホ対応は色々考えることが多く、更には機種差分もあったりして難しいですね。全部ブラウザだけで実現できたら良いのですが、現状なかなかそうもいかないようです。何か気になる点等がありましたら、コメントかTwitterの方に書いて頂ければ嬉しいです。08:31SkyWayでSDPを覗いて対応Codecを確認してみました。Tweet広告を非表示にするもっと読むコメントを書く2017-11-21SkyWay(WebRTC)を使ってスマホとPCでビデオ通話するサービスを作った時にハマった箇所のメモSkyWay少し前に、iOS11のSafariがWebRTCに対応したので、iPhoneでのWebRTCの動作検証も兼ねて、前から作ってみようと思っていたSkyWay+GoogleMapのサービスを作ってみました。現場から中継お願いします!~パソコンで上記のページを開いて、QRコードをスマートフォンで読み込むと、パソコンとスマホでビデオ通話ができます。同時にスマートフォン側の位置が、GoogleMapで表示されます。現状は機能的にシンプルな感じですが、気まぐれに機能を拡張したいきたいと思っています。地図表示は調べれば大量にサンプルがあるので問題無く作れましたが、iPhoneでビデオ通話する部分の実装は結構苦労しました。作っていてハマった箇所と、それに対して実施した対策、未解決の問題について書いていきたいと思います。最初に・GoogleMapについては詳しく書く必要は無いと思われるので省略します。・私はWebRTCの深い部分の知識は無く、SkyWay頼みで作っている感じです。同一デバイスでの複数のMediaStreamAndroid(Chrome)の場合、一つのデバイスを複数のMediaStreamに利用できました。iPhone(Safari)の場合:一つのデバイスを複数のMediaStreamに利用できない様子。}の2つのMediaStreamを作ってました。(そもそもこの方法が非効率?)以下のように修正したところ、動作するようになりました。1つだけ作成しプレビューと送信用の両方に使用するようにしました。(プレビュー用のVideoタグには、mutedを付けました。MediaStreamConstraintsの指定SkyWayJSの話になりますが、MeshRoomにJoinRoomする際に、Audioのみを指定していると音がでませんでした。(今回の作ったサービスは1対1の接続なのでMeshRoom使わなくても良いのですが、楽したい為にMeshRoom使ってます。Peerで直接繋ぐと大丈夫かもしれません。)対策として、使わなくてもVideoを指定する事にしました。}この件については、SkyWayの開発者コミュニティに同様の問題の報告が上がっています。VideoとAudioを使ってる人と、Audioだけの人が混在すると上手く動作しないケースがあるようです。最初はスマートフォン側にはパソコン側の映像を表示しない方針で作っていたのですが、ダミーでvideoを送るくらいなら、映してしまおうと思い方針を変えました。Audioタグを使った場合、Volumeを変更しても音量が変わりませんでした。そのためiPhoneの場合は、WebAudioを使うようにしてみました。WebAudioも、Android(Chrome)とiPhone(Safari)で挙動が違うようです。Androidの場合はVideo/AudioタグのVolumeで音量調整ができていたので、Safariの場合のみWebAudioを使う実装にしました。気になる点として、iPhoneの場合はハードウェアキーでの音量調整ができません。画面上のスライドバーでのみ音量調整が可能な状態です。追記)iOS11.2で、Video/Audioタグを使った場合でもハードウェアキーで音量調整ができようになったようです。時にエラーが発生し、プレビュー画面が表示されないケースが頻発しました。確認してみると、MediaStreamError(name="TrackStartError")が発生していました。エラーが発生している原因は不明なのですが、何度かリトライすると成功する感じなので、1秒毎にリトライ(5回まで)する事で対応しました。デバックして確認すると1~2回のリトライで成功する感じでした。アプリ内ブラウザ(WebView)での挙動LINE等のアプリから起動すると、標準ブラウザではなくアプリ内ブラウザ(WebView)で起動されます。その場合にgetUserMediaが動作しないケースがあるようです。getUserMediaが無いというエラーが発生。・AndroidのLINEの場合、権限が無いというエラーが発生。※Androidの場合は起動できるアプリもあるようです。SafariのWebViewは、getUserMediaは未実装らしいですし、Androidの場合は、各アプリ毎に権限の設定がされていてユーザー側からは変更できないと思います。しようも無いので、getUserMediaに失敗した場合は「標準ブラウザを起動してください」と表示するようにしました。iPhoneのフリーズiPhoneにてパソコン側から送られてきた映像をピンチアウト(2本の指での拡大)等をしてVideoタグがディスプレイの幅からはみでた場合に、iPhoneがフリーズする場合があります。(iOS側のバグと思われます)この件については、SkyWayの公式サイトにも記述があります。https://support.skyway.io/hc/ja/articles/236202427作っているサービスは、PC側から送られる映像は小さく表示していたので、暫くこの問題に気がつきませんでした。何度かフリーズさせてみた感じでは、PC側の映像の動かない状態で、左側にVideoタグがはみ出た場合に、フリーズする可能性が高いように感じました。仮想Webカメラ(MenyCam)を使ってテストする事が多いのですが、MenyCamの初期画面の場合にフリーズしやすい感じでした。スマホがフリーズしてしまうのは流石に致命的な問題なので、暫定対応として拡大/縮小ができないようにしました。この問題が完全に修正されるまで、怖くてサービスの公開はしづらい気がします。修正されたとしても、iOSのバージョンチェックして、古いバージョンは弾くような実装にしないとまずい気もします。追記)iOS11.2でフリーズする不具合が修正されたようです。端末ごとの対応Codec以下の4パターンのうち、最後のパターンはPC側に映像が表示されませんでした。×これについてはコーデックの問題ではないか予想し、試しにMeshRoomの接続オプションで'H264'を指定してみたところ、パターン2とパターン4で表示されなくなりました。この事から、Nexus9がH264のエンコードに対応してないのでは?と思っています。(safariのWebRTCは、H264しかサポートしてないらしいです。)裏付けをとりたいのですが、対応端末がH264のエンコードに対応しているかわかる資料や、確認する為の方法を見つけることができませんでした。可能であれば、JavaScript上でチェックできるようにしたいです。追記:時雨堂のVさんからコメント頂きました。SDPで確認できるとの事です。Vさんありがとうございました。"対応端末がH264のエンコードに対応しているかわかる資料や、確認する為の方法を見つけることができませんでした。いう文字列がなければ非対応と判断が可能です。追記2:上記について確認してみました。Safariでのデバイス名称取得についてマイクやカメラのデバイス名称の取得する為に、navigator.mediaDevicesを使用しているのですが、safariは未対応で名称取得できないようです。仮想マイク(NETDUETTO)を使いたいので、デバイス名称は表示したいんですよね。現状、スマホで別のアプリに切替えて戻ってきた時に、パソコン側の映像が消える場合があります。数十秒待ってると表示されるようになります。これについては、対策をこれから考えようと思います。未解決の問題について未解決の問題1と2については、PC側はChromeを使えば問題無いです。Windowsユーザーの場合はSafariは利用できないですし、MacユーザーでもChromeは使えます。Safariは現状スクリーンシェアに対応していません。PCのスクリーンシェアをスマホに表示する事も考えているのでChromeの方が何かと都合が良いです。上記のような理由で、PC側のブラウザはChrome推奨としています。Safariでも使えなくは無いけれど機能制限あり。いう方針で作ってます。最後にSafariがWebRTCに対応したのがつい最近です。WebRTC(及びSkyWayの)Safari対応の資料や記事がまだまだ少ない状況なのでけっこう苦労しました。良い実装方法もあるように思いますし、Safari側の修正や、SkyWayのSafari対応で変わっていく部分もあると思います。試行錯誤した内容が残っているだけでも、これからWebRTC(SkyWay)を使ったスマホ向けサービスを作る人の参考になるかもしれないと思いましたので、書き残しておく事にしました。何か気になる点がありましたら、コメントかTwitterの方に書いて頂ければと思います。08:57SkyWay(WebRTC)を使ってスマホとPCでビデオ通話するサービスを作った時にハマった箇所のメモTweet広告を非表示にするもっと読むコメントを書く2017-11-06音声合成をボイスチャットで使う仕組みを作ってみましたSkyBejeグループ通話またはライブ配信する際に、チャット入力した文章を音声合成してマイクに流す仕組みを作ってみました。基本的には、開発中のSkyBeje用に作ってみた仕組みですが、SkypeやDiscordの音声通話にも応用できると思います。以下の3種類の音声合成を、ボイスチャットに使う仕組みを作ってみました。基本的には開発や検証目的として公開されているAPIとのことですので注意してください。詳細については、それぞれのWebAPIの利用規約を参照してください。「棒読みちゃん」の音声をマイクに流す仕組み棒読みちゃんの音声をマイク代わりに使う方法は、以下を参考にさせて頂きました。棒読みちゃんのインストール方法や設定方法、仮想マイクデバイス(NETDUETTO)については、上記ページを参考にしてください。ちなみに上記ページはSkype用として説明されていますがDiscordにも適用できると思います。SkyBejeとの連動については、棒読みちゃんの標準プラグインにある「クリップボード監視」機能を使ってみました。Driver」を選択します。Driver」を選択します。これで自分のチャットの発言が、棒読みちゃんの音声でマイクに出力されるようになります。VoiceText)を使ってボイスチャット色々調べてたら、VoiceTextを再生できる棒読みちゃんのプラグインを作られている人がいました。ブロマガ最初、このプラグインでいけるかなと思ったのですが、プラグイン側で音声を標準デバイスに出力しているとの事で、棒読みちゃん側で設定したデバイスには出力できない仕様のようでした。デバイス指定の他に、音声パラメータも指定したかったのでツールを自作しました。github.com詳細は上記のGitHubのページを見て貰いたいのですが、少しだけ補足です。VoiceTextには感情パラメータというのがあります。上記ツールではVoiceTextは感情パラメータを指定できるようにしたのですが、AITalkでの感情パラメータの指定方法が不明だった為、上記のアプリからは指定できません。(WebAPIからは指定できないのかもしれません)他、SkyBejeは複数のアクターやアイコンを登録できて、切り替えながら発言することができます。アイコンごとに音声パラメータを設定できるようにしたので、喜んでいるアイコンに対しては喜んでいる音声パラメータを、怒ってるアイコンに対しては怒っている音声パラメータを設定するようなことができます。現状の設定画面はこんな感じです。チャット画面はこんな感じでアイコンを切替えながら発言できますが、同時に音声パラメータも切り替わって音声合成されます。VoiceTextのWebAPIが「商用利用禁止」というは把握してたのですが、オープンソースとしてGitHubに公開するし、広告とかも入れないので、遊び用途なら問題ないと考えていました。VoiceText両方の利用規約に「無料でもウェブサイトに一般公開した場合は商用とみなす」的な記述があり、これは多分遊び用途で気軽に使っちゃダメなやつだ、と気が付きました(笑)ただ、利用規約で曖昧部分もあって、判断に迷う部分があったので、そこは問合せてみようと思ってます。これも後で気がついたのですが、Windowsのネイティブアプリの場合だと、APIキーの扱いに困ります。GitHubにコミットするソースにはAPIキーは含めないとしても、ビルド時にAPIキーをバイナリの中に含めてしまえば、逆アセンブルすればAPIキーが拾われてしまう可能性がありそうですし。Support)の場合は、サービスやアプリの単位でAPIキーを発行する感じで、個別に発行するようものでも無いようなんですよね。(VoiceTextの場合は、個人に対してAPIキーを発行している感じなのですが)さいごにと、まぁ色々と問題はあるのですが、ASP.NET用とか、社内で使うツールとかに応用できなくはないかもしれないと思い、プログラムはGitHubに置いておく事にしました。最後まで読んでいただき、ありがとうございました。ご質問やご意見がありましたら、お気軽にコメントしていただければと思います。#1に参加してきました。SkyWay9月29日に上野で開催された、表題のイベントに参加してきました。復習も兼ねて、各種資料やまとめのリンクを集めてみました。発表時に使われたスライド資料です。Skywayのビデオチャットを録画しよう。以下のリンクから、LTの資料が見れます。Q&A大会のメモも残ってて、素晴らしいです。#1まとめ」をトゥギャりました。雑感こういったイベントに参加するのは初めてだったのですが、非常に勉強になりましたし、良い刺激を受けました。SkyWayの開発者の方と直接を話をする事もできましたし、SkyWayを使ったサービスの開発者同士の繋がりも作れるイベントでしたし、もっと早くこういったイベントに参加すれば良かったな・・と、しみじみ思いました。ちなみに私は岩手県に住んでますが、行く前は「岩手から参加するのは、きっと私ぐらいだろ~」とか思ってたのですが、他にも岩手から参加してる学生さんがいて、しかも立派にLTしてて驚きました。(内容も面白くて興味が湧くものでした)次回も参加できそうであれば、是非また参加したいと思えるイベントでした。Osakaでは、appear.inを使って、東京と大阪を繋いでたみたいですが、あんな感じで地方からも、もっと勉強会やイベントに参加できるようなったら嬉しいですね。その為にも、もっとSkyWayを色んな人に知ってもらいたいですね。同業者の知り合いに、私が作っているサービスを見せながら、SkyWay(WebRTC)を使うとこんな事ができるぞ~と布教はしているのですが、なかなか仕事には繋がりません。私が説明ヘタっていうのもあるのですが(笑)その他、会場で頂いたSkyWayのシールをノートPCに貼ってみました。中央のシールがちょっと斜めになってるのは、りんごマークを隠すように貼った為。シールを貼る時に気がついたのですが、このロゴは空に道が続いてるのを表してるんですね。#1に参加してきました。読者になる検索リンクはてなブログブログをはじめる週刊はてなブログはてなブログPro最新記事ChromeのIndexedDB(2.0)に、限界までデータを登録してみましたSkyWayでChromeのバックグラウンドタブからのデータ送信が遅くなる現象についてSkyWayの利用可能ドメイン指定とlocalhostでのデバックについてSkyWayでSDPを覗いて対応Codecを確認してみました。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。