Chrome 70は[機能リスト]とAV1をサポートしています-コーデックのサポートがそれほど重要なのはなぜですか？

Chromeの69番目のバージョンは大きなアップデートでした。 デスクトップ版とモバイル版の新しいインターフェースを示しました。 Chrome 70はそれほど急進的ではありませんが、その新機能は非常に重要です。 私たちは、新しいバージョンで最も重要な、私たちの意見では重要な、つまりパフォーマンスの新しい基準を設定するAV1コーデックのサポートについて、適合翻訳を作成し、資料を追加しました。 これまでのところ、コーデックはビデオの再生時にのみ使用されますが、WebRTCに到達することを願っています-これにより、ビデオ通話や会議で高度なエンコーディングを使用する機会が得られます（たとえば、 Web SDKを使用）。

AV1をサポート

ほぼ10年前、GoogleはH.264向けに独自の競合コーデックを展開しました。VP8でした。 技術的な競合他社はそれほど違いはありませんでしたが、VP8は無料であり、H.264にはライセンスが必要でした。 Androidは2.3のGingerbreadからVP8をサポートしています。 また、すべての主要なブラウザー（Safariを除く）はVP8ビデオを再生できます。







Googleは現在、AV1と呼ばれるVP8 / VP9の後継機を開発している企業グループであるAlliance for Open Mediaの一部です。 Facebookはすでに数千の人気のあるビデオでコーデックをテストしており、 VP9と比較して30％以上、つまり50.3％、46.2％、34％（メインのx264プロファイルと比較して、 x264プロファイルとlibvpx-vp9、それぞれ）。



Chrome 70以降、AV1コーデックはデスクトップとAndroidのデフォルトをサポートしています。 また、コーデックが広く使用されるには時間がかかりますが、それでも重要なステップです。 他のブラウザはAV1をまだサポートしていません。

AV1の詳細

説明：このセクションは、 次世代ビデオの記事「 AV1の紹介 」からの抜粋です。

ルマからのクロマ

Luma予測からのクロマ（以降-CfL）は、AV1で使用される新しい予測方法の1つです。 CfLは、輝度値（輝度）に基づいて画像の色（彩度）を予測します。 まず、輝度値がエンコード/デコードされ、次にCfLが色を予測しようとします。 試行が成功すると、エンコードする必要のある色情報の量が減ります。 したがって、スペースが節約されます。



CfLがAV1に初めて登場したのは注目に値します。 CfLの設立文書は2009年に遡ります。 同時に、LGとサムスンはLM Modeという名前でCfLを早期に実装することを提案しましたが、これはすべてHEVC / H.265の開発中に削減されました。 シスコのThorコーデックは同様の手法を使用しており、HEVCはCross-Channel Prediction（CCP）と呼ばれる改善されたバージョンを実装しています。

改善されたイントラ予測

最近まで、ビデオ圧縮はフレーム間予測に基づいていました。 予測が参照フレームに基づいている場合の、他のフレームとのフレームの違い。 この手法は急速に発展しましたが、それでも他のフレームに依存しない参照フレームが必要です。 その結果、参照フレームはフレーム内予測のみを使用します。







テストビデオの最初の60フレーム。 ヒストグラムは、残りの約20倍の参照フレームで始まります。



参照フレームは中間フレームよりもはるかに大きいため、できるだけ使用しないようにします。 ただし、参照フレームが多数ある場合、ビデオのビットレートが増加します。 これに対処し、参照フレームのサイズを小さくするために、コーデックの研究者はフレーム内予測の改善に焦点を当てました（これは中間フレームにも適用できます）。



要約すると、CfL-これはまさにフレーム内予測の高度な手法であると主張できます。 フレーム内の明るさに基づいて機能します。

着色されたクレヨン

CfLは基本的に、合理的で正確な予測に基づいたモノクロ画像の色付けです。 予測は、エンコードが独立して発生する小さなブロックに画像がビートするという事実によって促進されます。







コーディングの精度を最大化するブロッキング。



エンコーダーは画像全体ではなくその断片で動作するため、小さな領域で相関関係を明らかにするのに十分です-これは祝福された明るさの色を予測するのに十分です。 小さな画像ブロックを取得します。









このフラグメントに基づいて、エンコーダーは明るい=緑、暗いほど彩度が低いことを確認します。 そして、残りのブロックについても同様です。

CFLからAV1

CfLはPVQアルゴリズムの使用を開始しなかったため、ピクセルドメインと周波数ドメインのコストはほぼ同じです。 さらに、AV1は離散サインおよびピクセルドメインID変換を使用するため、周波数ドメインでAV1 CfLを実行するのは非常に簡単ではありません。 しかし-驚き-AV1は周波数領域でCfLを必要としません。 基本的なCfL方程式は、両方の領域で等しく機能します。



AV1のCFLは、再構築を可能な限り簡素化するように設計されています。 これを行うには、明示的にαをエンコードし、それに基づいてβを計算する必要がありますが、βを計算することはできませんが、代わりにエンコーダーによってすでに予測されたDCカラーシフトを使用します（精度は低くなりますが、まだ適切です）：







デフォルトのDC予測（隣接ピクセルに基づく計算）と計算されたβ値（現在のブロックのピクセルに基づく計算）の比較。



したがって、エンコーダ側での近似の複雑さは、予測を使用して最大限に最適化されます。 予測が十分でない場合、残りの変換が実行されます。 予測がビット単位で利点を提供しない場合、まったく使用されません。

いくつかのテスト

Open Media Allianceは、 Are We Compressed Yet？でも利用可能な一連のテストを使用しています。



以下は、さまざまなインジケーターのコンテキストでのビットレートの表です。 CIE delta-E 2000に注意してください。これは、知覚的に均一な色誤差のメトリックです。 ビットレートがどのように保存されるかがわかりますか？ 最大8％！

	BDレート
	PSNR	PSNR-HVS	SSIM	CIEDE2000	PSNR Cb	PSNR Cr	MS SSIM
平均	-0.43	-0.42	-0.38	-2.41	-5.85	-5.51	-0.40
1080p	-0.32	-0.37	-0.28	-2.52	-6.80	-5.31	-0.31
1080pスクリーン	-1.82	-1.72	-1.71	-8.22	-17.76	-12.00	-1.75
720p	-0.12	-0.11	-0.07	-0.52	-1.08	-1.23	-0.12
360p	-0.15	-0.05	-0.10	-0.80	-2.17	-6.45	-0.04

...およびChrome 70のその他の新しいアイテム

Windows上のPWA

Progressive Web Appsのサポートは主にモバイルプラットフォームに実装されていますが 、Googleはデスクトップについても忘れていません。 デスクトップChrome 67では、PWAインストールボタンが表示され、Chrome 70にはすでにWindowsユーザー向けのいくつかの改善がありました。









現在、ChromeはPWAのポップアップ「Install app？」を表示します（しばらく操作した後）。 PWAをインストールすると、ブラウザーは[スタート]メニューにPWAのショートカットを作成します。 モバイルエクスペリエンスと同様に、ブラウザーインターフェイスは開いているPWAで非表示になります。



Googleは、バージョン72のMacおよびLinuxでこの機能を展開することを約束しています。

形状検出API

Webアプリケーションは、通常は機械学習JSライブラリを使用して、さまざまな方法でバーコードを読み取り、顔を認識できますが、これは非常にゆっくりと動作します。 この機能のアクセシビリティと生産性を高めるために、GoogleはChromeに独自の機能である形状検出を導入しています。



Chrome 70 のシェイプ検出APIは実験的な機能（元の試用版）です。 まだ広く使用する準備ができていません。 APIは、顔、バーコード、テキストの3種類のオブジェクト/画像を定義できます。 現時点では、OSはオブジェクトを定義する機能を必要とするため、互換性はプラットフォームによって異なります。 ここでデモを試すことができます 。

TLS 1.3

Transport Layer Securityは、インターネット経由でデータを安全に転送できるようにするプロトコルです。 HTTPSでサイトを使用する場合、ほとんどの場合、データはTLSを介して送信されます。 Chrome 70は、先月リリースされたTLS 1.3をサポートしています。



変更点のリストはこちらから入手できますが、一般的にバージョン1.3では効率とセキュリティの両方が向上します（たとえば、BREACHとCRIMEがhttpsで安全に圧縮を使用できるようになりました- 翻訳者のコメント 、 menstenebrisに感謝します ）。 接続を確立するために必要な手順が少ないため、時間のわずかな改善に気付くことができます（もちろん、訪問したサイトがTLS 1.3をサポートしている場合）。 CloudFlareとの違いの明確な比較を次に示します。











TLS 1.3のリリースに伴い、SHA1やMD5などの古い機能のサポートも終了します。 Googleはこれをステータスページで発表しました：

TLS 1.3は複数年にわたるプロジェクトであり、さまざまな業界、研究グループ、およびその他の参加者からの支持者を集めて標準に取り組んでいます。 以前、標準のドラフトバージョンを試しましたが、標準が完全に実装されたら、Chromeで最終的に実装できます。

Firefox 60はTLS 1.3（ドラフト23）のサポートを追加しました。これは今年5月に公開されました。 その後、使用を開始し、CloudFlare。

その他の機能

いつものように、Chrome 70にはユーザーと開発者向けのイノベーションが含まれています。 このアップデートの他の変更点のリストは次のとおりです。

• 音声合成APIは、ページが少なくとも一度このAPIと対話するまで機能しません。 このAPIは、Chrome 66の新しい自動再生ポリシーまで、モバイルデバイスのポップアップをスパムするためによく使用されました。
• Macbook ProのTouch IDは、Web認証APIのログイン方法として使用できます。
• ページが全画面モードの場合、ポップアップが表示されるとページが全画面表示されなくなります。
• AppCacheは、https以外のページでは機能しなくなりました。
• Androidデバイスでは、ブラウザの識別を防ぐために、OCビルド番号（「NJH47F」など）はユーザーエージェントに含まれなくなりました。 iOS上のChromeは、Safariの実装に従うために、ビルド番号を完全に削除するのではなく、「15E148」のままにします。
• opusオーディオは、MP4、Ogg、およびWebMコンテナでサポートされるようになりました。
• WebUSBは現在、個々のワーカーのコンテキストを使用しているため、生産性が向上します。
• Web BluetoothはWindows 10で動作するようになりました。
• 新しいデスクトップ同期ダイアログ。
• サービスワーカーには名前を付けることができます。
• Credential Management APIはPublicKeyCredentialをサポートするようになりました。
• カスタム要素、HTMLインポート、navigator.getGamepads、Shadow DOM APIの初期実装は非推奨ステータスになりました。
• フラグ＃enable-lazy-frame-loadingおよび＃enable-lazy-image-loadingを使用して、 遅延読み込みを有効にできるようになりました。