日本語

ビデオと字幕 · YouTube サムネイル ダウンローダーとメタデータ ビューアー

YouTube サムネイル リクエストの仕組み: 動画 ID、サイズ名、i.ytimg.com

· 仕組み

YouTube サムネイル http

複数のサムネイル画像リクエストに分岐するビデオ識別子
オリジナル ToolAcre ベクトル イラスト

YouTube サムネイルは、ビデオ ID とサイズ名から構築された予測可能なアドレスに存在します。この投稿では、これらのリクエストがどのように形成されるか、何が返されるか、そしてツールがビデオ自体に触れることなくすべてのサイズをリストできる理由について説明します。

リンクがあり、画像が必要です - サムネイルのダウンロードの背後にある日常的なタスク

ニュースレターの編集者は多くの場合、視聴リンクから開始し、ビデオ ストリームではなく、信頼できるプレビュー画像を必要とします。各パブリック サムネイル アドレスはその ID と既知のファイル名から組み立てられるため、便利な単位は 11 文字のビデオ ID です。その ID をログに記録すると、元の共有 URL にトラッキング パラメーターやタイムスタンプ パラメーターが含まれている場合でも、編集者はすべてのサイズ チェックを 1 つのビデオに結び付けることができます。

ToolAcre は、リクエストが行われる前に、ブラウザーに貼り付けられたリンクを解析します。このローカル ステップにより、入力の理解と公開アセットの取得が分離されるため、無効なホストや不正な形式の ID は Google に連絡することなく拒否できます。したがって、リクエスト ログでは、無効な貼り付けによって i.ytimg.com エントリがまったく生成されないはずです。検証された ID のみが画像調査に進みます。

画像ホスト: i.ytimg.com — サムネイルが提供される場所と、それが youtube.com とは別である理由

画像ファイルは、視聴ページのホストではなく i.ytimg.com から取得されます。静的なポスターを画像ホスト上に保持すると、クライアントはプレーヤー、推奨事項、コメント、ページ JavaScript をロードせずに JPEG を直接リクエストできます。その結果、プレーヤーのマークアップを解釈したり、完全な再生ページが初期化されるのを待たずに、レスポンスを単独の画像として評価できます。

ダイレクト イメージ ホストは依然としてネットワーク サービスであり、ローカル処理ではありません。広告ブロッカー、オフライン モード、マネージド プロキシ、または DNS ポリシーによってリクエストを停止でき、Google はリクエストとブラウザが提供する Origin ヘッダーを受け取ります。 DevTools はリクエストの送信先を証明できる一方、レスポンスの解読により、アートワークと YouTube の小規模なフォールバックを区別するために必要な個別の証拠が提供されます。

アドレス パターン — ビデオ ID とサイズ名 (default、mqdefault、hqdefault、sddefault、maxresdefault など)

実装されたパターンは https://i.ytimg.com/vi/VIDEO_ID/VARIANT.jpg. です。ToolAcre は、ID 形状を検証した後、maxresdefault、sddefault、hqdefault、mqdefault、default、hq1、hq2、または hq3 のいずれかを置き換えます。すべての名前を調査すると、小さなフォールバックを含む 200 応答が、使用可能なアートワークを含む別のバリアントに早まって勝ってしまうのを防ぎます。

これら 8 つの名前には、5 つのポスターの選択肢と 3 つのフレーム静止画が含まれます。カタログには公称寸法と目的が記録されますが、すべてのビデオがすべてのオプション サイズを公開しているわけではないため、ブラウザーは返されたファイルを引き続きチェックします。行には、このビデオがその名前に対して実際に返した内容がレポートされます。これは、カタログが完全に入力されたアップロードに関連付けられるサイズとは異なる場合があります。

応答が証明するもの: ステータス、バイト数、デコードされた次元の組み合わせ

アウトラインでは HTTP ステータスをサイズが存在する証拠として扱っていましたが、実装ではその主張が修正されています。欠落している候補は、404、別の HTTP エラー、または YouTube の 120×90 プレースホルダーを含む成功した 200 応答である可能性があります。日付付きのレポートには、その実行時にサインアウトしたブラウザーに提供された応答がキャプチャされます。以前に同じ予測可能なパスを占めていた古いポスターを再構築することはできません。

ToolAcre はボディを Blob として読み取り、その実際の寸法をデコードします。デコードできない本体はエラーですが、より大きなバリアントの 120×90 の結果は欠落としてマークされます。したがって、ステータス、ディメンション、バイトはさまざまな証拠を表します。画像は Google から直接取得されるため、この検証により、画像を提供したサービスからの検索を秘密にすることなく精度が向上します。

動作する例: 1 つのビデオに対する 8 つの JPEG リクエストすべてを構築する

1 つの有効な ID に対して、ツールは概要に記載されている 5 つではなく 8 つの JPEG URL を構築します。 5 つのポスター名と hq1、hq2、および hq3 を調査し、カタログの順序を維持して、最大の目的のポスターが最初に考慮されるようにします。したがって、編集者は、アップロードのメインアートワークとキャプチャされた 3 つのフレーム位置を比較することができ、これらの静止画を別のポスター解像度と間違えることはありません。

あるリクエストでは 1280×720 が返され、別のリクエストでは 480×360 が返され、オプションのリクエストではプレースホルダーまたは 404 が返される場合があります。このリストでは、1 つのフォールバック シーケンスがすべてのアップロードを証明できるかのように振る舞うのではなく、それぞれの結果を報告します。この並列証拠は、古いアップロードに標準解像度のポスターが含まれていても、本物の最大解像度のファイルがない場合に特に役立ちます。

これがビデオに影響を与えない理由 — サムネイルはストリームの一部ではなく、別個の公開ファイルです

サムネイル リクエストではビデオまたはオーディオ バイトを要求することはありません。これは別の公開イメージ ファイルに対応しており、このツールにはプレーヤー トークン、メディア署名の解読、ストリーム ダウンロード パスは含まれていません。最大の候補でさえ通常の JPEG 応答であるため、これらの URL を検査しても、利用可能なメディア形式、ビットレート、再生許可については何もわかりません。

分離してもアクセスは作成されません。非公開、削除済み、年齢制限のある動画では、使用可能なサインアウト記録が公開されず、公開サムネイル規則ではこれらの制限を回避したり、YouTube が公開していないファイルを復元したりすることはできません。予測可能なパスは単なるアドレス規則です。許可と可用性は、リクエスト時にイメージ ホストが提供する内容によって決まります。

これでカバーされないもの — プライベートビデオ、地域ロックされたコンテンツ、最後に閲覧してから変更されたサムネイル

変更されたサムネイルは別の境界です。予測可能な URL は、過去のリビジョンではなく、現在提供されている画像を参照します。リージョン ポリシーとサインアウトの可用性も、訪問者が検索時に取得できる内容に影響を与える可能性があります。再設計後に同じパスをリクエストすると、変更されていない URL で異なるピクセルが返される可能性があるため、キャンペーンを文書化する人はダウンロードした画像に日付を付ける必要があります。

サムネイル プローブは、ネットワーク経由、成功しない HTTP 応答、200 プレースホルダー経由、または本文が画像としてデコードできないために失敗する可能性があります。インターフェイスはこれらの障害クラスを区別して維持するため、不在が誇張されることはありません。プロキシの中断では再試行が必要ですが、デコードされた 120×90 プレースホルダーは、要求されたより大きなバリアントが配信されなかったことを具体的に示しています。

要点: 事前に発表される予測可能なアドレス — YouTube サムネイル ダウンローダーがリンクのすべてのサイズをリストする方法

解析はフェッチの前に行われます。フェッチの後、ブラウザは、リファラーやストア キャッシュを使用せず、匿名の認証情報を使用しない GET リクエストを送信し、その後 i.ytimg.com と www.youtube.com に直接リダイレクトします。 Google はこれらのリクエストと Origin ヘッダーを認識しますが、それらの間に ToolAcre サーバーやプロキシは存在しません。したがって、DevTools ではブラウザから Google に向かう画像トラフィックが表示されるはずですが、貼り付けられたビデオ ID を運ぶ ToolAcre API 呼び出しは表示されません。

付随する oEmbed ルックアップでは、同じ ID と format=json を含む正規の監視 URL が使用されます。ネットワーク、HTTP 応答、または無効な JSON によって失敗する可能性があり、どちらのリクエストもプライベート、削除済み、または年齢制限のあるマテリアルを取得しません。サムネイルの証拠とメタデータの証拠は分離されたままです。構造化レコードが失敗し、どちらのブランチも永続的なアクセスが証明されない場合でも、JPEG を利用できます。