codesこの広告は、90日以上更新していないブログに表示しています。これからどうなっていきそうかについて、自分の理解している範囲で書いてみます。議論などの公開情報を元に書いてるだけなので、間違っているものや、将来変わるところも有ると思います。よって内容は一切保証しません。何か自分の理解がおかしいところなど有った場合は、コメントなどで指摘頂けると幸いです。テレビ会議」をするというユースケースを中心として策定されました。まじめに触ると「ユースケースを外れた途端の使いにくさ」が少なからずありました。文字列であるために、変更したい場合は文字列処理が必要であったり、通信相手ごとに映像のクオリティを分けることができないなどの問題が指摘されています。ラップされているため、それら個々のプロトコルレベルで細かい制御ができないという問題も有ります。セット」の上で再構築という流れになるのは、このブログでも何度か言及した通りです。輪をかけて色々と濃い感じになってます。勧告されることは基本的にはあり得ません。方向性について議論が進んでいます。何が起こって行くのかを見てみたいと思います。張るという方法があります。上に二本のストリームを多重化できればリソースを節約できます。対応した形で定義されています。対してストリームを追加するメソッドです。このメソッドを呼んで終わりとはいきません。対してストリームの追加を通知する必要があります。取得し直してシグナリングしなおします。発火し、そこで追加のストリームを取得できるわけです。タグに表示など}このフローを使うと、ストリームが追加されてない状態から順次ストリームを追加して行くこともできます。無視されている場合もありますが、本来はこのイベントが「シグナリングを実行すべきタイミング」です。ストリームの追加を途中で扱うためにはこのフローを行うことになります。間で、このフローがうまくいかないことがあるということです。複数ストリームの存在を示すラインが追加されます(m-line)。いうフォーマットの二種類があります。間で行おうとすると失敗する場合があります。書き換える方法があります。これを行うライブラリもすでに提供されています。実装待ちとなるでしょう。ストリーム(MediaStream)レベルの多重化な訳ですが、より細かく制御したい場合は、これだと粒度が大きすぎる場合があります。具体的には、ストリームは複数のトラック(MediaStreamTrack)からできているため、そのトラックレベルで制御をしたい場合です。トラックが両方入ったストリームです。多くのトラックを追加できます。このトラックレベルでのネットワーク上の扱いをそこまで細かく指定することができませんでした。追加されることで解決します。サイマルキャスト多拠点で会議をして受信側が複数人いた場合、それぞれのネットワーク状況や受信している端末は同じとは限りません。上の画面の小さいモバイル端末だった場合は、あまり嬉しくありません。解像度とフレームレートを下げたものを送ってくれた方が快適な場合があります。本来であれば、受信者の持つ表示能力やおかれている帯域状況に応じて、適切なクオリティの動画を配信したい。一つの動画を複数のクオリティで配信する。これがサイマルキャスト(Simulcast)です。サイマルキャスト(サイマル放送)を調べると全然違う意味で載っているように、一言でサイマルキャスと言ってもコンテキストによって意味が変わります。ここで言っているのは、テレビ会議などで使われるサイマルキャストです。あれば、一旦サーバで配信者の動画を受け取り、それを個々の受信者に合わせたパラメータに変えて、再エンコードをするという方法があります。これは再エンコードにかなりのリソースが必要な上、受信者によって必要なパラメータの組み合わせも非常に多くなってしまいます。遅延の問題も無視できません。基本的なアイデアは、動画を複数のレイヤに分けてエンコードすることです。元となる映像をベースとなる低解像度・低フレームレート・低ビットレートなパラメータでエンコードします。これを基本レイヤーと呼び、全員に配ります。加えて、基本レイヤとの差分となる拡張レイヤをエンコードします。ようなものだと考えるとわかりやすいでしょう。映像のレイヤを把握し、クライアントに配信する際に対象の表示能力や帯域状況に応じて、必要なレイヤだけを流してやります。受信者が低帯域にある画面の小さいモバイルだった場合は、基本レイヤ(解像度/フレームレート/ビットレート)のみを受けとります。一方で、受信者が十分な帯域のある大画面のテレビ会議システムだった場合、基本レイヤに加えて二つの拡張レイヤを受けとり、デコード時にマージすることで高クオリティ(解像度/フレームレート/ビットレート)の映像が手に入るわけです。その中間のスペックの受信者は、基本レイヤに加えて一つ目の拡張レイヤだけを加えることで、中クオリティの映像を手に入れることができます。基本レイヤは、最低限会議は成り立つというレベルのものであり、クオリティが低い変わりにデータも小さくなっています。代わりにエラー訂正などについては他のレイヤよりも重視します。拡張レイヤが壊れたり落ちたりしても基本レイヤがあれば最低限の映像は見えるため、そうした場合は基本レイヤにフォールバックしてリアルタイム性を確保します。データの少ない基本レイヤのリカバリにだけ気を使って入れば、ネットワークが不安定になっても、低クオリティへのフォールバックによって会議を続けることができるなどのメリットもあります。映像を犠牲にしてオーディオに優先度を振ることで、会議を快適にすることができます。違い、エンコードを配信元クライアントが一回だけ行えばよく、サーバのリソースも節約できるため、効率のよいテレビ会議を構築するためには非常に有望な技術なのです。エンコード時に注目するパラメータは大きく三つあります。フレームレート(Temporal)解像度(Spatial)画質(Quarity)フレームレート(Temporal)フレームレートは一秒間に表示する画の数です。拡張レイヤを加えるとフレームが増え、動きが滑らかになります。解像度(Spatial)解像度は単位面積あたりの画素数です。拡張レイヤを加えると大きな画面でもはっきり映ります。言われる場合もあるようです。いわゆる画の鮮明さです。いうと必ずと言っていいほど出てくる図があります。この図だけ見ても分かりにくいかもしれませんが、ざっくり言うと各ブロックがオブジェクトで、横の矢印が依存関係、縦がイベントとなっています。ここに出てないオブジェクトもまだあります。ここまでの話を踏まえつつ少し細かく見てみます。いうオブジェクトが諸々よしなにやってくれるのという感じでした。その時ブラウザが内部で行っていた個々の操作をオブジェクトにしているイメージです。スタックを理解できていると、レイヤリングされているプロトコルがオブジェクトとして抽象化されているだけだと言うことが良くわかるかと思います。トラックを一つだけ交換してみます。生成は以下のような感じになります。意識されていませんでした。今後どうなるかは後述するとして、レイヤが低いという意味はなんとなく感じて頂けたかと思います。情報の一部が含まれています。文字列を生成することができます。定義されたため、こうしたことが可能になった訳です。ブランチに入ってたので、参考にしてみてください。作り、トランスポートに紐づけることができます。取得してシグナリングを行います。増やしていけば良いという意味です。具体的には以下のような形で指定します。}];ざっくり言えば、個々のレイヤのパラメータと、そのレイヤの依存関係の指定になっています。一般の開発者にはなかなか敷居が高いかもしれません、逆にコーデックやネットワークの状態の把握にノウハウがあると、その知見をここのパラメータに反映することができます。来る可能性があります。しまくってる訳ですが、エディタがよくわからないフローで更新しているようで何とも言えません。挙動の定義は割とキチンと書けているので、単にエディタがプログラミング苦手なだけだかなと思います。一部が実装されたと発表されました。持って無い筆者はまだ試せていませんが、もし持っていたら是非試してみてください。して使えるようになるのではないかと見ています。どちらも日本で連続して開催されます。先日シアトルで開催されました。テーマになり、主要なエンジニアが発表をしています。チームの発表が参考になります。http://www.slideshare.net/webrtclive/kranky-geek-google-teamこの辺の話を総合すると、今後の流れとして抑えておくべき点として以下が上げられると思います。して次の仕様に取り組みたい。ある程度実現してから、残りの策定作業をする必要があります。要望が強く対応が急務になっていると見ることができそうです。考えて行きたいという話。ベースにもう一度立て直すという感じかな。したいのは、もうこれの延長で話しても限界が近いという雰囲気じゃないかと思う。やろうとしていることが複雑なので、本気でやるとしたらこのくらいフックポイントがあっても良いだろうと思います。同様、フレームワークなどが成熟することで、開発者が必要に応じて選ぶかたちになっていくでしょう。求められている重要な機能だということだと感じるし、じっさい標準化の場面でも非常に話題になっています。取って一つの重要な転換期になるでしょう。実装も進むことが予想されます。呼ばれていたものに繋がって行くのではないかと思います。使ったサービスの品質向上につながるでしょう。一部を使い、これまで前提となっていた「テレビ会議」というユースケースに縛られない、全く予想外な使い方による何かが出てくると、面白いのではないかと思います。あるなぁという話でした。インフラ構築力くらいの知識が平気で必要になります。この総合格闘技を一人で戦い抜くのもいいけれど、正直それができる人を俺は知りません。エコシステムで作るものだと思うので、全部一人で抱えるよりは、得意な人が得意な分野を開拓して、補いながら作り上げていく方が全体としては成長するんじゃないかと思います。自体が、己の自重で沈んでしまうでしょう。こんなエントリでも、そのサイクルを回す一助となればと思います。指摘頂いたタイポや誤訳などを更新しました。誰のものでもありません。#nextwebconf月別アーカイブリンクhttps://jxck.iohttps://github.com/jxckhttps://twitter.com/jxck_http://mozaic.fmはてなブログをはじめよう!Jxckさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。