ChromeやNode.jsで利用されているJavaScriptエンジン「V8」に、8年の歴史の中でも大きな変化が訪れました。8月3日にリリースされたバージョン6.1で、数年かけて進めてきたJavaScriptコンパイラーが世代交代を終えました。詳しい話は、V8のブログでも語られていますが、ここでは大きなトピックであるコンパイラーの世代交代についてお話します。

なお、この動きについては、昨年に開かれたカンファレンス「BlinkOn 6」でも語られており、Google I/O 2017でも、Seth Thompsonによるセッション「V8, Advanced JavaScript, & the next performance frontier」によって紹介されています。本記事では、これらの発表内容を補足してご紹介します。

V8のミッションとは？

Chromeで使われているJavaScriptエンジン「V8」ですが、そのミッションはとてもシンプルです。

「Speed up real-world performance for modern JavaScript, and enable developers to build a faster future web.(実世界での要求にあわせてモダンなJavaScriptのパフォーマンスを向上させること。そして、今後の変化していくWebに早く追従し、開発者がそれらをビルドできるようにすること)」

V8のパフォーマンス改善につきまとう2つのトレードオフ

V8とはなんでしょう？JIT(just-in-time compile)で動作させることができるJavaScriptのエンジンです。ブラウザがJavaScriptを受け取ると、ブラウザはそのコードをトランスレートして実行したり。また、コードを翻訳してコンピューターが理解できるネイティブコードにコンパイルしてから実行します。

ただ、そこにはいくつかのトレードオフが存在します。

1. コンパイルして生成されたネイティブコードは、実行されるピーク時の速度が早い一方で、コードの量が多いほど、最初に実行されるまでに遅延が発生する。一方で、トランスレーターを使った場合は、実行されるまでの遅延は小さいけど、実行時の速度が遅い。
2. JavaScriptエンジンは、パフォーマンスを良くしようとするとメモリの消費量が多くなる。一方で、省メモリを進めようとするとパフォーマンスは悪化する。

例えば、以下のような一行のfunctionを呼び出すコードについて考えてみましょう。

このコードでは、 function foo() は一度しか呼び出されていませんよね。このケースでは、実行されるまでの速さ（Fast Startup）を重視し、実行時のパフォーマンス（Peak Perf）は重要視しません。

しかし、以下のケース。

1万回も function foo() を呼び出しています。このケースでは、Fast Startupが遅れてでも、Peak Perfを重視する必要がでてきます。 foo() はネイティブコードにコンパイルされていなくてはいけません。そしてそれがデスクトップ型のコンピューターであれば、メモリも潤沢なので、大量のメモリ消費を犠牲にネイティブコードをさらに幾度に渡り最適化させます。

ただ、これはあくまでデスクトップ型コンピューターの場合。同じ1万回 foo() を呼び出すコードであっても、モバイルの場合は同じアプローチにはなりません。Androidデバイスはモバイルなので、デスクトップと同じようにメモリを扱うことはできません。

ネイティブのコードへコンパイルはされますが、メモリの消費量は抑えられるよう最適化は制限されます。

別のパターンについても考えてみましょう。それが以下のコード。

これはNode上で実行されているコードです。一度起動されたら、ずっと利用されるわけですから、当然、Fast Startupを犠牲にしてPeak Perfを改善しようとしますね。しかし…

IoTデバイス上で動作するとなると、同じ状況とは言えません。サーバー用マシンとは異なり、メモリ消費は抑えなくてはいけません。Peak Perfを上げるようにはしますが、それはメモリ消費が少なくて済むようなアプローチで進めます。

同じ一行のfunction呼び出しであっても、その最適化方法は無数にあり、コンテキストやデバイスの状況に強く依存するのです。そしてそれは、Fast Startupなのか、あるいはPeak Perfに最適化していくのか、メモリを富豪的に扱うのか、それとも小さくなるよう努力するのか、解決しなくてはいけません。

8年前のリリース時点から全てが変わろうとしているV8

V8エンジンは、ここまでに説明したあらゆる状況で最適化できるようにしたり、また新しいパターンのJavaScript（asm.js, WebAssembly等）に対応できるよう、2〜3年かけて実行パイプラインを作り変えました。

過去の変遷を見てみると。

2008年のリリース時点の段階では、シンプルなコードジェネレーターがあって、そこからやや最適化を行ったマシンコードが生成されるだけでした。あらゆるJavaScriptのコードは、この仕組を使って実行されます。

ただ、最適化には計算が必要なため、コードを実行できる状態にするまでに多くの時間を要します。大量のJavaScriptコードを扱う場合は、Startup Time短縮するために最適化の処理をスキップすることが求められます。

2010年にコンパイラ「Crankshaft」が追加されます。計算コストの高い最適化処理を分離し、Crankshaftにその責務が委譲されました。コードの生成だけであれば、Full-codegenは最小のコストでマシンコードを吐き出すため高速なため、Startup Timeが最適化されます。そして、CrankShaftを使ってコンパイルすれば、計算コストを犠牲にPeak Perfにとって最適なマシンコードが生成されます。

実行時に、CrankShaftが吐き出したコードを、Full-codegenが吐き出したコードへ置き換えることで最適化を図ります。

2015年。Crankshaftには限界が来ます。JavaScriptの仕様そのものが大きく変化する時代になりましたが、Crankshaftはその設計上、JavaScriptの機能をサポートしきれず、また新しいパターンのJavaScript（asm.js, WebAssembly等）にも十分に対応できませんでした。当時のフロントエンドエンジニアなら、V8のECMAScript標準への対応の遅れに苛立ちを感じたはずです。

V8開発チームは、それを改善しようと新たなコンパイラ「TurboFan」を追加します。

2016年。「Ignition」と呼ばれる仕組みを追加しました。Ignitionには、ソースコードをいきなりマシンコードにするのではなく、バイトコード(マシンコードほどハードウェアに依存しない「中間コード」と呼ばれるもの)を生成するコンパイラーと、それを実行するインタプリターが内包されています。

そして、TurboFanはバイトコードを扱う形へと作り変えられました。そして現在、最新のVersionである5.9では、この2つの仕組みは既に使われていません。内部にコードこそ存在していますが、バイトコードの生成と解釈するインタープリターIgnitionと、PeakPerfを改善するための処理をするコンパイラーTurboFanだけで動作しているという状況です。

そして、これからまもなくリリースされる6.0では、コードとして完全にV8から削除されます。

「Ignition Interpreter」とは？

中間コードを生成して実行するインタプリター。メモリ消費が小さく動く、Fast Startupも最適という特徴があります。

• モバイルなどのメモリの小さな環境で動かすのに最適。
• Startup Timeに最適化すべきコードの実行に向いている。
• TurboFanと組み合わせることで、実行速度を最適化できる。

「TurboFan」とは？

主として、最適化を行うことを目的としたコンパイラー。

• 使われ方としては、拡張的な感じ。ただ、あらゆる新しいJavaScript機能に対応していき、その場合も活用される。
• WebAssemblyのバックエンドでもある。
• 最近はtry/catch/finallyとか、ES2015+の最適化が可能になった。

まとめ

V8について、メモリ管理向けガーベジコレクター「Orinoco」など、さまざまな技術要素が進化し、語り尽くせないほどのトピックがあるのですが、それはまた別の機会にお話しましょう。TurboFanへの完全移行、実態としてすでにほとんど終わった状況といっても過言ではありませんが、8年前とは全く異なる、Web・JavaScriptの変化に追従する大きな変化です。今後も楽しみですね。

この記事は2017年5月17、18、19日に米国カリフォルニア州マウンテンビューにあるAmphitheatreで行われたGoogleの開発者向けカンファレンスGoogle I/Oの3日目に「The Future of Audio and Video on the Web」というタイトルのセッションの内容です。

はじめに

タイトルをパッと見て、例えばWeb Audioの話も絡むのか！？と思いきや、内容はビデオでしたが、2000年からwebのみならずリビングにあるテレビ（動画）から、YouTube、SNSでの動画も含めて歴史を追った説明、デモをまじえ動画を中心としたwebサイトの現在できる最高のExperience、そして見えかけている未来のwebでの動画の拡がり、とwebで動画という切り口から幅広く説明をした中身の濃いセッションでした。

登壇したのはこのお二方。Product ManagerのJohn Pallettと、Developer Programs EngineerのFrancois Beaufortです。

それでは内容を見ていきましょう。

動画が机、リビングから手の上に乗り外に向けて歩き出す

2000年から10年はほとんど変わらなかった。 2000年は私(John Pallett)がHDのテレビを買った最初の年。この当時はHD動画を録画する機器すらなかったが、直後にHD録画機器も出始めSkypeも同じ頃に登場。2005年にYouTube、2007年にはAmazonのPrimeビデオ、Netflixがストリーミングサービスを開始。しかし、この頃は机、リビングで見るのが主でした。

2010年からは私の娘を軸に見ていきます。 2010年はタブレットが出始めた年。娘はこの頃から場所を選ばず受動的に動画、音楽を聞いたり、一方で能動的に録画、録音するようになっていました。

ちょうどその頃にはFaceTimeが登場し、ビデオチャットが気軽にできるようになり、2011年にはTwitchでゲーム動画の配信、2013年にはSnapchat、2014年にmusical.lyで若者が音楽ビデオを録り、さらにそれを友達同士で配信するようになった。さらに過去数年では、VR、AR、360度動画が出てきたりと、イノベーションがここ数年の動画の進化を加速。

この進化を裏付けるように、現在のインターネットのトラフィックの70%が映像（ビデオ）で、Cisco社は2020年までにこれが80%まで伸びるだろうと予測しています。

モバイルwebでの動画の過去と未来

先程挙げた、Twitch、Snapchat、musical.ly、これらのサイトに行くと実はアプリ（Android, iOS）のインストールを求められます。

しかし、モバイルwebでこれらのアプリを作ればアプリのインストールは不要、そしてすぐにやりたいことができるはずなのに、なぜそうなっていないのでしょう？少し奇妙です。

理由を考えると実はそれにはいくつかの問題、課題がありました。一言でいうと、モバイルwebは動画が得意ではなかったのです。その問題点を見ていきます。

Buffering

動画の提供側はFlashを第一に、第二にHTML5に向けて公開するという時代が続いていて、モバイルwebは眼中の外でした。なぜならモバイルwebで動画にアクセスすると動画のダウンロードに時間がかかり、再生までにかなりの時間がかかっていたからです。

映像のクオリティの低さ

「ダウンロードに時間がかかるのなら、映像のクオリティを落とし、ファイルサイズを小さくしよう！」となりますが、小さくすればするほど映像のクオリティは低下します。

いけてないレイアウト

動画の提供側はモバイルwebは眼中の外だったので、サイト全体のデザイン、レイアウトはデスクトップに最適化されていて、モバイルwebでは動画の一部しか表示されていなかったりした。しかし、この現象は防ぐためのAPIがなかったことが大きい要因で、対策はできなかったかもしれないというのも事実。

オフラインでは利用不可

オフラインでの利用はできなかった。もちろんChromeではOffline時には恐竜ゲームはできて楽しいけど、動画を観たいのに恐竜ゲームを例えば飛行機に乗って数時間するのは現実的ではありません。

では現在のモバイルwebでどうなっているかを紹介します。

デモアプリとしてDeveloper Relations TeamのPaul Lewisが書いたアプリを例に紹介します。アプリの名前は「Biograf」で、アプリとソースコードは以下のURLにあります。

• アプリ bit.ly/pwa-media
• ソースコード bit.ly/pwa-media-code-media

（セッションではここで実際にデモを行います。併せてご覧になると分かりやすいと思います。デモの動画）

（クリックでデモ部分の動画が再生可能です）

特徴は以下です。これはwebアプリですよ！

• Progressive Web App
• Nativeアプリのようにホーム画面からアイコンをタップして起動可能
• 起動アニメーション（Splash）が表示できる
• Chrome（ブラウザ）の枠はなく、全画面でアプリ全体を表示
• スクロールも非常にスムース
• 動画は再生をタップしてから一瞬で開始
• デバイスを横にするとフルスクリーンでも動画の表示が可能
• タイムラインをスクロールすると、サムネイルも表示可能
• フルスクリーン中にタップすると、「再生、停止、コマ送り・戻し」のコントロール画面が表示可能
• 通知エリアにもコントロールを表示することが可能
• 動画のダウンロード機能もあり、ダウンロードした動画はプラウザを閉じても、機内モードでも再生可能（Background Fetch）
• ロック画面からのコントロールも可能
• ロック画面で動画のサムネイルを背景としても表示可能
• 制限付き動画でもライセンスをハンドルして再生可能

これらのExperienceは動画の再生時「ページのロードが遅いとユーザはサイトから離脱してしまう」事実を元に考えると非常に重要な機能でもあります。Akamai社の調査では2秒で表示されないとサイトからの離脱が始まり、また動画の再生に関しては6秒以内に再生されないとユーザは再生開始を待たず離脱してしまうという調査結果を出しています。

では、このアプリを例にExperienceを1つ1つ見ていきましょう。

反応の速い再生(Fast Playback)

これはAdaptive Bitrate Streamingで実現しています。動画を再生するには動画のダウンロードは必須だが、モバイル環境下ではダウンロードするデバイスがトンネルを通ったり、帯域を失ったりする。Adaptive Bitrate Streamingがこれらのネットワークがコンスタントでない部分を解決します。

再生するビデオは複数のBitrateでエンコードして、それらがさらにある時間間隔で断片化して保存する。断片化されたファイルをダウンロードするアプリ側で低域等の状況に合わせてBitrateと断片の組み合わせの最適化を施すことで、反応の速い再生を可能にします。

これを実装したのがOpen SourceのShaka Playerです。

また、再生ボタンをクリック/タップしてからの再生の反応に関しては、Service Workersで動画をPre-Cacheすることで速くしている。これが実装されているのがTHEOPlayerです。Biografにも実装されているが、動画の説明等も一緒に、事前にキャッシュ（Pre-Cache）することで再生までの時間を短縮している。またService Workersを使うとサイト自体のスピードもアップすることが可能です。

VIACOM18のVootという動画サイト（5月25日現在、インドでの提供のみ）ではページロード時間が5倍速くなり、これによってユーザがが77%増加、日々に動画を再生するユーザは15％増加したという結果もあります。

Offline

Offlilneは例えば飛行機に乗っている時など、インターネットアクセスがない場所では非常に重要な機能。BiografではService Workersを使って、ページに表示する動画の説明、また動画に関してはリーズナブルなBitrateで事前にダウンロードしキャッシュとしてブラウザ側に保存することでどこでも再生できるようにしています。このBitrateは開発者側からService Workersのロジックの中で、またはユーザ側が例えばダウンロード開始時に選択することが可能。

Offlineはオーディオにも適応可能です。例えばオーディオブックを考えると、Service Workersを使って事前にブック内のプレイリストのオーディオを事前にキャッシュしておくことで、Offlineでも再生が可能になる。

Biografでは動画をキャッシュするためにBackground FetchというAPIを使っていますが、この機能は現在開発中でExperimental Web Platform features（Chromeのアドレスバーにchrome://flags/#enable-experimental-web-platform-featuresを入力すると変更可能です）をEnableにすることで利用が可能になります。このAPIに関するフィードバックをお待ちしています。

VP9

コーデックに関してです。クオリティを落とさずに2倍のコンテンツを保存できたらよいですよね。VP9は一般的なコーデックに比べると50％程圧縮率が高いので、質を落とさずにファイルサイズを50％減らすことができます。既に20億のデバイスがサポートされている状態なのでとてもよい選択肢。例えばYouTubeではVP9を使うことで他のコーデックで配信したときよりも再生までの時間を15〜80％縮めることができています。

User Experience

Media Session API

ロック画面、通知エリアでサムネイルをバックグラウンドに表示していたのと、コントロールボタンを表示していたのがこのAPI。ウェアラブル側にも表示されます。

実装は簡単でMetadataとしてタイトル、アーティスト、アルバム名、表示する画像を指定をし、コントロール（再生、ストップ等）のボタンが押された時のHandlerをそれぞれ書くことで実装が可能です。

Session Orientation API

デバイスを回転させたときの動作を指定できるAPI。Biografでは横にした場合に全画面表示にしている。縦、横になった場合のHandlerを書くことで実装が可能。

webでの動画の未来

タイトル通りの未来のお話をします。映像周辺の仕様の進化はディスプレイをよりリアルな表現の表示に近づけてくれます。

Wide Color Gamut

まずは色からお話します。現在のテレビ（4Kや8K）で実現されている色がモバイル、デスクトップのwebで表現できるようになります。

現在のディスプレイで表現できている色は目で見えているよりも色の表現は乏しい。その色は存在する色が外側の枠だとすると、最も内側にある三角枠が現在のディスプレイ（SRGB）の守備範囲。これがBT2020になると真ん中の三角枠まで表現できるようになります。

僕の履いている靴、実はこのディスプレイ（登壇者の背面にある）では正しい色で表示されていない。けども4K、8Kではより近い色が出てるはず。
（独り言：もしや登壇者のJohn Pallettさん、このために靴を新調したのかな？）

High Dynamic Range (Brightness)

いままでよりも明るいものは明るく、暗いものは暗く表示できるようになる仕様です。現在の一般的なディスプレイではSDR（Standard Dynamic Range）しか表現できません。これは現実の世界の明るさからするとかなりの差があります。

HDR(High Dynamic Range)をサポートしたディスプレイがこれから市場に出てきます。これはOTF（electric Optical Function、またはガンマFunctionともいう）を変えます。デジタルの数字からディスプレイでどれだけの明るさで表示するかのFunctionのことで、それが変更されるので映像・画像を扱う方はどのディスプレイが何をサポートしているか、またそのディスプレイの特性を知った上で選択する必要が出てくるということです。

Wide Color GamutとHigh Dynamic Rangeのコードは以下です。上部についてです。CSS Media Query Level4で可能になります。現在のChromeではcolor-gamutがサポートされていますが、デバイスでどの色が使えるかをクエリすることが可能で、それによって決定することが可能です。

また下部のコードではVP9がHDRとOTFでどの色で表示できるかをクエリによって決定することができます。

Alliance for Open Media(AOM)

アライアンスです。このアライアンスはYouTube、Google、Amazon、Twitch、Netflix、Microsoft、Mozilla、Hulu、BBCが参加していて、Open SourceでRoyalty-Freeの新しいCodecを作ろうとしています。

HDRだけでなく、Wide Color Gamut、また8K、4K、360どビデオも低いBitrateでも届けることができるようなCodecを考えています。なぜなら世界で皆が同じレベルのネットワークを使えるわけではないから。

このアライアンスではAV1という名前のCodecを開発している。数週間前はまだ開発も終えていないし、使えるフォーマットではなかったが、NetflixがVP9よりも20％高い圧縮率のフォーマットを実現することができたとの報告を受けている。

恐らく疑問に思うのは「AV1がどれだけのデバイスでサポートされているのか？」というところだと思います。ここがwebのユニークで面白いところ。1GHzと3GHzのデバイスでは再生のされ方が違う。ではそこをどうするか、VP9を例にコードを見てみます。Media Capabilities APIを使うことで以下のようにいろいろな値を指定することが可能です。

APIにResolution、Bitrate、再生したいCodecを渡すと、指定した形式をサポートしているか、指定した形式でスムースにつまらずに再生できるか、バッテリパワー的に効率的かを返してくれるので、この情報をどのタイプで再生するかのみならず、どのResolutionで再生するか等、ユーザに最適なExperienceを提供することができるようになる。

録音・録画とシェアとSNS

ここ数年、映像とオーディオに関してここ数年で飛躍的に前進している。私の娘がモバイルで音楽の制作、映像の撮影をしている。顔に飾り物をディスプレイ上でつけたりカスタマイズして、そのまま友達とSNSでシェアしてる。これは5、6年前では考えられなかったことです。SNSでは即座に撮影してシェアすることがキーになります。これはwebにはとても得意ところ。なので、ここでSNSやコミィニケーションについて話をします。

WebRTCはあたらしい技術ではないが、ここ数年で急速にブラウザベンダとアプリケーションプラットフォームとしての両方に適応されてきました。そしてWebRTCを使えばLiveStreamingもすることが可能です。

そしてユーザがシェアする動画・音楽の制作に関して、簡単に探せて、簡単に見ることができ、さらにそれを見た友達が動画・音楽の制作ができ…となれば、とてもよいサイクルが生まれます。

このサイクルの実現はwebでなら難しくはありません。それではこのサイクルがwebで実現できるかどうかを、デモを交えてフランソワから紹介してもらいます。

Mustache（髭）

映像とシェアに関わる部分で現在のwebでできることを盛り込んだデモをご紹介します。アプリは「Mustache」という名前です。

Progressive Web Appになっています。ホーム画面のアイコンから起動すると、起動アニメーション（Splash）が表示されます。このExperienceですと、既にwebアプリだと認識するのが難しいと思います。顔には髭、頭には帽子をかぶっています。動かしても映像はとてもスムーズです。動画の撮影も可能で、それをシェアすることももちろん可能です（上の画像の右側）。

Mustacheが利用しているAPI

映像を扱う(getUserMedia())

カメラを扱い、画面に表示するコードが以下になります。

getUserMeida()でカメラの映像と音声を取得します。Mustacheの場合は映像のみを利用します。その他の条件として利用するカメラ（前面、背面）、Framerate、サイズをしています。そして下部のコードで取得した映像を画面に表示しています。

形状の検知（Shape Detection API）

現在、実験中のAPIであるShape Detection APIを使っています。動いている顔へ髭、そして頭に帽子をと、このAPIが重ねる正しい場所を検知することを可能にしています。つい先週完成したばかりのAPIです。

コードは以下のようになります。とてもシンプルです。FaceDetector()に顔を取得するか、また、顔を最大いくつ検知するかの数を指定するだけです。ブラウザ側のAPIなのでインターネットへの接続は不要です。

このShape Detection APIはBarcode、QR Codeを検知するAPIと同時に9月にはChrome安定版でテスト利用という目的で利用可能になります。また、現在でも「Experimental Web Platform features」をEnableにすることで利用可能です。もし要望、バグがあったら知らせてください。

映像の録画（Media Recording API）

Mustacheでは、以下のようにMedia Recording APIを使っています。MediaRecorder()へCodecをVP9と指定して、映像を受け取ったら処理をするHandler、また録画を停止した時のHandlerを書いている。Chromeに公開されて1年になるのでAPIは安定しています。

シェア機能（Web Share API）

シェアボタンを押したときにAndroidのNativeのシェア選択画面が出てきていましたよね。自然過ぎてわからなかったかもしれませんが…。これはWeb Share APIを使っています。
コードは以下です。share()にタイトル、テキストと映像のURLを指定します。このAPIは今年末には利用できるようになるでしょう。

Mustacheは以下のURLで公開しています。
Chrome for AndroidのCanaryを使い、Experimental Web Platform featuresのEnableにして利用してください。

• Mustache

全てのAPIを1つのノードとしてみるとwebではPlug-inなしでこれらノード同士を無限につなげることができます。例えば、Media Streamを使えばカメラからCanvasに描画、アップロード、またマイクからWeb Audioそして、WebRTCのRTCPeerConnectionへと、たくさんのAPIと接続して利用することが可能です。

まとめ

デモに交えてたくさんのAPIを話しました。多くが現在でも利用可能なAPIです。

Biografでは、Service Workers、Media Session API、Full Screen API、Screen Orientation APIなどを使っています。フランソワがこちらに記事としてまとめてくれていますので詳しくはそちらを参照してください。

映像の再生等に関わるProgressive Web Appを書く場合はBiografのコードを参考にするとよりよいExperienceを提供できるでしょう。
そしてMustacheで使っているMediaStream Recording API、Media Capture API、Media Streams APIは現在でも利用可能です。

最後に、以下の3つは特にFeedbackをお待ちしています。

• Background Fetch
• Shape Detection API
• Web Share API

ありがとうございました！

おわりに

個人的に数年前から年に数回はFacebookをモバイルwebから使う儀式をしています。写真や動画を撮ってシェアしたりするのが特にですが不自由な点がありました。

また、QRコードの読み取りも必ずモバイルのNativeアプリ、またはインターネットへの接続が必須とされていました。それを元に考えると近年のWebブラウザの進化には目を見張るところがあり、また同時にその進化を肌で実感できるエキサイティングなプラットフォームの1つだと思います。

今後も映像のみならず、他の分野でのWebブラウザの発展、拡張も期待できそうですし、その進化から目が離せないですね。