ブログに戻る

動画の画質が再生中に変わるのはなぜ?アダプティブビットレートストリーミング解説

アダプティブビットレートストリーミング(ABR)は、接続が維持できる画質レベルを選ぶロジック。YouTube・Netflix・Twitchが次に送るものをどう選ぶかを平易な日本語で解説します。

By

YouTube動画の途中で、絵が突然鮮明からぼやけたものに変わります。数秒後、また登り戻します。何のコントロールにも触れていません。隅のWi-Fiアイコンも問題なさそうです。今、何が起きたのでしょうか?

あなたはアダプティブビットレートストリーミングアルゴリズムが目の前で仕事をしているのを見ました。現代のあらゆるストリーミングプレーヤーの裏側には、ネットワークを計測し、その数値をサービスが用意した事前エンコード済みの画質バリアントメニューと比較し、計算が指示するときに静かにそれらの間で切り替える静かなループがあります。接続が揺れれば、プレーヤーは再生を停滞させないように小さなバリアントへ切り替えます。接続が回復すれば、登り戻します。ほとんどの場合、あなたは気づきません。気づくときは、切り替えが見えるほど大きかった時です。

アダプティブビットレートストリーミング(ABR)は、同じ動画の事前エンコード済み画質バリアント間を切り替え、各セグメントで接続が維持できる最高のバリアントを選んで、乱雑な現実のネットワークでも再生を流し続けるために現代のプレーヤーが使う技術です。

このガイドでは、画質が再生中にシフトする瞬間に実際何が起きているのかを順に追います。サービスが同じタイトルの複数バリアントをどうエンコードするか、プレーヤーが帯域をどう計測し次に取得するものをどう決めるか、なぜアルゴリズムにはBOLAやMPCのような名前があるのか、実世界でABRに出会う場所、そしてこのように再生されている動画を保存したいときに意味することを見ていきます。

重要ポイント {#key-takeaways}

  • ABRはアダプティブストリーミングプレーヤー内のビットレート切り替えロジック。 アダプティブストリーミングはより広いパターン(HLS・DASH)で、ABRは次にどのバリアントを取得するかを選ぶ具体的なアルゴリズム。
  • サービスは各タイトルを複数のビットレートで事前エンコードする — 1080p@5Mbps・720p@2.8Mbps480p@1.4Mbps・360p@800Kbpsのような「エンコードラダー」。マニフェストはラダー全体をプレーヤーに見せる。
  • 切り替えはセグメント境界で起き、セグメント中では起こらない。 プレーヤーは2〜10秒ごとに別のバリアントを選べる。セグメントの中ほどでバリアントを変えることはできない。
  • 帯域推定は思ったより難しい。 プレーヤーは直近数セグメントのダウンロードのスループット、バッファレベル、またはその両方を使う。BOLA・MPC・dynamicなどのアルゴリズムがこれらの信号を組み合わせる。
  • コールドスタートは意図的に保守的。 帯域履歴がない状態で、プレーヤーは速く再生を始めるために低いバリアントを選び、実測ができたら登る。
  • ライブABRは同じモデルでバッファが薄い。 ライブプレーヤーは小さなバッファで動き、低いバリアントを受け入れる。ライブのエッジから遅れる方が画質を1段落とすより悪い。
  • ABRストリームを保存するということは、1つのバリアントを意図して選ぶこと。 プレーヤーが再生中に切り替えると、ディスク上のバイトは縫い合わされたハイブリッドになり、クリーンコピーとしては使えない。

シンプルな説明

渋滞のある道路を運転していると想像してください。常に80キロでは走れません。50のときもあれば、徐行のときもあります。1つの速度を選んで固定するのではなく、絶えず前方の道路を確認して調整します。ABRはあなたの動画プレーヤーが、インターネットの「速度」を絶えず確認し、今この瞬間に接続が維持できる画質レベルへ切り替えているのです。

道路のアナロジーはよく成り立ちます。ストリーミングサービスはすでに同じタイトルを6種類くらい異なる「速度」(小さな360pストリームから巨大な4K HDRストリームまで、画質バリアントの範囲)でエンコード済みです。プレーヤーは手元にメニュー全体を持っています。数秒ごとに「今どれくらい帯域があるか、バッファはどれくらい満たされているか、次にどのバリアントを取るべきか」と問います。

視聴者の席から見ると、これは多くの作業を隠しています。Wi-Fiが揺れたときのスムーズなフォールバック — プレーヤーはバッファが枯れる前にラダーを1、2段下げるので、ローディングアイコンの代わりに短い画質の落ち込みが見えるだけです。帯域が再び開いたときの回復 — プレーヤーは次の数セグメントで登り戻します。**画質の「コールドスタート」**は最初の10秒だけぎこちなく低く感じられることがありますが、それは接続が実際に何をできるかわかるまでプレーヤーが意図的に保守的でいるからです。

要点は、最高画質を見つけて固定することではありません。要点は、再生を絶対に止めないことです。ABRは根本的に信頼性技術であって、達成できる最良画質を選ぶことは副作用です。設計全体がインターネットは乱雑で、あなたとCDNの間の接続は不行儀に振る舞う、と想定しています。そしてこの想定こそが、現実のネットワーク越しにストリーミングが成立する理由です。これがより大きなストリーミングパイプラインのどこに収まるかについては、兄弟記事が端から端までカバーしています。

ABRは実際どう動くのか

ABRプレーヤーは各セグメントでタイトなループを走らせます。帯域を計測、持続可能なものを推定、バリアントを選択、取得、デコード、繰り返し。 各ステップの裏には数十年の現実のエンジニアリングがありますが、ループ自体は小さなものです。

エンコードラダー

動画がCDNに届く前に、サービスは同じタイトルを複数のビットレート・解像度の組み合わせで事前エンコードします。バリアントの集合はエンコードラダーと呼ばれ、典型的なウェブのラダーはこんな形です。

解像度ビットレートコーデック
1920x10805.0 MbpsH.264
1280x7202.8 MbpsH.264
854x4801.4 MbpsH.264
640x3600.8 MbpsH.264
426x2400.4 MbpsH.264

プレミアムサービスはこの段数を2倍にすることもあります。上に4K HDRバリアント、新しいクライアント向けにH.264と並行して走るAV1またはH.265のラダー、それに別個の音声のみレンディションが加わるなど。すべてのバリアントは同じソースコンテンツを、異なる画質目標で独立にエンコードしたものです。ラダーはまた、バリアントごとに異なるコーデックを含めることもでき、新しいデバイスがより効率的なエンコードを得て、古いデバイスがH.264フォールバックを得るようにできます。

マニフェストがラダーを露出する

プレーヤーは、サービスが再生開始時に配信する小さなテキストファイル(マニフェスト)を取得することでラダーを知ります。主流のマニフェスト形式2つは、同じラダーの概念を異なる構文で記述します。HLSでは、マスタープレイリストがバリアントごとに1行の#EXT-X-STREAM-INFを使います。

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080,CODECS="avc1.640028,mp4a.40.2"
1080p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2800000,RESOLUTION=1280x720,CODECS="avc1.4d401f,mp4a.40.2"
720p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1400000,RESOLUTION=854x480,CODECS="avc1.4d401e,mp4a.40.2"
480p/index.m3u8

DASHでは、同じ情報がAdaptationSetにネストされたRepresentation要素の中、bandwidthwidthheightcodecs属性として存在します。構文は違っても仕事は同じです。HLSのマスタープレイリストがバリアントを露出する仕組みDASHがRepresentationでバリアントを定義する仕組みで詳細を並べて見られます。どちらにせよ、プレーヤーは宣言された帯域と、より詳細なメディアプレイリストやセグメントテンプレートへのURLを伴うバリアントのリストを手にします。

帯域推定

プレーヤーはネットワークに容量を尋ねることはできません。推測しなければなりません。2つの信号が支配的です。

  • ダウンロード時間ベースの推定は、直近数セグメントについて到着バイト数とかかった時間を計測します。6MBのセグメントが2秒で来たなら、約24Mbpsのスループットを示唆します。直近3〜5ダウンロードの調和平均などの移動平均が、単一のノイズサンプルを均します。
  • バッファレベルベースの推定はバッファを監視します。バッファが伸びていればネットワークは余裕で再生を上回っており、縮んでいれば生のスループットが良く見えてもネットワークは追いついていません。次のセグメントが遅いCDNキューに乗っているのかもしれません。

現代のプレーヤーは両方を使います。純粋なスループット推定は高速なネットワーク変化に反応しますが、1つの遅いセグメントに過剰反応することもあります。純粋なバッファベース推定は安定的ですが反応が遅いです。両方をブレンドすると、速く行儀の良い信号が得られます。

切り替えアルゴリズム

帯域推定があれば、それをバリアント選択に翻訳しなければなりません。いくつかの名前付きアルゴリズムが現場を支配しています。

  • スループットベース(オリジナルのアプローチ) — 安全マージン調整後の推定値に収まる最高のバリアントを選ぶ。シンプル、高速、ノイズに敏感。
  • BOLA(Buffer Occupancy-based Lyapunov Algorithm) — 2016年に発表されたバッファベースのアルゴリズム。バッファの満たされ度合いに基づいて判断します。バッファが健康な間、BOLAは現在のバリアントを保持し、バッファが下がったときだけ落とします。これによりノイズの多いネットワークでの無用な画質振動を避けます。
  • MPC(Model Predictive Control) — スループット推定値、バッファレベル、切り替え自体のコスト関数を組み合わせて、短い予測ホライズンにわたって予測される停滞と目に見える画質変化の合計を最小化するバリアントを選ぶハイブリッド。
  • dash.js dynamic — オープンソースのdash.jsプレーヤーのデフォルトで、スループットとバッファの信号をブレンドし、最近のネットワーク挙動に基づいて調整します。

差は不安定な接続で効いてきます。スループットのみのアルゴリズムは、1つの遅いセグメントを見てパニックを起こし、2段落とすかもしれません。BOLAはバッファがまだ問題ないなら安定を保つかもしれません。エンジニアリングの好みは様々ですが、ほとんどの本番プレーヤーは調整されたMPCバリアントまたはdynamicハイブリッドを配信します。

切り替えはセグメント間で起こる

プレーヤーはセグメント中にバリアントを変えることはできません。1080pバリアントからsegment042.tsをダウンロードし始めたら、そのセグメント全体はロックインされます。ネットワークが突然徐行になっても、480pへの切り替えは早くてもsegment043からです。これがセグメント長が本当の調整パラメーターである理由です。短いセグメント(2秒)はプレーヤーに切り替えチャンスを多く与え、ネットワーク変化への反応を速くしますが、HTTPリクエスト数とオーバーヘッドが増えます。長いセグメント(10秒)は効率的ですが、ABRが遅くなります。

コールドスタート対定常状態

再生を押した瞬間、プレーヤーには帯域履歴がありません。最初のバリアント選択は本質的に推測です。ほとんどのプレーヤーは保守的に推測します。即座の停滞を避けて速く再生を始めるために、最低またはそれに近いバリアントを選びます。最初の1、2セグメントが届くと、プレーヤーは実測のダウンロード時間を持ち、登れます。これが動画の最初の数秒がしばしば残りより明らかに見栄えが悪い理由です。設計通りに動作しているABRのコールドスタートです。前のセッションの帯域やネットワークタイプのヒントから始めるサービスもありますが、保守的なコールドスタートがデフォルトのままです。

ライブ対VODのABR

ライブストリームは同じABRループを走らせますが、1つの重要な違いがあります。バッファを無制限に伸ばせないのです。VODプレーヤーは30〜60秒先を快適にバッファできます。ライブプレーヤーは5〜15秒程度、それ以上はライブのエッジからさらに遅れます。小さなバッファはABRに、より速く反応し、より積極的に低いバリアントを受け入れるよう強制します。悪いセグメントを吸収する余裕が少ないからです。低遅延HLSとDASHはこれをさらに進め、チャンクベース配信でプレーヤーがより薄いバッファで作業できるようにします。

これらの判断はそれぞれ、あなたがただ再生ボタンを押した場合にプレーヤーがあなたのために行うことです。代わりにクリーンなファイルを持ち帰りたい場合は、これらの判断のいくつかを自分でしなければなりません。そこにVidMostが登場します。マニフェストを解析し、絶えず切り替える代わりに正しいバリアントを1回選びます。

実世界でABRを目にする場所

2026年のあらゆる主要ストリーミングサービスはABRを走らせており、違いはチューニングであって、するかどうかではありません。

  • YouTubeはABRを最も目に見えやすく示しています。画質メニューに「Auto」と特定バリアントのリストがあります。AutoはYouTubeのハイブリッドアルゴリズムによるABRが走っている状態で、特定バリアントを手動で選ぶとそれにプレーヤーをピン留めし、安全網を無効にします。ブラウザ開発者ツールのネットワークタブで、その瞬間にアルゴリズムが選んだバリアントからのセグメントリクエストを見られます。
  • Netflixは業界で最も研究されたABRスタックの1つを、コンテンツ認識エンコーディングと組み合わせて走らせます。万能なラダーを使う代わりに、Netflixは各タイトルのラダーをそのコンテンツに合わせて調整します。動きの少ないドラマは、エンコーダーが同じ知覚品質に達するためにより少ないビットしか要らないので、速いアクション映画とは違うラング集合を得ます。結果としてタイトルごとに最適化されたラダーになります。
  • Twitch・Bigo Liveなどのライブプラットフォームは、レイテンシを低く保つために攻撃的な低バッファABRを走らせます。プレーヤーは小さなバッファとより速いバリアント低下を受け入れます。ライブチャットの文脈で30秒のバッファは、アクションから30秒遅れることを意味するからです。配信者と視聴者の両方が気づきます。
  • モバイル対デスクトップは挙動が違います。モバイルプレーヤーは通常、Wi-Fiとセルラーが有線接続より予測不能なので、低く始めてゆっくり登ります。デスクトップとTVのプレーヤーは安定した接続性を想定して速く登ります。
  • Apple TVとスマートテレビは通常、登るのに最も攻撃的です。安定したWi-Fiまたは有線イーサネットを想定し、防御的でいる気がありません。これがTV上のNetflixストリームが、しばしばノートパソコンの同じタイトルより鮮明に見える理由です。アルゴリズムが高めに始めて速く登ったのです。
  • VRと360度ストリーミングはABRの限界を新しい方向に押します。360度動画は通常のフラット動画よりはるかに多いピクセル数を持ちますが、任意の瞬間に視聴者は小さなビューポートしか見ません。タイルベースABRはパノラマをタイルに分解し、見ているタイルだけを高画質でストリームし、残りを低く保ちます。古典的なABRとは別の問題ですが、複数バリアントをエンコードして選ぶという哲学は同じです。

コンシューマーサービスの先では、ホスト型動画プロバイダー(Cloudflare Stream・Mux・Bitmovin・JW Player・Vimeo)がABR対応プレーヤーをデフォルトで配信します。ウェブサイトがそうしたサービスから動画を埋め込めば、誰も口に出さなくてもABRが起きています。

動画を保存したい場合に意味すること

ここでABRは人々が驚く問題を生みます。「Auto」でストリームを視聴すると、ブラウザのネットワークタブには混在ダウンロードが映ります。一部のセグメントは1080pから、一部は720pから、Wi-Fiが点滅した瞬間に480pを少し経由しているかもしれません。視聴中に実際にディスクに当たるバイトは、複数バリアントを縫い合わせたハイブリッドです。「視聴したもの」を保存することは不可能です。なぜなら視聴したものは1つのものではなかったからです。

クリーンで一貫した画質のコピーを得るには、1つのバリアントを意図して選び、そのバリアントのセグメントだけを取得しなければなりません。つまり、マニフェストを解析し、利用可能な最高帯域のバリアントを識別し、ABRループを完全にバイパスする。切り替えを依頼せず、最上段からすべてのセグメントをダウンロードするだけです。ブラウザ拡張と「右クリックで保存」はこれをしません。マニフェストのテキストファイル(材料のないレシピ)を保存するか、プレーヤーがたまたま取得したセグメントを捕捉します。これは欲しくないハイブリッドの混沌です。

VidMostはこれを直接扱います。マニフェストを読み、サービスが提供する最高帯域のバリアントを選び、その1つのバリアントから一貫した画質のセグメントをダウンロードします。Wi-Fiが点滅した瞬間の480pのスライスではなく、タイトルの完全な1080p(利用可能なら4K)バージョンに行き着くわけです。DRM保護コンテンツについては、エンコードラダーは依然として存在し、キーがライセンスサーバーの背後にゲートされているだけです。VidMostの組み込みWidevine L3サポートはL3再生が利用可能な範囲で動作します。ただし、実際の上限はサービスとDRMレベルによって設定され、NetflixやDisney+のようなプレミアムプラットフォームはABRラダーが何を提供しようと、L3ストリームを480p〜720pに制限するのが一般的です。

よくある落とし穴と誤解

ABRに関する誤解は、フォーラムスレッドで何度も繰り返し出てきます。整理する価値があります。

  • 「高い帯域は良い画質を意味する。」 帯域が安定している場合に限ります。1分間に2秒だけ1Mbpsに落ちるスパイキーな100Mbps接続は、安定した5Mbpsの回線よりABRには悪いです。アルゴリズムが高いバリアントを保持する代わりにノイズに反応することに時間を使うからです。安定性はピーク速度より重要です。
  • 「切り替えは常にバッファリングを引き起こす。」 違います。現代のプレーヤーはセグメント境界で見えずにバリアント間を切り替えます。画質シフトは見えても停滞は見えません。スピナーはバッファが次のセグメント到着より速く尽きたときにだけ現れるもので、それはまさにABRが防ごうとしていることです。
  • 「ABRはアダプティブストリーミングと同じ。」 近いけれど同じではありません。アダプティブストリーミングはより広いパターン(マニフェスト・セグメント・HTTP配信)で、HLSとDASHが体現しています。ABRは具体的に、アダプティブストリーミングプレーヤー内のビットレート切り替えロジックです。あらゆるHLSやDASHプレーヤーはABRアルゴリズムを走らせます。アダプティブストリーミングがそれを可能にし、ABRが選ぶ仕事をします。
  • 「画質を1080pに手動で設定するとABRを上書きできる。」 できますが、安全網を無効にします。不安定な接続では1080p固定は、ネットワークがビットレートを維持できないたびに再バッファを意味します。ABRが存在するのはネットワークが信頼できないからで、画質を固定してもネットワークは直りません。結果が見えるようになるだけです。
  • 「バッファは帯域の無駄。」 違います。30秒のバッファは、20秒のWi-Fi断絶を越えてあなたを見続けさせるものです。バッファはアルゴリズムの安全マージンで、健康なストリームとイライラするストリームの違いは、通常、バッファが一時的なネットワーク問題を吸収できるほど深かったかどうかで決まります。

結びに

ABRは、動いているときには消えるテクノロジーの1つです。あなたが気づくのは、画質シフトが見えるほど大きいか、バッファが枯れてスピナーが現れるときだけです。ほとんどの時間、それは静かに走っています。プレーヤーが取得するセグメントの各ペアの間で、計測し、判断し、切り替えながら。

マニフェスト内のエンコードラダーと、プレーヤーが各セグメントで走らせる帯域・判断・取得ループを認識できるようになると、多くのストリーミング挙動の謎が消えます。コールドスタートのぼやけは意図的な保守的推測。再生中の画質ジャンプは停滞を避けるプレーヤー。「視聴したもの」のコピーを保存するのが難しい理由は、視聴したものがそもそも1つではなかったから。

プロトコルレイヤーを完全に飛ばして、最高画質のバリアントを一度に保存したい場合、VidMostはマニフェストを解析し、最上段を選び、それをクリーンにダウンロードします。

関連する読み物

よくあるご質問

アダプティブビットレートストリーミングとは何ですか?
アダプティブビットレートストリーミング(ABR)は、視聴中に同じ動画の事前エンコード済み画質バリアントを切り替えるために、現代の動画プレーヤーが使う技術です。サーバーはタイトルを複数のビットレート(たとえば5Mbpsの1080p、2.8Mbpsの720p、1.4Mbpsの480p)でホストします。プレーヤーは帯域とバッファレベルを計測し、新しいセグメントごとに接続が維持できる最高のバリアントを選びます。ネットワークが変われば、プレーヤーは再生を再起動することなく次のセグメント境界で別のバリアントに切り替えます。
YouTubeの動画の画質がころころ変わるのはなぜですか?
YouTubeがAutoに設定されていると、ABRアルゴリズムが走っています。プレーヤーは短い動画セグメントをダウンロードし、到着の速さを計測し、接続が追いつける最高のバリアントを選びます。Wi-Fiが一時的に遅くなれば、次のセグメントは低画質バリアントから取得され、回復すれば再び戻ります。目に見える画質ジャンプは、プレーヤーがバッファアンダーランを避けている瞬間です。手動で1080pに固定するとこの安全網が無効になるので、不安定な接続では再バッファになります。
動画が最初にぼやけて後で鮮明になるのはなぜですか?
再生開始時、プレーヤーには帯域履歴がありません。即座の停止を避けて速く始めるために、保守的なバリアントを選びます。最初の数セグメントが届くと、プレーヤーは実測のダウンロード時間を計測し、想定より帯域があると気づき、次のセグメント境界でより高いバリアントに切り替えます。動画の最初の5〜15秒は、しばしばストリーム全体で最も見栄えの悪い部分です。これは元素材の問題ではなく、ABRのコールドスタートです。
アダプティブストリーミングを無効化できますか?
ある意味で可能です。YouTube・Netflixの開発者オプション・Twitchなど、ほとんどのプレーヤーUIは画質を特定のバリアントに固定できます。これはABRロジックに「あなたに代わって選ぶのをやめろ」と伝えるものです。代償は本物です。720pしか維持できない接続で1080pに固定すれば、バッファが枯れるたびに再バッファが起きます。ABRが存在するのはネットワークが信頼できないからで、それを切ってもネットワークは信頼できるようになりません。ただ結果に対してプレーヤーが正直になるだけです。
Netflixはなぜ私の回線が扱える以上に低い画質を選ぶのですか?
NetflixのABRは意図的に保守的です。アルゴリズムは実測スループット・バッファレベル・ジッターのための安全マージンを勘案し、加えてDRMセキュリティレベルに基づいて最大ビットレートをキャップします。Widevine L3のデスクトップブラウザでは、Netflixは接続がどれだけ速くても720pを超えて配信しません。Netflixのコンテンツ認識エンコーディングもタイトルごとにラダーを個別に調整します。動きの少ないドラマは、同じ知覚品質に達するためにエンコーダーがより少ないビットしか要らないので、アクション映画より低いビットレートで頭打ちになる場合があります。
バッファリングはABRの切り替えと同じですか?
いいえ、関連はしていますが同じではありません。ABRの切り替えは見えません。プレーヤーは次のセグメント境界で別のバリアントに替わり、あなたは見続けます。バッファリングは、次のセグメントが届く前にバッファが空になったときに見えるもので、プレーヤーが待つ間に再生が停止します。現代のABRはまさにこれを避けるために、バッファが枯れる前に小さなバリアントへ落とすよう設計されています。スピナーが見えるとき、それは通常、アルゴリズムが反応するより速くネットワークが落ちたことを意味します。
最初の数秒がいつも悪く見えるのはなぜですか?
再生を押した瞬間にプレーヤーには帯域データがないので、速くスタートするために低いバリアントを選ぶからです。代替案(1080pを楽観的に選んで10秒間バッファを満たすために停滞する)はユーザー体験としてはるかに悪いです。ほとんどのABRアルゴリズムは意図的に最低またはそれに近いバリアントでコールドスタートし、最初の数セグメント内に登ります。前のセッションのデータや信号強度のヒントを使って高めに始めるサービスもありますが、保守的なコールドスタートが正当な理由でデフォルトのままです。
ABRはライブストリームでも動きますか?
はい、より厳しい制約のもとで動きます。ライブABRはVODと同じエンコードラダー・マニフェスト・セグメントモデルで走りますが、バッファがはるかに小さく(時には数秒だけ)動きます。バッファを積み上げるとライブのエッジから遅れることになるからです。これによりアルゴリズムはより速く反応し、ネットワークが揺れるときには低い画質を受け入れる必要があります。低遅延HLSとDASHのバリアントは、部分セグメントとチャンクベース配信を使い、ABRの判断を遅く・悪くせずにバッファを薄く保ちます。