Web向けメディアフォーマットの詳細

♪ ♪

「Web向けメディアフォーマットの詳細」 へようこそ WebKitのエンジニアの Jean-Yves Avenardです Safariでサポートされている メディアフォーマットについて 画像と動画を中心に説明し Safari 17で利用可能になった 新技術を紹介します 新しい画像フォーマットの サポートを追加しました 最も一般的な画像フォーマットを 簡単に説明したあと あなたのサイトに適したフォーマット を選ぶお手伝いをします そして Safari 17で実装した 全く新しい技術による― MSEの最適化についてご案内します 最後に Media Source Extensionを使用した― 動画へのAirPlayサポートの 追加方法を紹介します 長年 3つのフォーマットが 最も広く使用されています これらは全ブラウザでサポートされており 簡単に作成と展開が可能です しかし この10年間で技術は格段に進歩し 新たな素晴らしいフォーマットが 利用可能になりました 現存のフォーマットは GIF JPEGおよびPNGです 詳しく見ていきましょう GIFは私の生まれた国では 正式には「ジーフ」と言います 36年前に登場したフォーマットで シンプルなアニメーションや ミーム ソーシャルメディアの コンテンツに最適です フルカラーパレットには非対応で 一度に8ビットカラーに制限されています ロスレス形式のため ファイルサイズが非常に大きく 大きなアニメーションには不向きです そして 30年以上前に登場した JPEGがあります プログレッシブ形式の読み込みという 優れた機能では 画像が完全に読み込まれる前に その一部が確認でき ネットワーク速度が速くない時代に 特に便利でした 写真などの色や細部に こだわった画像に最適です これはロッシー圧縮のフォーマットで 圧縮の過程で画像データの一部が失われます 圧縮によってファイルサイズを縮小して 読み込み時間を短縮することができます GIFには多くの制約があるため PNGが26年前に誕生しました PNGは透過性をサポートしているため 画像を重ね合わせる際に便利です ベタ塗りの面積が大きい画像や ロゴなどのシャープなテキストのほか WebKitのJavascriptの リス魚のようなイラストに適しています ロスレスのためJPEGほど圧縮しないので 色の多い大きな画像には不向きです GIFと同様に 置き換えを想定した作成で アニメーションをサポートしていますが そのような使用はほとんど見かけません

これらフォーマットの使用により Webブラウザに関わらず すべてのユーザーにリーチできます Safari 17は レガシーフォーマットに加え 4つのモダンなフォーマットを サポートしており すべて利用できるので理にかなっています どれも素晴らしく 互いに置き換えて利用でき それぞれ他のフォーマットにはない 利点があります Safari 14とmacOS Big Surで WebPが追加されました 高度な圧縮アルゴリズムにより 画質を犠牲にすることなく ファイルサイズの縮小を実現した 最新の画像フォーマットです WebPファイルは一般的に 以前の画像フォーマットよりも小さいため Webサイトのパフォーマンスや 読み込み時間の改善に役立ちます WebPは動画のようなクオリティで アニメーションを実行できるので サイズや色数の都合で GIFの使用が適さない場合に使用します Safari 17に追加された エキサイティングな機能として 高い圧縮率と画質を実現する― 新しい画像フォーマットである JPEG-XLがあります JPEG-XLは新しい圧縮アルゴリズム 「Modular Entropy Coding」を採用し 圧縮率の調整がより柔軟になりました JPEGのような低速接続での提供画像に適し 画像全体が完全に 読み込まれる前に ユーザーは画像の一部が確認できます JPEG-XLの大きな特徴は 既存のJPEGファイルから JPEG-XLに変換する際に データを失うことなく 最大60％の大幅な圧縮が可能な ロスレス変換ができることです 比較的新しいフォーマットのため すべてのデバイスやブラウザで 広くサポートされているとは限りません AVIFも最新の画像フォーマットで AV1ビデオコーデックを使用し 画質を損なうことなく 高い圧縮率を実現しています すべてのブラウザで広くサポートされており ライブフォトに適しており 最大12ビットの色深度に対応しています 最も幅広い支持を得ているため フォールバックとして使うと良いでしょう AVIFはJPEGと比較して 最大10倍まで圧縮することができます Safari 17ではHEIFとも呼ばれる HEICのサポートを追加しました HEVC動画コーデックの 圧縮アルゴリズムを使用する 画像フォーマットで 小さなファイルサイズを実現します 他のプラットフォームでは 広くサポートされていないため 代替フォーマットとしてのみ 使用することになるでしょう iPhoneやiPadで使われている 写真の保存形式なので iPhoneからアップロードされた写真を 無変換で直接扱うことができます アプリケーション内でWKWebViewを 使用して画像を表示する場合 ハードウェアアクセラレーションにより 高速かつ効率的にレンダリングできる― この形式を使用する必要があります

しかしJPEG-XLや AVIF HEICの大きな特徴として 広色域とHDRの両方に 対応していることがあげられます 数十億の色をサポートする大色域は より多くの色をファイルに保存し 画面上で表現することができます

HDRでは暗部や明度の程度および 光をどれだけ取り込めるかを より明確にできます さらに より鮮やかな屋外の風景または コントラストの強い明るいシーン または美しく複雑な肌の色を 完璧に表現することができます

広く普及しているWebブラウザに ご自身のWebサイトを対応させ続けるため 今後もGIF JPEGおよび PNGの提供が必要でしょう

追加フォーマットの提供によって 互換性を保ちつつ サイトの読み込みを高速化し 使用する帯域幅を減らせます 選択の必要はありません その方法をご紹介します JPEG-XL画像を使用して img要素に宣言すると 古いブラウザや対応していないブラウザでは 壊れた画像が表示されます

HTMLのpicture要素では 代替ソースを指定することで ブラウザがサポートする形式を 選択することができます 複数の代替ソースを用意し 最高のパフォーマンスを発揮する― フォーマットを優先させることも可能です ブラウザは利用可能なフォーマットリストを 上から下へと見ていきます そこで今回 サポートされている場合は HEICを優先して使用します 一致するものがない場合 または途中でデコードに失敗した場合は img要素のソースURLが選択されます User-Agentの文字列や 使用するブラウザを気にせず デバイスのサポートに関わらず 正しいフォーマットの提供が 簡単に実行できるのです 選択の必要はありません ブラウザに任せればいいのです では どのような画像形式があり 使用する場面が理解できたところで 次は動画― 特にアダプティブストリーミング動画を 見ていきましょう Webサイトにおける動画表現の進化は 魅力的であり Web黎明期から 長い道のりを歩んできました ここではWebサイトにおける 動画表現の進化にまつわる 重要なマイルストーンを紹介します 技術的な制約により 黎明期のWebサイトでの 動画利用は 一般的ではありませんでした Webサイトは主に テキストと静止画像で構成されていました 2000年代初頭にFlashや QuickTimeなどのブラウザプラグインが Webサイトに動画を追加する 一般的な方法として登場しました そして2010年にはHTML5が登場し プラグインを必要とせずに Webページに直接動画を 埋め込むことが可能になったのです よってWebサイトへの 動画の追加が容易になり 動画コンテンツの表示や再生方法を より柔軟に制御できるようになりました この革命の最前線にいたのがWebKitです モバイル端末の普及に伴い Webサイトにとって小さな画面でも 動画コンテンツを表示できることが ますます重要になってきました そのためWebサイトを さまざまな画面サイズや 向きに対応させる新技術が開発されました HTTPライブストリーミングは 2009年にAppleが導入しました HLSの大きな特徴として アダプティブ ビットレートストリーミングへの 対応により ユーザーのインターネット接続速度や デバイスの能力に応じて最適な品質の 動画配信が可能な点があげられます HLSのアダプティブストリーミングは ビデオコンテンツを 通常2秒から10秒の長さの 小さなチャンクまたは セグメントに分割することで動作します 各セグメントは 複数のビットレートでエンコードされており これらの異なるビットレートのバージョンは M3U8マルチバリアントプレイリスト形式で マニフェストファイルを介して クライアントに提供されます HLSは最適なバリアントを選択する点で 素晴らしい役割を果たします 使い方は非常に単純で エンドユーザーに 最適なソリューションです 残念ながらデスクトップでは全ブラウザが HLSのサポートに対応するわけでなく 現在もSafariのみサポートしています Webデベロッパはメディアデータの 選択と転送あるいは DRM付きコンテンツを デスクトップ再生する機能など よりコントロールしやすく 柔軟な対応を望んでいました そうして2013年 W3C団体からMedia Source Extensionが公開されました Safari 8と他のブラウザは すぐにこのサポートを追加しました Media Source Extension（MSE）は バッファリングと解像度を 管理するため Webページに さらにコントロールと責任を与えることで アダプティブストリーミングを可能にする 低レベルのツールキットです 総じてMSEはWebデベロッパにとって ゲームチェンジャーとなりました Web上での高品質な ストリーミング体験の開発が可能な 現在最も利用されている Webビデオ技術となっています MSEには欠点もあります バッファレベルや ネットワークアクセスのタイミングや量 メディアバリアントの選択といった 管理は得意ではありません 現代の汎用コンピュータのような 比較的強力なデバイスでは これらの非効率性はほぼ無関係です モバイル機器での消費電力は HLSネイティブプレーヤーより非常に高く MSEでは必要なバッテリーの節約を 実現できなかったため iPhoneでの利用は実現しませんでした MSEを有効にすると バッテリー寿命が短くなることは 様々なサイトの検証結果により 証明されています

デバイスの能力が制限されている場合や 接続が不安定な場合には MediaSource APIを使用した再生で HLSにおいて可能な同等の品質の 再生を実現することは困難です

理由としてMSEが メディアデータの ストリーミングに関する ほとんどの制御を User Agentから ページ内で動作するアプリケーションに 移したことがあげれられます ページにはユーザーエージェントと 同じレベルの知識はなく また最も安いネットワーク接続経路を 探すような目的もないため この制御の伝達は非効率的であり 通常は電力使用量の 大幅な増加につながります 今年はその欠点に対処したいと考え MSEが提供する― 柔軟性とHLSの効率性を 両立させる方法を懸命に探しました MSEの長所とHLSの素晴らしい要素を 組み合わせたこの新しい技術 Managed Media Source APIを 紹介できることを嬉しく思います 「管理された」MediaSourceとは MediaSourceと その関連オブジェクトの制御が ブラウザに委ねられているものです これによりユーザーエージェントが 利用可能なメモリや ネットワーク機能の変更に対応しながら メディアWebサイトの制作者は 性能に制約のあるデバイスでの ストリーミングメディアの再生を 容易にサポートすることができます 旧MSEとの違いをご紹介します Managed Media Sourceはより多くの メディアデータのバッファリングに 適したタイミングをWebページに伝えて 電力使用量を削減します バッファリングをしていないときは セルラーモデムを 長時間低電力状態にすることができ バッテリー寿命を延ばすことができます システムがメモリ不足の 状態になったとき Managed Media Sourceは未使用または 放棄されたバッファリングメモリを インテリジェントにクリアし ページをより効率的に使えるようにします Managed Media Sourceは バッファリングの開始と停止のタイミングを 追跡するため ページが 低バッファおよびフルバッファの 状態を検出する作業が容易になり ブラウザがこれをデベロッパに代わり 行なってくれます

これらの改善により Safariは5Gモデムを介して メディアリクエストを 送信することができます これにより高速な 5Gネットワークを利用し メディアデータの読み込みを 驚くほど高速かつ 電力消費を最小限に抑えながら サイト構築ができます ライブ再生が必要な場合は Managed Media Sourceが 自動的に検知し 利用可能な場合はLTEまたは4Gに 切り替えて バッテリー寿命を延ばします でも主導権はデベロッパが握ったままです どの解像度でどうやって どこからダウンロードするかは ご自身でコントロールできます Managed Media Sourceはヒントと MSEのより効率的なバージョンを 提供するだけです ManagedMediaSourceの利用により 帯域幅とバッテリー寿命を 節約することができ ユーザーはiPhoneだけでなく iPadやMacでも より長く動画が視聴できます MSEからManaged Media Sourceへ いかに移行が容易か ご紹介します ビデオプレーヤーをMSEから Managed Media Sourceに 移行するのは簡単で いくつか手順を踏むだけです ここでは過去にMSEの開発テストに 何度も使用したことのある 非常にシンプルな HTMLページを開いてみます video要素を作成し 12秒間のデータを読み込み再生します すべてのロジックは 実際には同梱の ユーティリティファイル mediasource.jsで行われます 特にrunWithMSEという メソッドを見てみましょう RunwithMSEはページの読み込みを 待ち video要素を作成し MediaSourceオブジェクトに添付して HTMLのボディに追加します まずManaged Media Sourceが 利用可能か確認します ManagedMediaSourceオブジェクトが 定義されているドキュメントを 定義されていない場合はMSEの使用の フォールバックにより簡単に実現します MediaSourceへの呼び出しを ManagedMediaSourceに置き換えます 別の容易な方法はMediaSource 自体のオーバーライドです getMediaSource()メソッドを定義し MediaSource shimを設定します

これでMediaSourceを 参照しているときはいつでも 代わりにManagedMediaSourceを 使用することになります Managed Media Sourceは 古いMSEより優先して選択すべきです HTMLページに戻りましょう

SourceBuffer作成後 ManagedSourceBufferを作成し 2つのイベントハンドラを追加します Startstreamingは新しいコンテンツの フェッチを開始し 管理された― sourceBufferに追加すべき場合に プレーヤーに通知します

1つは「endstreaming」イベントを 処理し プレーヤーが新しいデータの 取得を停止すべき場合に通知します これでユーザーエージェントは 十分なデータがあると判断し 低電力モードに 移行できるようになりました この実演では endstreamingイベントハンドラは 単なるプレースホルダーです MSEとは異なりsourceBufferは データを追加するときに限られず いつでもコンテンツを 退避させることができます MSEでは新しいデータの追加時に バッファリング範囲が増加すると 仮定するべきではなく 再生が停止する可能性があると考え MSE仕様では定期的な確認を 推奨していました よってbufferedchangeイベントの イベントハンドラを追加し どのデータが退去の対象になったか 確認する必要があります

Managed Media Sourceイベントの ガイダンスに従い エレメントから要求されたときだけ データを追加すれば iPhoneやiPadで 5Gスピードにアクセスでき ユーザーに高解像度 短い再バッファリング時間― そして最大限のバッテリーライフが 提供できます Safari 17で利用できる 新しいManagedMediaSourceを使った アダプティブストリーミングを扱う 準備が整いました しかしAppleのデバイスしか 気にかけないのであれば HLSを使用する方が 理にかなっているでしょう もうひとつユーザーが継続利用を 希望することがあります お気に入りのテレビに AirPlay機能が使用できることです ネイティブHLSを使う 大きなメリットとして AirPlayに対する 自動対応があります AirPlayを使えば ソファに座ったまま スマホの映像を大きな AirPlayデバイスに移せます Airplayには送信できる URLが必要ですが MSEには存在しないため 解決すべき問題が発生します 先ほどの画像フォーマットの選択では picture要素で代替ソースを 追加する方法を紹介しました video要素も 同様の仕組みを提供しています HTTPライブストリーミングの プレイリストを videoの子要素に追加するだけで ユーザーがコンテンツを AirPlayする際に Safariが Managed Media Sourceから切り替えて HLSストリームを再生します Safariは動画プレーヤーの コントロールに AirPlayアイコンを 自動的に追加し ユーザーに動画をAirPlayさせます これが複雑すぎる場合は LS.jsのような フレームワークを使用すれば Managed Media Sourceが利用可能 であれば 自動的にサポートしてくれ すべての作業を代行してくれます HLS.jsを利用して 動画を扱うのは非常に簡単で HLSをネイティブにサポートしていない Webブラウザでも使用可能です まず 通常通りHTMLファイルに video要素を作成します HLSがブラウザでネイティブに 対応しているか最初に確認します 対応していればマニフェストURLに直接 video source属性を設定できます そうでない場合はHLS.jsが 実行可能かを確認し 実行できる場合はHLS.jsライブラリの 新しいインスタンスを 作成して ID 「my-video」 の video要素に添付します 次に HLSプレイリストファイル ここでは my-video.m3u8を読み込みます これだけです 以上の手順で ほとんどのブラウザで HLS動画が再生可能になるでしょう

Managed MSEを設計する際 取りこぼしなく 従来と同じレベルの機能を ユーザーが引き続き 利用できるようにしたいと考えました そのためMac iPad iPhoneで Managed MSEを有効にするには プレーヤーがAirPlayソースの 代替物を提供する必要があります なくてもManaged MSEに アクセスすることはできますが Remote Playback APIから メディア要素のdisableRemotePlaybackを 呼び出して 明示的に AirPlayを無効にする必要があります 以上です Managed MSEは 昨年追加した SharePlayや空間オーディオ HDRなどの素晴らしい技術に すべて対応しています Managed MSEは macOSと iPad OSのSafari 17で 利用可能で iPhoneでは試験段階にありました ついにiPhoneに搭載されるのが 非常に楽しみです ぜひ新しい画像フォーマットや Managed Media Sourceをお試しください その際 必ずサイトを Safariでテストしてください また Safari Technology Previewを 2週間に1度公開しており エンドユーザーに届く前に 最新機能のテストが可能です 活発に開発された他のプログラムと同様に 不具合やバグが発生することがあります 問題が発生した場合は bugs.webkit.orgに ご報告いただけますと幸いです ご意見やご感想もお寄せください 私たちは常に耳を傾けています Safariの新しいCSS機能については 「What's new in CSS 」をご覧ください Managed Media Sourceを試すため 機能フラグをオンにする方法は 「Rediscover Safari developer features」をご覧ください ご視聴ありがとうございました ♪ ♪