用語集

ストリーミングとIPTV

インターネット越しのライブテレビは、放送・Web・そして偶然標準になった1つのパネルソフトウェアという3つの異なる場所から語彙を借りてきました。ここではよく出てくる言葉をまとめます。

HLS

HTTP Live Streaming

Appleのストリーミングプロトコルで、ほぼすべてがこれを使っています。映像はテキストのプレイリストに列挙された短いセグメントに切り分けられ、プレーヤーは通常のHTTPでそれらを順番に取得します。

HLSが普及したのは特別なサーバーを必要としないからです——セグメントもプレイリストもただのファイルで、どんなWebサーバーでも両方配信できます。Appleのプラットフォームではどこでもネイティブに対応しており、それ以外でもほぼどこでも対応しています。

この設計には人が必ず出会う帰結が一つあります——保存すべき1本の動画ファイルというものが存在しないのです。今見ているものは、千個の断片と、それらを取得するための一連の指示としてしか存在しません。

以下も参照してください。 マニフェストセグメントアダプティブビットレート

マニフェスト

プレイリスト、.m3u8

ストリームの構成を列挙したテキストファイル。マスターマニフェストは利用可能な画質レベルを列挙し、それぞれが実際のセグメントを列挙するメディアマニフェストを指します。

開いてみると数十行しかありません——ヘッダー、いくつかのパラメーター、そしてアドレスの列です。実際に視聴する中身は別の場所にあります。ライブ放送の場合、放送が続く限りこのファイルは伸び続けるため、プレーヤーは数秒ごとにこれを取得し直します。

マニフェストのアドレスはたいてい署名付きで期限があり、今朝は使えたリンクが午後には何も指さなくなっていることがよくあるのはこのためです。

以下も参照してください。 HLSセグメント

セグメント

チャンク

ストリームの短い一部分で、通常2〜10秒。それぞれが独立したファイルとして配信されます。1時間の動画なら数百から数千個になります。

セグメント化のおかげで、再生中の画質切り替えが可能になっています——プレーヤーは単に別の画質レベルから次の断片を要求するだけで、その切り替えは中断としてではなく区切りとして起こります。

これはまた、ストリームのダウンロードが単純なコピーではなく再構築になる理由でもあります。すべてのセグメントを取得し、適切なインデックスを持つ1つのコンテナへ書き込む必要があります——この工程があってはじめて、シークバーがまともに機能する結果が得られます。

以下も参照してください。 HLS再多重化

アダプティブビットレート

ABR

同じコンテンツを複数の画質レベルで提供し、接続状況の変化に応じてプレーヤーがその間を行き来できるようにすること。ストリームが止まるのではなく画質が下がる形で耐えるのはこのためです。

プレーヤーはセグメントの到着速度を計測し、維持できると判断した最も高い画質を選びます。接続が細くなると、たいていバッファーが尽きる前に画質を落とします。

これがストリーミング視聴とファイルのダウンロードとの最大の違いです。ダウンロードは最良のバージョンを求めて待ちますが、ストリームは一時停止するくらいなら画質を落とすことを選びます。

以下も参照してください。 HLSバッファリングビットレート

バッファリング

プレーヤーが今見ている位置より数秒先の映像を保持しておくことで、一瞬のネットワークの乱れが再生の停止につながらないようにする仕組み。この言葉が画面に表示された時点で、そのバッファーは尽きています。

バッファーを大きくすると、より多くの乱れを乗り越えられる一方、再生開始までの時間が長くなり、チャンネル切り替えへの反応も遅くなります。ライブストリームは意図的にこれを小さく保っており、これがオンデマンド動画より壊れやすい理由です。

IPTVのチャンネルがカクつくとき、原因はほぼ常にプロバイダーとあなたの間のどこか——相手のサーバー、経路、あるいはあなたの回線です。同じデバイスの同じアプリで、同じビットレートのローカルファイルを再生すればまったく問題なく再生できる、というのが両者を見分ける最も手早い方法です。

以下も参照してください。 アダプティブビットレートIPTV

IPTV

電波やケーブル、衛星ではなくインターネット経由で配信されるテレビ。この言葉自体は配信方式を表すだけで、誰が何を配信する権利を持つかについては何も語りません。

実際に契約として渡されるのは一覧です——M3Uプレイリスト、あるいはパネルのアカウント——チャンネル名とそれぞれのアドレスが記されています。プレーヤーはそれをチャンネルガイドに変換するだけで、何かをホストしたり供給したりはしません。

これは技術的な話であると同時に、法的にも重要な点です。IPTVを再生するアプリはチャンネルを一切同梱しておらず、あるプロバイダーが配信している内容を配信する権利を持っているかどうかは、そのプロバイダーに関する問題です。

以下も参照してください。 M3UプレイリストXtream CodesEPG

M3Uプレイリスト

チャンネル名とストリームアドレスのプレーンテキストの一覧で、IPTV契約が届く最も一般的な形。動画は一切含まれていません。

各項目はチャンネル名を記した1行——慣習でロゴやグループ、識別子が付くこともあります——と、そのアドレスを記した1行で構成されます。これらの慣習は一度も標準化されておらず、プロバイダーごとに書き方が微妙に異なります。

プロバイダーの一覧はこの形式が想定していた規模をはるかに超えて肥大化しています。数十万チャンネル、数百メガバイトのテキストは今や普通のことで、解析前にファイル全体をメモリへ読み込むアプリは、終わるよりずっと前にiOSに強制終了させられます。

以下も参照してください。 IPTVXtream Codes

Xtream Codes

そのAPIが事実上の標準になったパネルソフトウェア。プレイリストファイルの代わりにサーバーアドレス・ユーザー名・パスワードを受け取り、アプリはパネルにチャンネル・映画・シリーズ・ガイドを問い合わせます。

開発元の企業は2019年に閉鎖されましたが、APIはそれより長生きしました。すでに何千ものプロバイダーがそれを基盤に構築しており、利用者もそれを前提にしていたからです。「Xtream対応」と説明されるソフトウェアは、その企業の製品を使っているのではなく、そのインターフェースを実装しているだけです。

単純なプレイリストとは2つの点で異なります。カタログが平坦な一覧ではなく構造化データとして届くこと、そしてパネルが接続数の上限を強制することです——これが原因で、ダウンロードとライブ視聴を同時に行うと互いを弾き出すことがあります。

以下も参照してください。 IPTVM3UプレイリストEPG

EPG

電子番組ガイド

番組表——各チャンネルで今何をやっていて、次に何が来て、以前は何をやっていたか。チャンネル自体とは別に、通常はXMLTVファイルとして配信されます。

ガイドは、プロバイダーが各チャンネルに付与する識別子によってチャンネルと紐づけられます。この識別子が欠けていたり一貫していなかったりすると(よくあることですが)、ガイドのデータ自体は存在し正しいにもかかわらず、チャンネルには番組情報が何も表示されません。

大手プロバイダーの完全なガイドは、それ自体がかなりの容量のダウンロードになります。数千チャンネル分の、数日先までのスケジュールを含むからです。

以下も参照してください。 IPTVキャッチアップXtream Codes

キャッチアップ

タイムシフト、アーカイブ

プロバイダーのサーバーに、あるチャンネルの過去の時間帯を問い合わせることで、すでに放送された番組を視聴すること。プロバイダーが録画している場合にのみ存在し、デバイス側には何も保存されません。

提供されている場合、アプリはガイド上の過去の番組を、そのチャンネルのその時間帯へのリクエストに変換できます。一般的なアーカイブの保持期間は数日です。

これは完全にプロバイダー側の機能です。アプリは何もない状態のチャンネルにキャッチアップを追加することはできず、先週分のガイド情報があるからといって、その録画が実際に存在する証拠にはなりません。

以下も参照してください。 EPGIPTV

DRM

デジタル著作権管理

ライセンスサーバーから取得した鍵を使い、正規のライセンスを持つ再生ソフトウェアだけが解除できる暗号化。Appleプラットフォームでは FairPlay、Androidやほとんどのブラウザでは Widevine が該当します。

DRMで保護されたストリームは端から端まで暗号化されており、鍵は付随するルール(保存不可、キャプチャ不可、時には外部出力も不可)を守ると証明したソフトウェアにしか渡されません。

これは回避すべき不都合ではなく、仕組みが正しく機能している証拠です。DRM保護されたストリームをダウンロードできると謳うツールは、自分がしていることかそのストリームの性質のどちらかについて、事実と異なることを述べています。

以下も参照してください。 HLSIPTV

その他の科目