16:03<背景>十人程度の人数がディスカッションを可能なルームを作成しようと思っております。SFUモードを用いているのですが、7人程度以上になると、動作が不安定になるように思われました。負荷をさげようかと考えました。<発生現象>受信モードでpeer.joinRoomを実行すると、room.on("stream")が呼ばれない。よって、話している人のstreamが取得できず、音声の再生の方法がわかりません。room.on("peerJoin")は呼ばれているので、peerIdは取得できます。Windows7<期待される事象>受信モードでの、音声再生方法が知りたいです。いう仮定をもとにした質問となります。その仮定自体が間違いであればそれもご指摘いただけますと幸いです。)peer.joinRoom()の受信のみモード(Streamを指定しない)ですが、SFUで利用した場合、映像が表示されるまでに数十秒掛かるようです。SkyWayの不具合の可能性があるため、継続調査させて頂きます。ご報告ありがとうございます。受信のみモードを利用すれば、端末側の負荷を軽減できるため、参加者を増やすことは可能だと思います。受信のみモードを使わずに負荷を軽減する手立てとして、受信者のgetUserMediaの設定を変更し、widthとheightを最小サイズにし、且つ、ミュート処理を行うことで、同様の効果が得られるかもしれません。ミュート処理の一例ですが、以下のようにすることでオーディオトラックとビデオトラックのミュートが可能です。03:57ご返信ありがとうございました。07:02ミュート処理については、データ転送量を削減するために有効です。widthとheightを最小サイズにするという設定は、getUserMediaを実行する端末の負荷を下げるのに有効です。05:18getUserMediaをする際にaudioのみの指定にすれば音声だけは受け取れるようです。映像は重くて無理なんでしょうか・・・しかし、後から部屋に入ってきた人のstreamは受信のみモードの人はroom.on("stream")が呼び出されず音声のみでも受け取れないようです。01:46お世話になっております。このトピックと同じと思われる現象が発生した為、追記させて頂きます。後から参加したクライアントが、受信モードでpeer.joinRoomを実行すると、room.on("stream")が呼ばれない。rooom.on('stream')が呼ばれる様子。例)AさんがSFURoomで配信中、Bさんが受信モードで接続すると、Aさんの配信が表示されない。Cさんが接続すると、Bさんのクライアントで表示されるようになります。Cさんが受信モードで繋いだ場合は、Cさんのクライアントでは表示されない。発生すれば正常に表示されるようになる様子です。私の開発中の環境では暫定対応として、受信モードのSFURoomのOpen後、ダミーのPeerを接続(すぐに解除)する事で期待する動作となりました。)上記と似た現象で、こちらの環境ではSFURoomのstreamイベントは発火するけど、MediaStreamで映像が転送され始めるのが他クライアントが参加した後という感じです。SFURoomのopenイベントのコールバックで下記のような処理を呼び出してwork-aroundしています。04:36鶴谷さんのコメントを見て再確認した所>SFURoomのstreamイベントは発火するけど、MediaStreamで映像が転送され始めるのが他クライアントが参加した後という感じです。room.on("stream")の通知は来てました。様SFUに原因があるという所までは確認ができておりますが、まだ解決しておりません。開発者の皆さまからご投稿いただいている、ワークアラウンドで対処していただけますと幸いです。受信モードであれこれワークアラウンドしてみたのですが、結局うまくいかなかったので、双方向モードでやりとりをすることにしました。(どういう状況で「うまくいかない」のか把握するまでには至りませんでした...)ですが、双方向モードでも「streamイベントは発火するが、mediastreamが転送されない」(=ビデオが真っ白)という状態が起きました。この問題にも、鶴屋様のワークアラウンドで対処できました。似たようなものですが、もし同じ問題で困っていらっしゃる方がいた場合、以下のコードをお使いいただければ解決すると思います。Roomに参加した際に、映像が表示されない不具合を解消致しました。こちらのスレッドに記載のあるワークアラウンドは不要になりました。修正までお時間がかかり申し訳ございませんでした。Permalinkログインしてコメントを残してください。