2018」が開催されました。PCやモバイル等、あらゆるデバイスでのトラフィックが増大している昨今。インターネット上で流通するコンテンツがリッチになっていく中でより重要度が増しているCDNに用いられている最新のテクノロジーや事例を紹介します。ベストプラクティス」をテーマにプレゼンテーションを行いました。ベストプラクティス」と題してお話をさせていただきます。Managerと呼ばれるRoleとして、お客様から有償のサポートサービスのご契約をいただいて、お客様ごとに技術的なサポート、コンサルティングをさせていただいています。動画業界だけではなく、いろいろな業界のお客様を担当させていただいているのですが、今回は動画関係にフォーカスし、皆様の業務の1つにお役立ていただける知識を1つでも持って帰っていただけたら幸いです。本日のアジェンダです。インターネットを通して動画配信を行う場合には、Encodingに気をつけていただくことがあると思います。そこに関する1つのベスト・プラクティスについてお話しさせていただきます。その後、4K配信の現在。その次は、低遅延を実現するためにどのようなところに気をつけるべきか。次にQUICへの弊社の取り組みについて話をさせていただき、最後のおまけで簡単な宣伝をさせていただきます。Practiceのお話しをさせていただきます。Practiceというマニュアルを公開しています。その中の式を1つ紹介させていただきます。RateとMotion_Factorと呼ばれる1つの係数を本式に当てはめることで、ベースとなるBitrateを算出することができるようになります。アクション映画やスポーツ中継のように、動きの激しい動画であれば、Motion_Factorをできるだけ小さくしたBitrateを使用することで、効果的なBitrateとなります。本式を活用することで各動画に対して、より効率的なBitrateの基準を算出することができるのです。動画といっても一概に同じBitrateがすべての動画に対して最適とは限らないのです。アクション映画のような非常にモーションが大きいものであったり、ドラマのような室内の暗い映像が多いものもあるので、各動画に対して大きいBitrateが必要かどうか、一度気にしてみるといいかもしれません。Netflix社が調査した例を挙げさせていただきます。Netflix社は100個の動画を1つの1080Pサイズの映像ソースで、一定のクオリティパラメータに固定し、Bitrateのみを変えて、Encoding結果の品質をPlotした調査結果を公開しています。品質はPSNR(ピーク信号対雑音比)と呼ばれる、ノイズがどれぐらい入っているかという動画の品質評価指標のもと、評価した結果になります。グラフの縦軸がクオリティを示すPSNR、横軸がBitrateです。結果を見ていただくとわかるのですが、1つのBitrateを取って見ても、Bitrateを上げたからといって、必ずしも動画品質が向上するという結果にはつながらないことがわかります。ladderを組むことを検討することがユーザにとって効果的か、ということがグラフからもわかると思います。ladderを組めるのかということにフォーカスして考えてみます。ひとつの例を紹介させていただきます。現実的に配信したい映像サイズをピックアップします。その次に、一定のQualityではなく、はっきりと違いがわかるQualityレベルのパラメーターを設定いただき、Encodeした上で動画の品質評価を行います。それを、先ほどのグラフのように(PSNRの測定結果を)BitrateからPlotしていきます。ladderが組めるようになります。実際にグラフに書いてみます。今回の場合、いくつかResolutionの中でも、720×480、1280×720、フルHD(1920×1280)の3種類のladderを考えたとします。そこでいくつか評価してみると、まず720×480で動画の品質をBitrateで評価した場合、このような(グレーの曲線の)Plotになります。次にHDとフルHDです。Hullと言うのですが、そこを組もうとすると、実際にこのような赤文字のラインが組めることがわかります。ladderを組むことが非常に有効だとわかります。Ladderとなります。いえ、みなさん業務の中で動画を1つしか使っているわけではなく、多種多様なタイトルを扱っていただいているので、タイトルごとにやるのは非常に手間だと思います。実際、先ほどの8個のRenditionを決定するのに14回もEncodeが必要になっています。ladderを検討することが現実的にとれる効果的な改善策かと思います。Bitrateを算出することで、その動画の複雑さを測ることができます。ladderを組めばいいのかという動画カテゴリ内での1つの指標にすることができます。ladderの適用例と動画の評価指標BITMOVIN社が出していた適用例のデータを紹介させていただきます。ladderを、先程紹介したやり方で組み、実際に動画の品質を評価した結果となります。Bitrateを下げつつ、PSNR・動画品質を向上させることができたという結果が出ています。今のEncodingのやり方について、少しサマリをさせていただくと、今回はPSNRという指標でご紹介はさせていただきましたが、動画の評価指標はほかにもいろいろと出てきています。現在はSSIM、VMAF(Netflix社が提唱、gitに公開)なども出てきていて、みなさんのサービスで配信されている動画も、そのような品質評価指標をどこまでされているのか、あらためて振り返っていただけたらと思います。見直しをすることによって、ユーザーがより快適に、もっと高品質な動画を視聴することができるかもしれません。ここに示されているPSNRやSSIM、VMAFはあくまで動画全体のAverageの評価指標が出てくるので、すごく変化の少ない映像だけれども、一部急に映像が激しくなったりするようなのもありますので、やはり最後に主観評価していただくことも重要になってきます。今回のやり方を1つの方法として捉えていただいて、自分たちが配信している動画の品質は、果たして最適なBitrateで作成されているかということをぜひ見直していただけるといいかなと思います。次に、今回のタイトルにもなっている4K配信についてお話をさせていただきます。4Kの配信のテストは日々行われています。こちらは総務省が定期的に出しているデータの一部ですけれども、各社TV局といろいろな試みしています。TVやモニタをお持ちの方はどれくらいいらっしゃいますか?(会場挙手)......2名。本日出席されているみなさんはわりと動画業界の方々とは思うのですが、意外と手が挙がらないところを見ると、やはり4Kデバイスの普及は、まだまだこれからなのかなという印象を受けます。2年前に某テレビ局様で聞いたときには、誰も手が挙がりませんでした(笑)。今回は2人手が挙がったということで、少し普及が進んできたのかなと思います。今、私が申し上げたとおり、4Kのテレビはなかなか普及が進んでないのが現状です。VoDではサービスとして、さまざまなコンテンツが4Kで用意されているのですけれども、ユーザー環境という意味では、そこまで整ってきていません。いうと、1つ考えられるとしたら、やはりエンドユーザー側の帯域が用意できていないということがあると思います。今だと、20Mbps程度必要になってしまいます。Liveをイベントなどで使う分には非常にいいのですが、これからもっと普及させるためには、やはりH.256(HEVC)であったり、VP9、AV1などの高圧縮のコーデックの準備がどうしても必要になってきます。Viewingなどでは効果的に使えます。Hybridcastを使って、ユーザー体験をどんどん上げていくような試みをすることで、4K映像をよりリアルに感じていただくために必要になってくる施策なのかなと考えています。先ほど申し上げた、帯域についてですが、H.264での4K配信は非常に帯域を必要とします。VP9はどうだろうということで少し確認してみると、4KだとH.264の21.2Mbpsに対して、VP9は17.3Mbpsまで抑えることができます。フルHDになってくると、逆にH.264のほうが圧縮効率が良い部分もあったりするので、安易にコーデックを全部切り替えると判断するのは、なかなか難しいかと思います。現状の「ゴールデンタイム」に、日本のISPはどれぐらいスピードが出てるのかというところですけれども、一番帯域が出ているISPでも4Mbps程度しか出ていません。考えると、せっかく高いお金を出して買った4Kのテレビで、結局観れないという話になってしまうので、なかなか悔しい結果なのかなと思います。今後の高圧縮なコーデックは非常に重要な役割もっていると思います。4K配信に欠かせない、エンコード技術「HEVC」の現状ではまず高圧縮コーデックの中でも、HEVCにフォーカスして見ていきます。supportが進んでいないのが現状です。ハードウェアの対応や処理できるチップも必要になります。一部のIEやSafariでは動くようになっています。Sierraでも動くようになっています。インターネットサービスプロバイダが提供している限られた帯域の中で、HEVCの効果はどうでしょうか。H.264だと720pのResolutionでしか提供できない帯域でが、H.265(HEVC)を使うとフルHDで視聴できるようになります。8Mbpsの帯域が見込める場合はどうかというと、8MbpsではフルHDが限界です。2Kのものでもまだ配信するには足りないというのが現状のHEVCの圧縮効率です。同じフルHDでもH.264よりH.265のほうが動画のノイズは少ないということがVMAF評価値からわかっています。フルHDまでのResolutionにおいて、より圧縮効率を高めたい、より高品質な動画を配信したいということであれば、H.264からHEVCへ移行する価値は高いのかなと思います。H.264とH.265で同じResolutionにて、それぞれ画質評価を行ったところ、H.265はH.264の結果を上回るという結果が見られています。deltaというのは、Netflixが提唱している画質評価指標で確認したもので、6以上差が付いたものは、人間の目で見て明らかに品質が上がっていると感じられるレベルです。非常に小さいResolutionほど画質の評価が高いということですので、とくにモバイルユーザーには、良い効果が見られるのかなと思います。いえ、HEVC使用時の負荷はどうなのか、気になると思います。devicesで調べると、やはり若干のCPUの負荷の上昇が見られるそうです。全体的に見ると劇的にCPU負荷が上がるわけではないので、とくに問題はありません。これらの結果が出ているのに、なぜHEVCの対応デバイスがもっと加速していかないのか気になると思うのですが、みなさんご存知のとおり、HEVCはDecodeに対するRoyalty料もSubscriptionとPPVに対するRoyalty料も定義されています。このようなこともあって、意外とみなさんから「乗り換える気がない」という回答をしています。動画業界の方々がどのようなプランをお持ちかというと、AV1やVP9はもう少し情報が整って実装されることを待っているという結果も出ています。今後、AV1がHEVCに対抗するコーデックとして成長してくるのではないかということが、現状見られる業界全体のトレンドなのかなと考えています。MediaへApple社も加入しているので、またハードウェア対応の加速が期待できます。知られていないのかなと思うのですけれども、AV1の圧縮効率の評価はどうなのかというところです。こちらはモスクワ大学が調べた評価になります。真ん中右にあるH.264のEncodingを100パーセントした場合に、どれぐらいBitrateを抑えることができるかという圧縮率が縦軸のパーセンテージになるのですが、AV1は約半分程度まで抑えることができるようになります。こちらは非常に革新的な圧縮効率の良さだと思います。左から4番目のVP9でも、72パーセントの圧縮効果が見られています。AV1はVP9をさらに超える高圧縮なコーデックとして、期待できそうです。早く現場に出てこないのかというと、AV1はまだ専用ハードウェアチップが開発されていないので、全部ソフトウェアでの処理が必要です。このような試験をやるときも、Encoding自体は全部ソフトウェアでやっているので、普通にハードウェアでEncodingをやるよりも、数千倍時間がかかってしまうということがあるので、実用的ではないというのが現状です。VP9とAV1のサポート体制VP9はどこまでサポートされているかというと、Googleが軸足になって開発していたものなので、Browser側の普及は早いですけれども、Apple側は対応していません。それに対して、当然ですがAV1の公式サポートブラウザはまだありません。Canaryでは、すでにAV1のdecodeが実装されています。BITMOVIN社はサンプルのAV1の動画を置いていますので、実際に同じぐらいのBitrateの動画との品質の違いを体感いただくことができます。現状のAV1の開発ステータスです。Freezeに至っていないというのが現状です。5月31日に至ってもまだドラフトの状態となっています。当初、2019年にはモバイル向けのデコード用の専用チップ等が出てきて、AV1はデファクトスタンダードに成長していくのではないかと言われていたものの、若干開発が遅れることも考えられます。いうことで、4K配信の部分のサマリです。4Kの配信については、各社がCodecの検討含め、いろいろなチャレンジをしているという現状です。業界の方がこれだけ集まっていても、4Kが視聴できるデバイスがそこまで大きく普及していないところもあって、これから4Kの普及を進める為にも4Kの価値を高めていくことが重要だと考えています。4K配信を本格的にやりたいとなった場合、やはり高圧縮なコーデックを検討する必要があります。現状だとVP9やHEVCが選択肢に上がると思うのですが、AV1はデファクトスタンダードに成長する可能性が非常に高いと思われます。HEVCのRoyalty料も非常に高く、当社もビジネスモデルが古いのではないかと言われていますので、今後このビジネスモデルも変わっていくのではないかと思います。主要なブラウザであるFirefoxやChromeなどで日々AV1の準備が進んでいる状態です。YouTubeとNetflixは「AV1を押していく」と宣言しているので、そのようなところにも注目だと思います。Mediaに入っているので、デバイス等の普及も進むかと考えています。参考までに、Akamaiの取り組みをご紹介します。我々は配信側なので、どのようにコーデックが選択されるかはそこまで気にしていません。我々が今取り組んでいることは、もう少し先のところです。VRになってくると、8Kレベルのものを配信していかないといけないという課題があります。そのような課題に対して、TILEDMEDIA社と協力して、8K画質の多角的なものをどれぐらい、どのようなフォーマットで配信するのがいいのかというところも含めて、頭を悩ませて日々検証させていただいているところです。低遅延配信を実現するために次に「低遅延配信を実現するために」です。高画質なものを配信したいけれども、やはりLiveになってくると、遅延も気になるものだと思います。最近の遅延は小さくなっていく推移が非常に早くて、数年前までは、インターネットでLive配信する場合、45秒〜1分ぐらいは遅延するものがみなさん常識と思っていたと思います。去年の暮れぐらいからは、20秒〜30秒ぐらいで配信できないと、インターネットの配信としては納得してもらえる品質ではないという状況になってきています。Live配信のフォーマットがどのように変わってきたかというと、当初はAdobeが出していたRTMPが主流でした。そのときはインターネットを介していても、3秒〜5秒の遅延が主流でした。DASHに変換する取り組みです。HTTPに特化していくことで、CDNによる配信効率を上げたり、視聴できる環境を広げたかたちになります。それによって若干遅延が伸びてしまったという現状もあります。それに対して、WebSocketを使って、さらに遅延を縮めようと試みられた部分もありますし、HLS/DASHではSegment長を縮めることで6-8秒遅延での配信を実現しています。最近では、1対1の通信であれば、WebRTCという話も最近出てきています。今はエンドユーザーの選択肢として、配信のやり方はこれだけあります。出力フォーマットの比較という意味では、やはりいろいろと差分はあります。低遅延を実現するためのポイント8つでは、どうすれば低遅延にできるかというベストプラクティスを1つずつ見ていきたいと思います。若干当たり前のことを書いているとは思うのですけれども、今一度あえて1つずつ見ていきます。Encoderでの遅延を減らすことが重要です。Encoderでの遅延は、意外と気にされてない方もいらっしゃるのではないかと思うので、こちらについてはまた後ほどお話しします。offを取ることが重要になります。Durationを小さくすることも重要です。今では2秒でもStableに配信できます。1秒になってくるとPlayerなどの視聴環境側でいろいろとチューニングが必要になってきます。インターネットを通して配信するので、Ingestするところの遅延も気にする必要があります。Ingestを受けるClusterをできるだけEncoderの近く設置し、Ingestすることが重要になってきます。CDNでの転送時間をできるだけ短くしましょう。こちらは我々の取り組みなのですけれども、CDN内ではできるだけ高速に確実な配信が実現できるよう設計されています。Mileの部分では、RTTをできるだけ短くする必要があります。server)をできるだけエンドユーザーの近くから配信することも重要になってきます。Latencyでの再生が実現できます。Rate)の動きをチューニングすることでそのリスクをより小さくする必要があります。TransferによるCMAFセグメントの利用を検討することも1つのやり方としてあります。最後に非常に重要な部分です。Latencyとはいえ、配信が止まってしまっては元も子もないので、冗長化構成を組むことが必要になります。(MSL4)では、Akamaiのプラットフォーム内はすべて冗長化されています。今だと2msで、約10秒ぐらいの遅延で配信することができます。内部のプラットフォームは500ms以内にすべて切り替わるように設計されていますので、非常に強固な配信プラットフォームとしてご利用いただくことが可能です。言え、遅延はどこを目安として見たらいいのかということを挙げさせていただきます。mile、最後のPlayerの部分と見たときに、10秒セグメント、トータル50秒ぐらいの遅延で配信するときに、これぐらいの内訳で考えていただければいいのかなと思います。2秒セグメントのときはどうなのかというと、トータル11秒ぐらいということで、これぐらい縮まります。これよりも大幅に外れる部分があれば、チューニングの余地があるということで、先ほど申し上げた部分を再度見直していただくことでより低遅延の配信が実現できると思います。先ほど少し申し上げた、Encoderの部分について、どう設定すべきかという1つの見解をお話しさせていただきます。HLSの場合、弊社側でサポートしている2秒セグメントでやってみましょう。Manifestに含めるChunk数は3とします。HLSの仕様に即さずに思い切ってしまうのであれば、2つに縮めることもできます。Rateを使っていらっしゃるのかなと思うのですが、その場合にKeyframeを挿入する間隔を30にしておく必要はなく、60にしておくことで2秒のセグメントの中に1つのKeyframeを挿入する形になります。このKeyframeを入れる処理は、Encoder上では負荷が高い処理になるので、入れるタイミングをセグメントごとに1回で済ませると、処理速度が改善される可能性があります。Latencyで出したいということであれば、こちらを思い切ってOffにすることで恩恵を得ることができるかもしれません。Bitrateを見直してください。そのようなBitrateが含まれていると、Encoderの処理が重くなりますので、そのようなものをできるだけ排除することが重要になってきます。Bitrateの小さいStreamを作ろうとすると、より圧縮を頑張るEncoderは負荷が大きくなります。1つ上げるとすれば、あえてBフレームを使用しないということです。Client側でのPのdecodeには、最初のIとBのデータが両方必要になりますので、decodeの処理待ち時間をできるだけ短くする意味だと、あえて予測の入っているBフレームを使わずに配信してしまうのも1つの手です。Offになるケースもあります。打ち上げようとした動画がどれくらいの画質になっているか。今までやっているものに対して、どれくらい差があるのかを見極めていただきながら、Encoderの設定をどうするのか検討していただく必要がありますので、ご注意をお願いします。LiveにおいてQUICはどこの段階から必要になるか次は、LiveにおいてQUICはどこの段階から必要になるかという話です。mileの環境が悪ければ悪いほど効果があって、使っていただくのはもちろんベターなのですが、どこから必須となるかという観点でお話しします。これはTCPの再送制御の視点からのお話です。10のTCPの再送処理タイマ(RTO)の初期値は3秒です。再送を繰り返していくと、ネットワーク環境は非常に悪いと判断され、再送時間タイマはどんどん伸びていきます。すると、プレイヤー側のBufferは2秒chunkだと6秒、1秒chunkになると3秒しか持てません。RTOが3秒しかない場合、1秒chunkだと再送するまでにRebufferingが発生して、破綻してしまいます。2秒chunkの場合には必須ではないけれども、1秒chunkのときには必須になってくるということが1つの見解として挙げられます。2秒chunkの場合でも、Manufestに含めるBufferの数を3つではなく、2つにしていく場合には、このようなQUICの取り組みが非常に重要になってくるのかなと思います。contributionの恩恵を受けることで、よりスタートアップタイムが早くなります。このあたりを実験していただくこともできる環境は整ってきていると思いますので、ぜひお試しいただければと思います。みなさん30秒から45秒のLatencyのところにいる必要はなくて、DASHのパススルーでも2秒セグメントで配信することで、15秒〜18秒ぐらいまでいけます。CMAFを使ったり、HLS/DASHの1秒セグメントを使うことで、10秒を切るようなLatencyも実現することができますので、ぜひみなさんぜひトライしていただければと思います。サマリとしては、小さいセグメントサイズは、Latencyを下げるのには有効です。有効なのですけれども、プレイヤーの動きのチューニングは必須になります。縮めれば縮めるほどBufferingのリスクは上がりますので、プレイヤーはうまくハンドリングできるような実装が必要になってきます。スタートアップを縮めるためには、このようなポイントが必須になってきます。今後、CMAFへの取り組みにも積極的にトライしていただきたいですし、最近はWebRTCなども出てきています。今は1対1の通信の話がメインで取り組んでいると思うのですけれども、1対多にスケールできる話になってくると、非常におもしろくなってくるのかなと思います。Latencyを実現する際にも、冗長化は必須になります。最後にQUICの話を少しさせていただきます。みなさんご存知の方は多いかと思うのですが、もともとTCPレイヤーの上でHTTP/2で通信をすることで、配信をしていたのですけれども、そこの再送処理や効率的に配信する部分の話を、全部QUICのレイヤーでやってしまおうということがQUICの取り組みの概要になります。Architectのエンジニアが実際にQUICの一部のDraftを執筆中です。mileの部分でQUICが使えるようになってきています。ここをUDPの通信にして、できるだけ早くエンドユーザー様にデータを転送することによって、より低遅延で効率の良い配信をしようというのがQUICの取り組みになります。QUICが出てきたかというと、Connection確立のオーバーヘッドであったり、転送の順番が詰まってしまうという問題があったりましたので、それらの問題を解決するためにQUICが出てきてたという流れになります。QUICでも使われているChromiumというプロジェクトのコードをベースにしています。IETFの会合でいろいろと決まったことがあると、Chromiumのコードが更新されますので、Akamai側のコードもそのたびに順次アップデートされています。QUICもIETFで定義されているQUICに向かっていきます。Akamai側でQUICを動かす条件はGoogle社と違うところがあります。Optimizationチームがおり、そこのチームがどの条件でQUICを動かすかを詳細にチューニングしています。AkamaiのTCPは非常に高速で、すごくうまくチューニングされています。Akamaiからの配信の場合、QUICだから単純に高速通信ができるようになるわけではありません。Akamaiが使っているTCPは高速なので、UDPのQUICを使ったほうが早いと判断したときにだけ、UDPのQUICを動かすような処理を目指して日々チューニングを行っています。逆に、UDPが使える状況でも、TCPじゃないと効率が落ちてしまうような場合には、TCPを優先して使うような判定を目指しています。現状の予定では、7月16日より一部Akamaiの配信Solutionにて、プラットフォーム側で自動的にQUICがONになるような動きをするようになります。AkamaiとGoogleにおけるQUIC開始の違いこちらは何を示しているかというと、左側はアメリカのIPSプロバイダ。右側はEUのISPプロバイダです。これらの棒グラフは、QUICの通信がTCPに比べてどれぐらい転送効率が上がったかというグラフになっているのですが、一番右の青い棒グラフは、Akamaiがきちんとネットワークごとに輻輳制御をチューニングした結果、単純にQUICを使用するよりもはるかに転送効率のよいQUICの通信を実現していることが示されています。真ん中の紫色の棒グラフの7パーセントはQUICのDefaultの輻輳制御、一番左の赤い20パーセントというのは、AkamaiのQUICのDefault値を使った場合です。このように、きちんと制御をしないと、効果的なパフォーマンスアップは見られないので、このあたりはAkamai側も非常にセンシティブに日々チューニングを行っています。次にQUICのNegotiationの開始はどのようにされるかというところにフォーカスして見ていきます。今、IETFで定義されている方法が2つあります。2018年6月現在、その2つのうち、Google社とAkamaiはともにHTTPの”alt-svc”ヘッダを使ってQUICのNegotiationをしています。AkamaiでのQUICの開始はどのように始まるのかというと、ある程度TCPのレイヤーで通信をして、HTTPSの通信をいくつかしたあとに結果としてQUICで通信したほうがが効率が良いネットワーク完了であると判定された場合、QUICに切り替えます。そのときのalt-svcのmax-ageは1時間で出しています。同様の内容をGoogle社のQUICと比較してみました。半月ぐらい前に確認した結果なので、今も同じかどうか、みなさんもやってみたらおもしろいかなと思います。TCPのセッションが確立した直後、HTTPSの通信が始まると同時にQUICのHelloが飛んでいます。alt-svcのmax-ageが長めの1ヶ月と出ていますので、GoogleのドメインではQUICの通信が多い傾向にあるということが頷けます。Google社が通信している内容と我々が配信している内容はけっこう違いまして、Google社は自社サービス、自社ドメインでQUICを動かしているのですけれども、我々はお客様のトラフィックを転送させていただいているので、より効率的にできるようにということに注意を払いながら、よりセンシティブにチューニングを続けています。先ほども申し上げたとおり、IETFで日々QUICの議論がされているのですが、まだまだ議論中のトピックが残っています。Bitと呼ばれるFieldを定義しようという話が出ていますが、実装するかどうかは今後のバージョンで考えるとなっている状況です。現状のQUICは、HPACKと呼ばれるHTTP/2でのヘッダ圧縮方式が使われているのですが、今後はQPACKと呼ばれるQUICの新しいヘッダ圧縮方式に変わっていくと思われます。IDの2つを持つことで、できるだけスムーズに通信を継続できるようにする、という実装が議論されています。ECNは提案はされているのですが、現状では実装されないかもしれません。最後は、クライアント側のQUIC対応です。SDKが提供されています。Library(Cronet)が公開されていますので、こちらを使うことで非常に容易に実装できるようになってきています。Report)最後にサマリです。日々コードをアップデートしていっているところです。AkamaiのTCPではAggressiveにQUIC接続をOfferしていないように見えるかもしれませんが、あまりそこは気になさらず、QUICが動いたときにはQUICのほうが転送効率が良いんだなと考えていただければと思います。Supportは7月16日から徐々に動き始めますので、ぜひ楽しみにしていただければと思います。プレイヤー側のQUICの挙動に不安がある場合には、Opt-outしておくことを推奨しています。みなさんは、ご使用中のプレイヤー側のセキュリティをどこまで気にしていますか?弊社側ではそのようなプレイヤーのセキュリティアセスメントも有償サービスでやらせていただいてますので、もし気になる部分があるようでしたら、ぜひお声がけいただければと思いますので、よろしくお願いいたします。私の本日の話は以上となります。ご清聴ありがとうございました。Conferenceに関する記事をまとめています。Conferenceに関する新着記事が公開された際に、通知を受け取ることができます。