ブラウザからのビデオ通話の記録:1週間で記録されることを望みました

旅の初めに、ボクシムプラントクラウドプラットフォームにより、音声通話のみで作業することができました。 しかし、進歩はまだ止まっておらず、時間の経過とともに、ビデオ伝送、テキストメッセージ、プレゼンス、その他多くの機能が追加されています。 そして、最近ビデオ録画機能の開発を終了しました。ビデオコール中に、javascriptコールマネージャーから記録機能を呼び出して、録画したビデオファイルへのリンクを取得するだけで十分です。



クライアントにとっては、すべてが非常にシンプルに見えて動作しますが、このタスクは思ったほど簡単ではありませんでした。 多くの技術的な問題を解決し、適切に機能するソリューションを作成するには、弱い開発者から遠く離れた数か月かかりました。 アンダーカット-コーデック、ファイル形式、webRTCとの闘いの物語。



ビデオ通話は異なります。 トレンディなwebRTCテクノロジーを使用して、ブラウザーから呼び出すことができます。 ブラウザが古く、技術が搭載されていない場合は、フラッシュにロールバックできます。 ブラウザをまったく使用せずに、電話プログラム、いわゆる「Sipソフトフォン」を使用できます。 SIPサポートのある物理的なビデオ電話をインターネットに接続し、それを介して電話をかけることができます。 インターネット経由でモバイルアプリケーションを呼び出すことができます。具体的には、ios、android、react nativeのSDKがあります。



これらすべての方法は、SDPプロトコルの使用によって統合されています。ビデオコールに関係する当事者は、ビデオの解像度、使用されるコーデック、およびコールの編成に必要な他の多くのことに同意します。



コーデックの課題



コーデックは異なります。 SIP電話機は、何に対しても同意を試みることができます。 フラッシュの場合、これはh.264です。 しかし、webRTCにとって、このストーリーは非常に興味深いものです。 webRTCの標準化委員会は、どのコーデックがプロトコルに必須であるかについて長い間戸惑っていました。vp8は特許料を必要としませんが、h.264はすべての冷蔵庫にあります。 最終的に、彼らはこの問題について口論し、コーデックを実装するために両方を必須にしました 。 そのため、事実上webRTCはVP8を使用しているという事実にもかかわらず、H.264のサポートは標準で指定されており、ある程度の配布が行われる可能性があります。



問題は何ですか? 奇妙なことに、コンテナがあります。 発信者がどのコーデックに同意するかは事前にはわかりません。 さらに、通話中にビデオのオン/オフを切り替えることができます。 すべてのコンテナが同じように役立つわけではありません。ほとんどのコンテナでは、ライブラリではビデオのコーデックをすぐに指定する必要があります。これは、録画時にはわかりませんでした。 また、顧客はビデオを最も一般的なコンテナで提供したいと考えており、ブラウザとの互換性が良好であることを望んでいます。 また、ビデオを再生するときのブラウザは、可能なすべての組み合わせをサポートしていません。 たとえば、ほとんどのブラウザはVP8ビデオコーデックでmp4を再生できません。 また、ビデオコーデックとオーディオコーデックの "失敗"の組み合わせについても話していません。



私たちが見つけた最も簡単な解決策は、ビデオと音声を中間ファイルに記録し、その後、目的の形式に変換せずに変換することでした。 データは、未加工ファイルとコンテナの両方に書き込むことができます。 協議した後、mkvコンテナを使用することにしました。必要なすべてのコーデックをサポートし、他の形式に簡単に変換できます。



ビデオ録画



最初に、私たちは最も単純な方法で、ビデオを操作するための事実上の標準ライブラリ、偉大で強力なffmpegを使用しようとしました。 しかし、現実はしばしば野心的な計画を調整します。 同じ名前のコンテナを記録するためのmkvモジュールは複雑であることが判明しました。 いいえ、そうではありません-それはCOMPLEXです。 あまり成功していないAPIとの闘いに数日間を費やし、Google検索で多くの未回答の質問を研究していたので、戦術を変えて代替品を探し始めました。 遠くまで行く必要はないことがわかりました。mkvチームのlibmatroskaは使いやすく、すぐに使用できます。



結果は、次のアーキテクチャです。



  1. クラウドで実行されるクライアントJavaScriptは、設定「{video:true}」を指定してcall.record()メソッドを呼び出し、ビデオを記録します。
  2. サーバーはmkvファイルを作成し、コールの対応する参加者(存在する場合)のビデオと、コールの参加者ごとに1つずつの2つのオーディオトラックを記録します。
  3. javascriptが記録開始のイベントにサブスクライブしている場合、対応するコールバックは記録されたファイルのURLから呼び出されます(これについては後で説明します)。
  4. 呼び出し後、mkvファイル内のトラックを分析し、使用するコーデックに応じて.mp4またはwebMに変換するPythonスクリプトが実行されます。 サウンドトラックは、選択した1つ、ステレオまたはモノに結合されます。 ステレオの場合、通話の最初の参加者の音声は左のステレオチャンネルに配置され、2番目の参加者の音声は右に配置されます。
  5. 結果のファイルはAmazonにアップロードされ、以前に発行されたURLで利用可能になります。 URLのファイルには拡張子がありません(記録の開始時点ではわからないため)。そのため、そのタイプはHTTPヘッダーのフィールドによってMIMEクライアントに渡されます。




Habrのボーナス



私たちが愛しているオープンソースは、javascriptとwebrtcです。 通話の記録に多くの時間を費やしたため、コミュニティと共有することができ、共有する必要があります。 特にhabituraについては、mkvビデオを数行のコードで記録するために作成したc ++ライブラリをgithubに投稿しました。 したがって、同様の問題に直面した場合は、ベストプラクティスを活用して時間を節約できます。 このライブラリは、MITの公式リポジトリにあるライセンスの下で入手できます



結論



最初は、ビデオレコーディングを数週間で「テープ」にしたかったのです。 数ヶ月で判明しました。 なぜこれが起こるのですか? ソフトウェア開発業界の急速な発展は、テクノロジーの急速な変化と膨大な数の狭い専門分野の出現をもたらしました。 したがって、計画時に、チームに専門のスペシャリストがいない場合、ニュアンスを考慮せずに真剣に「ミス」する可能性があります。 アジャイルアプローチでは、技術的に複雑なプロジェクトを計画する前に一連の実験を実施して、テクノロジースタックが正しく機能し、大きな驚きがないことを確認することをお勧めします。 実際、これは最初の週にやったことです-ビデオを録画するためのさまざまなライブラリを調べ、データでそれらをチェックしました。 しかし、慎重にレイアウトされたストローでさえ、開発の後期の段階で常に驚きから救われるとは限りません。 私たちにとって、そのような驚きは、ビデオを一時停止する機会、パケット損失、その他の微妙なニュアンスでした。 結局のところ、ビデオコールの作成は、カメラからのTCPストリームよりもはるかに困難です。



私たちが作成したビデオコールの録音は、最初に試してみた顧客に好印象を与え、すでに「改善と拡張」のアイデアを送ってくれました。 作成されたアーキテクチャがどのようにタスクに適しているのかを見てみましょう。6か月以内に「ビデオ録画をどのように編集したか」という記事を書かないことを望みます。 また、近い将来、「ネイティブ」コンテナだけでなく、一度に両方に変換することも計画しています。 もちろん、計算能力の負荷は増加しますが、顧客は録画されたビデオを最新のブラウザーで再生できます。



記録されたビデオ通話のサンプルである10メガバイトのファイルは、 ここからダウンロードできます






All Articles