興味深い顧客
私は1〜2時間モニターの前に座った。 それはすべて、誰かのツイッターへのリンクから始まりました。私の同僚はそれをSkypeで親切に投げてくれました。 それから彼は誤ってニュースサイトを開いてからFacebookを開いたが、その間にもう2、3のニュースが表示された。 オフィスは涼しく、エアコンは静かに働きました。 私は通りの熱気に行きたくなかったので、まっすぐになったので、私は近くのコーヒーメーカーに足を踏み入れました。 レセプションのどこかでベルが鳴りました。
数分後、私はオルガがアジア系の紳士に同行しているのを見ました。 彼は約50を見た。 少ししわのある頭の上に、短いつばのある灰色の帽子が座っていました。 彼らは明らかに私のところに来ました。 カプチーノと一緒にグラスの中にすでにゴボゴボと音を立てているコーヒーマシンに追いついた紳士は、壊れたロシア語でこう言いました。 こんにちは、私はWebRTCプロジェクトに関連しています。 私の名前はすこなこで 、彼の手を差し出した。 この日本人をここに連れてきたのは、握手に応えて、ゲストを私のオフィスに招待したと思いました。 その後、英語に切り替える必要がありましたが、どちらも私たちにとってより理解しやすいものでした。
要件を収集します
私： それでは、どうすれば役立つのでしょうか？
C： 2000年以来、多数のユーザーを対象にストリーミングとFlexに取り組んできました。 Adobe Flash Media Server（FMS）を使用しており、WebRTCを使用したいと考えています。
私： WebRTCサーバーを使用して達成したいことについて詳しく教えてください。
C： 1人のユーザーからビデオストリームを受信し、他のユーザーに転送できる通常のメディアサーバーが必要です。 ビデオチャットが必要です。
私： 問題ありません。WebRTCサーバーの1つに基づいてソリューションを作成できます。
C： Adobe FMSはまったく問題ありません。 FMSを削除せずに、WebRTCでユーザーの輪を広げたいと考えています。 うまくいきます。
スコナコの手にタブレットが現れ、彼はそれを私に押して指を次の図に突っ込んだ。
C： Flexアプリは医者であり、Flexアプリは患者であり、医者はWebカメラを使用して、一度に複数の患者に相談します。 患者の1人は、医師からの個人的な相談を要求できます。その後、医師は、患者との個人的な相談に直面します。 この時点で、残りの患者は医者とコミュニケーションが取れず、医者に会えません。
奇妙な、私は思った。 医師が同時に患者に助言できること。 1つは耳が痛いという不満、2つ目は扁桃腺について不平を言ってから、扁桃腺で扁桃腺を圧迫し、個人相談モードに入ります。 ただし、原則は明確です。 私たちは問題の技術的な側面に焦点を当てています。
私： つまり その結果、医師と患者の間に双方向のビデオ接続が確立されますか？
S： そうでもない。 患者は常に医師の診察を受けますが、医師は患者の診察を受けない場合があります。 デフォルトでは、患者のビデオは無効になっています。
私： ビデオは一方通行です-医師から患者まで？
S： ほとんどの場合、はい。 しかし、患者は自分のビデオを医者に見せたいと思うことがあります。 これはめったに起こりません。
私： すべてが明確です。 そのため、医師と患者の両方が、FirefoxやGoogle ChromeなどのWebRTCブラウザと、FMSで動作するIEを使用できる必要があります。 そう？
S： ほぼそのとおりです。 すべての医師は、当社が開発したFlexストリーミングアプリケーションを使用しています。 患者は、当社のアプリケーションまたはWebRTCを使用する必要があります。
私： つまり 理想的には、アプリケーションは次のようになりますか？
そして、図をスケッチしました。
S： はい、そうです。 それはそのように動作するはずです。 一方はネイティブFlexアプリケーション、もう一方はWebRTCブラウザーです。 主に、AndroidスマートフォンとiOSデバイスのブラウザーに関心があります。 Flashはすべてのデスクトップブラウザ（IE、Chrome、Firefox、Safari）に何らかの形で存在することをご存知でしょうが、AndroidやiOSにはありません。 モバイルブラウザでサービスを利用できるようにし、デスクトップでうまく機能するもの、つまり FMS
私： WebRTCはAndroidブラウザーで動作しますが、iOSでは問題です。プラットフォームの制限により、iOSブラウザーのWebRTCは動作しません。 つまり iOSにWebRTCビデオストリームを配信することはできず、iOSブラウザーのウェブカメラからビデオをストリーミングすることはできません。
C： 待ってください。SafariはWebRTCをサポートしていませんが、Google Chromeではサポートされています。
私： はい、しかしiOSの場合はそうではありません。 そこで、Chromeはプラットフォームの技術的な制限につまずき、WebRTCビデオを操作するための機能はデスクトップと同じではありません。 つまり この場合のiOSブラウザは適切ではありません。 独自のアプリをApple App Storeにアップロードしてみませんか？ 次に、iOSユーザーは、アプリケーションをインストールして、Google Chromeで使用される純粋なWebRTCを使用するだけで済みますか？
S： 残念ながら、内部的な理由でアプリケーションをApp Storeにアップロードできません。 さらに、ユーザー（患者）に、iPhoneまたはiPadに追加のアプリケーションをインストールするのではなく、ブラウザーから直接作業する機会を提供したいと考えています。 どのようなオプションがありますか？
この時点で、アプリケーションがApp Storeで公開されるのを妨げる「内部の理由」について考えました。 おそらく、医療相談の分野は法律によって規制されており、この種のアプリケーションをApp Storeで公開するのはそれほど簡単ではありません。
実際には、多くのオプションはありませんでしたが、それらの最高のものはWebRTCをサポートするネイティブアプリケーションでした。 ご存じのとおり、iOS SafariはHLS（Apple HTTP Live Streaming）をサポートしていますが、このオプションは破棄されました。 医師と患者とのコミュニケーションでは、特定のリアルタイムおよびライブコミュニケーションが想定されていましたが、HLSは約20秒の遅れで完全に不適切です。
最後のオプションは残った：Webソケット。 Websocketは、ほぼすべてのブラウザでサポートされるようになりました。これは、実際にはRTMPに匹敵する遅延（20秒ではなく3秒）で動画を配信できるTCPチャネルです。配信では明らかです。 それでもこのストリームを<video /> HTML5要素で再現するには、すべてが素晴らしいでしょう。
私： オプションは1つだけのようです-websockets。 さらに、この場合、患者はビデオをサーバーに送信できません。 医師から患者への片道配達のみが可能です。 HLSを試すことはできますが、20秒以上の遅延があり、おそらくこれは機能しません。
S： いいよ。 iOS Safariブラウザで直接FMSでライブストリームを再生できることを正しく理解しましたか？ WebRTCなしで、RTMPに匹敵する小さな遅延があるとしますか？
私： はい、絶対に本当です。 しかし、しばらくこれを確認する必要があります。 同意して、月曜日に言ってみましょう。デモをお見せします。
S： iOSとAndroidで動作することを確認するために、WebRTCとWebsocketsと同時にFMSを統合する可能性を見たいです。 そうすることは可能ですか？
私： はい、すべてうまくいくと思います。
S：ご相談ありがとうございます。 月曜日に10に進みます。すべての問題を気にせずに話し合い、既にデモを行っています。
私： はい、もちろん、この頃にはすべてが準備できています。
私たちは解決策を探しています
会話からわかるように、要件が少し変更されたため、2つの配信方法をAdobe AMSに固定する必要がありました。AndroidブラウザーのWebRTCとiOSのSafariのWebsocketです。 このデモを構築し、それに関連するすべてのテクノロジーとプロトコルを接続できるようにするために不足している要素を見つけることは残っています。
日本人のゲストを訪問して、私が最初にしたことは、Adobe AMS仕様を見に行くことでした。 WebRTCとWebsocketという言葉を除いて、たくさんの興味深いものを見つけました。
さらに、ためらうことなく、Googleで必要な3つのキーワードrtmp、webrtc、websocketsを獲得しました。 Googleはいくつかの関連サイトを吐き出しました。 独自のFlashphonerプロジェクトと、 Phoboslab Webサイトのオープンソースプロトタイプの説明の2つのみが適切であることが判明しました。
最初の候補
私は、Phoboslabから始めることにしました。そこではiOS Safariでのストリーム再生の問題がすべての色で説明されており、オープンソースに非常に似たソリューションが提案されました。
このソリューションは、ffmpeg、node.js、およびクライアントjavascript上に構築され、ビデオストリームをデコードおよび再生します。 すべてのコンポーネントは本当にオープンソースであり、回路は有望に見えました。
仮想サーバーをDOに上げ、ffmpegをコンパイルし、node.jsをインストールしました。 これには約2時間かかりました。
iOS Safariのビデオは実際に再生され、ひどく再生されませんでした。 私のiPhone5は少しウォームアップしていましたが、JavaScriptはWebsocketからのビデオトラフィックを着実に押し出し、Webページに表示しました。
実際、ストリームはJavaScriptでデコードされ、iOS Safariブラウザーページ要素でレンダリングされました。 次の質問は未解決のままです。
-FMSでストリームを取得する方法
-ストリームにサウンドを追加する方法
-WebRTCはどうですか
そして、ここでいくつかの失望が私を待っていました。 JavaScriptプレーヤーはビデオを再生（レンダリング）するだけであることが判明しました。 オーディオの場合、追加のストリームを起動する必要があります。その後、何らかの方法で同期する必要があります。 しかし、この決定はこれを提供しませんでした。 したがって、このソリューションは、音声が不足しているため、医師からのビデオの送信には適していませんでした。
第二候補
次のテスト対象は、RTMP、WebRTC、Websocketプロトコルのサポートが約束されているWeb Call Serverです。 これらのプロトコルのサポートが私の特定のケースに適用可能かどうか、およびそれがどのように機能するかを確認することは残っています。
まず、以前のテストと同様に、RTMPビデオストリームのWebsocketへの変換を確認することにしました。 結局、これが成功した場合、RTMSストリームをFMSからWeb Call Serverにリダイレクトして、問題の1つを解決できます。
私はiPhoneで武装し、デモページの1つを開きました。これは、デモサーバーからこれを行うことを提案しました。 テクニカルサポートによると、Web Call ServerはLinuxシステムにすばやくインストールできますが、時間がかかり、デモにより、動作するかどうかをすぐに理解できるようになりました。
デモインターフェースは、Flash Streamingと呼ばれる気取らないデザインとシンプルな機能を備えた通常のFlashアプリケーションでした。
このFlashアプリケーションから、RTMPプロトコルを使用してサーバーに接続し、Webカメラからストリームを公開できます。 パブリッシュとは、Flash Playerを使用してブラウザのウェブカメラからビデオストリームをキャプチャし、RTMPプロトコルを使用してリアルタイムでサーバーにデータを送信することを意味します。
「接続済み」および「公開中」のステータスから判断すると、接続が正常に確立され、ウェブカメラからのストリームがサーバーに送信されました。 私の顔でストリームに映らないようにするために、仮想カメラと5番目（？）のGame of Thronesのシリーズを使用しました。
その後、SafariブラウザのiPhoneでこのビデオを視聴できます。 これを行うには、WS Player Minimalという別のプレーヤーを使用することをお勧めします。
プレーヤーは、歪みやrassynchronなしで、まともな画像とサウンドを得ることができました。
おそらく、私はレビューをある程度進めました。
- RTMP-Websocket Stream Deliveryをテストするための管理
- ストリームはサウンドとビデオで、Safariブラウザーで正しく表示されました
ストリームがWebRTCで再生されるかどうかを確認する必要があり、Adobe FMSとの統合に進むことができました。 WebRTCで同じストリームを確認するために、ChromeブラウザーでStreamer And Player Minimalデモを開き、ストリーム名を挿入して再生をクリックすることで、同様の簡単な手順を実行しました。
私の喜びは何だった、ハリシ！
現在、私の武器庫は、RTMPストリームをChromeに配信することでした。つまり、AndroidではWebRTC経由で、iOS SafariではWebソケット上で配信されます。 どちらの場合も、状況は非常に滑らかで、健全であり、コンサルティングサービスの展開に理論的に適しています。
次の質問はFMSでの作業でした。 RTMPプロトコルはすべての実装で同じであることは明らかですが、a）FMSがRTMPストリームをFlashphonerにリダイレクトできるかどうか、b）Flashphonerが上記のテストでFlashで受信したこのストリームを受け入れるかどうかを調べる必要がありました。
Adobe Media Serverとの統合
FMSをいじる必要がありました。 そのインストールとテストには数時間かかりました。 私が最初にしたことは、FMLEを使用してFMSをテストし、FMSを正しくインストールして構成し、RTMPビデオストリームが障害なく動作することを確認することでした。
次のステップは、RTMPストリームリダイレクトをFlashphonerに設定することでした。 ここで、私は少し頭を痛め、Action Scriptのアドビのドキュメントを手に入れ、そのようなスクリプトmain.ascを実装する必要がありました。
var wcsServer = "wcs5-eu.flashphoner.com"; var netConnections = new Object(); var streams = new Object(); application.onConnect = function (client){ trace("onConnect "+client.id); var nc = new NetConnection(); var obj = new Object(); obj.login = "Alice"; obj.appKey = "flashChatApp"; nc.connect("rtmp://"+wcsServer+":1935",obj); nc.onStatus = function(info){ trace("onStatus info.code: "+info.code); if (info.code=="NetConnection.Connect.Success"){ trace("connection opened "+wcsServer); } } netConnections[client.id]=nc; return true; } application.onDisconnect = function (client){ trace("onDisconnect "+client.id); var nc = netConnections[client.id]; if (nc){ nc.close(); trace("disconnected "+client.id); } } application.onPublish = function(client, myStream){ trace("onPublish "+myStream.name); var nc = netConnections[client.id]; ns = new NetStream(nc); ns.onStatus = function(info){ if (info.code == "NetStream.Publish.Start"){ trace("It is now publishing "+myStream.name); } } ns.attach(myStream); ns.publish(myStream.name); streams[myStream.name]=ns; trace("publish stream "+myStream.name+" to: "+wcsServer); } application.onUnpublish = function(client, myStream){ trace("onUnpublish "+myStream.name); var ns = streams[myStream.name]; if (ns){ ns.publish(false); trace("unpublished "+ns.name); } }
スクリプトは非常にシンプルで、FMSに含まれる接続とビデオストリームをFlashphonerサーバーに委任します。 たとえば、onConnectメソッドでアプリケーションから接続を受信すると、RTMPを介したFlashphonerサーバーへの接続が作成されます。
onPublishビデオストリームを受信すると、同じビデオストリームがFlashphonerに発行されます。
ストリームを切断および停止すると、対応する呼び出しがリソースを解放するように委任されます。 そのため、FRTとFlashphoner間のトラフィックがWebRTCとWebsocketsを介してさらに配信されるように転送されるブリッジを取得しました。
この構成をテストするために、すでにおなじみのFlash Streaming Flashインターフェイスを使用しました。 唯一の違いは、FMSサーバーのRTMPアドレスを指定してから、このFlashphonerビデオストリームを委任するmain.ascスクリプトに依存する必要があることです。 私の場合、このアドレスはrtmpでした：// my-fms：1935
テスト中に、FMSのAction Scriptとサーバープログラミングの無知からmain.ascサーバースクリプトをほとんど保護する必要がありましたが、これはすべて過去に残っており、その時点で動作しているスクリプトのバージョンは上記のリストにあります。 FMSは失敗せず、RTMPストリームを宛先に転送したため、ChromeおよびさらにSafariで正常に再生できました。
Web Call Serverをインストールする
その結果、デモの準備が整いました。 プレゼンテーション時の混乱を避けるために、Web Call Serverをシステムに配置することは残りました。 あなたは彼らが月曜日までそこに何ができるのか決してわかりません。
開発者のサイトでは、5つのポイントで構成されるインストール手順がありました。 SSL証明書のインストールに関する5番目のポイントは省略しました。 カメラとマイクからWebRTCストリーミングを使用する予定はありません。
- Web Call Server 5をダウンロードする
- 「install.sh」スクリプトを使用してインストールする
- 「service webcallserver start」を使用して起動します
- Webインターフェイスhttp：//ホスト：9091を開き、ライセンスをアクティブ化します
インストールはうまくいきました。 トラフィックの輻輳の問題を排除するために、テストサーバーでファイアウォールを慎重に無効にしました（service iptables stop）。
サーバーが起動してから1分後に、管理パネルhttp：// host：9091でWebインターフェースを開き、テストライセンスをアクティブにして、次のようなUbuntuでデモサーバーを取得しました。
追加のテスト実行により、回路が私の環境でも機能することを確認しました。 達成感を持って、私は就業日を完了し、スコナコの到着前の月曜日の9時にテストを再度確認するようにリマインダーを設定しました。
移行がどのように行われ、どのように終了したかについて、興味深い場合は、第2部で説明します。
使用するツールへのリンク：
- FMS（ Flash Media Server ）別名AMS（Adobe Media Server）-RTMPメディアサーバー。
- DO（ Digital Ocean ）-仮想サーバーのホスティング。
- WCS（ Flashphoner Web Call Server ）-WebRTC、Websocketメディアサーバー。
- FMLE（ Adobe Flash Media Live Encoder ）-サーバーとのRTMP接続を確認するためのクライアント。
- Phoboslabは、iOSのSafariでのWebsocketストリーミングのオープンソースプロトタイプです。