M3Uプレイリストの作り方：自分の配信URLを登録

M3Uを作るには、利用権限のある配信URLと分かりやすい名前をプレーンテキストに記入します。UTF-8で保存し、まず1件を再生してから増やしてください。作るのは参照先の一覧であり、チャンネルのダウンロードや視聴権限の取得ではありません。

このガイドでは外部テキスト エディタを使用します。 APTV に組み込みのプレイリスト テキスト エディターが含まれていること、すべてのオプションのタグをサポートしていること、または壊れたソース アドレスを修復できることは想定していません。基本的な保存、インポート、再生のサイクルが機能するまで、ファイルのサイズを小さくしておきます。

利用許可のあるストリームを収集する

自分が所有、管理しているストリーム、またはサードパーティ プレーヤーでの使用を許可されているストリームから始めます。実際のメディアのアドレスとその使用条件については、ソースの所有者に問い合わせてください。ビデオを含む通常の Web ページは、プレイリスト エントリに必要な直接ストリーム URL である必要はありません。

各エントリについて、認識可能な表示名と指定されたアドレスを記録します。有効期限またはアクセスに関するメモは、別の個人的な記録に保管してください。アカウントのパスワードをチャンネル名に含めないでください。スクリーンショットや共有テレビ インターフェイスで目立つように表示される可能性があります。

1 つの信頼できるソースから最初のバージョンをビルドします。スクレイピングされたコレクションが大規模であるため、利用できない数十のストリームからファイル形式の間違いを区別することが困難になります。認可された情報源をまだ持っていない場合は、次のステップとしてそれを入手します。プレイリストを作成しても、不足しているメディアを提供することはできません。

最低限のプレイリストを作成する

プレーンテキストエディタを開いて、新しいドキュメントを作成します。次の元の例では、予約済みのサンプル ドメインが使用されているため、記述どおりに再生されません。そのメディア アドレスを、使用を許可されているアドレスに置き換えます。

#EXTM3U
#EXTINF:-1,Workshop Camera
https://media.example.com/workshop/master.m3u8

最初の行は拡張 M3U フォーマットを示します。 2 つ目は、カンマの後の表示名を含むエントリ情報を提供します。最後の行はメディアのアドレスです。 Live365 の基本的なプレイリスト構文は、ストリーム エントリに対してこれと同じ一般的な配置を使用します。

-1 値は、この種のディレクトリの例では通常、不明または無期限の期間に使用されます。これは、ソースが常にライブであること、無制限の再生権があること、または巻き戻しをサポートしていることを主張するものではありません。作業しているプレーヤーとソースで期待される規則を使用してください。

ストリーム URL を単独の行に含めます。エディターは、実際の改行を挿入せずに、ウィンドウ全体で長いアドレスを視覚的に折り返す場合があります。これは、URL 内で Return キーを押すこととは異なります。アドレスが分割されていると思われる場合は、保存されたテキストを調べてください。

ダウンロード可能なリファレンス フィクスチャは慎重に使用してください

バンドルされているリファレンス プレイリスト ファイルは、Apple の公開 Bip Bop HLS サンプルを参照しています。 Apple は、公式のテストストリームの例にこれをリストしています。このフィクスチャには参照のみが含まれており、コピーされたビデオや APTV チャンネル登録は含まれていません。

ソースの条件に従って、限定的な再生比較に使用してください。 APTV が所有するものではないため、ここでは実際の APTV 再生結果は主張されません。この例には、複数のメディア バリアントが含まれています。サポートはプレーヤーとデバイスによって異なります。このガイドのソース チェック後に利用可能かどうかが変更される可能性があります。

制御するストリームがある場合は、それを継続的なメンテナンス テストに使用します。自分自身のサーバーの変更と公開デモへの変更を区別できるようになります。テスト素材は、視聴者と共有する予定のコレクションとは別に保管してください。

学習用サンプルは、実際のコレクションとは別に保管してください。予約されたサンプル アドレスは実際の URL が属する場所を説明しており、ダウンロード可能な参照は外部デモンストレーションを指します。どちらも、他の人に提供するコレクションに約束されたチャンネルとして誤って表示されるべきではありません。完成したプレイリストを共有する前に、説明エントリを置換または削除してください。

ファイルを正しく保存する

エディタの保存オプションでプレーン テキストと UTF-8 を選択します。ファイルに workshop-streams.m3u などの明確な名前を付けます。エディターが .txt を追加していないか、リッチ テキスト ドキュメントを保存していないことを確認します。ファイル名は、実際に作成したファイルを説明する必要があります。

エディターがバイト オーダー マークのない UTF-8 オプションを提供している場合、それは相互運用性の観点から賢明な選択です。この推奨事項を、すべてのプレーヤーがあらゆる選択肢を拒否する証拠として扱わないでください。 HLS マニフェストのより厳格な要件と、M3U と M3U8 の広範な区別については、個別に説明します。

インポートする前に、保存したファイルを閉じて再度開きます。この簡単なチェックでは、間違った保存形式、最終行の欠落、または意図したものと異なるファイル名を検出します。コレクションに基本的な英語の文字以外の名前が含まれている場合は、アクセント付きのラベルを比較してください。

ラベルをアクセス情報から分離する

「ワークショップ カメラ」や「オリエンテーション セッション」など、コンテンツを識別できる表示名を使用します。最初の実験が終了したら、「テスト 1」のような名前は避けてください。明確なラベルは、プライベート アドレスをサポート会話にコピーすることなく、後で失敗したエントリを特定するのに役立ちます。

見栄えを良くするためにソース URL を変更しないでください。クエリ フィールド、エンコードされた文字、およびパス コンポーネントが重要になる場合があります。配布用に短いアドレスが必要な場合は、リダイレクトを考案したりパラメータを削除したりするのではなく、サポートされているアプローチについて配信元と話し合ってください。

小規模なビルド サイクルを通じて各エントリをテストする

まず、完成したプレイリストをインポートし、その 1 つのエントリを開きます。リストが表示され、予期したメディアが開始されることを確認します。インポートが成功すると、ドキュメントがディレクトリとして使用されているかどうかがチェックされます。再生が成功するかどうかは、参照されるソースとサポートされているメディアによっても異なります。

次に、URL が後に続く別の情報行を使用して、最初のエントリの下にエントリを 1 つ追加します。ファイルを保存し、文書化されたルートを通じて更新されたコピーをインポートします。新しいコピーが期待どおりに動作することが確認されるまで、古い作業ファイルを保管してください。

追加、保存、テストというサイクルを繰り返します。 100 個のアドレスを貼り付けるよりも遅く感じるかもしれませんが、各失敗に考えられる原因がいくつか示されます。エントリ 1 がまだ機能しているのにエントリ 2 が失敗した場合は、作業中のヘッダーを変更する前に新しいエントリに注目してください。

ソースの正しい動作をテストする

オーディオ ストリームは音を生成する必要があります。ビデオ画像は必要ありません。スケジュールされたライブ ソースは、営業時間外には利用できない場合があります。オンデマンド ファイルの終わりは固定である場合があります。すべてのエントリに 1 つの期待を適用するのではなく、結果をソースの目的と比較します。

エントリがインポートされても再生されない場合は、ソース アドレスとその現在のアクセス要件を確認してください。ファイル全体が拒否された場合は、ファイル形式と最新の編集内容を検査してください。これらのブランチを分離して、1 つの利用できないビデオによってディレクトリへの不必要な変更が引き起こされないようにします。

ローカル プレイリストはオフライン再生を意味しません。そのエントリがオンライン リソースを指している場合でも、それらのリソースには接続が必要です。同様に、ディレクトリを別のスマートフォンにコピーしても、アカウントのアクセス許可は転送されず、2 番目のデバイスが同じメディアをサポートすることも保証されません。

エントリを置き換える場合は、プライベート メンテナンス ノートから古いレコードを削除する前に、新しいアドレスをテストしてください。新しい場所、期限切れのトークン、修正されたラベルなど、変更された理由を記録します。このコンテキストは、後で誰かが以前のコピーが機能しなくなったと報告した場合に、計画されたメンテナンスと予期せぬ停止を区別するのに役立ちます。

ファイルを整理して維持する

コレクションを閲覧する人にとって意味のある、一貫した命名スキームを使用してください。安定したコンテキストを最初に置きます。無関係な 2 つのラベルよりも、「ワークショップ — 北カメラ」を「ワークショップ — 南カメラ」と並べてスキャンする方が簡単です。視聴者が必要としないマーケティング上の主張や技術的な詳細を名前に詰め込むことは避けてください。

group-title などの属性を使用した IPTV の例が表示される場合があります。これらは、プレーヤー固有のサポートを必要とするオプションの規則として扱います。このガイドでは、APTV によるこれらの属性の処理が確立されていないため、作業サンプルでは、自動グループやカテゴリを約束する代わりに、単純な名前を使用しています。

日付を付けた原本と、変更したURLの記録を非公開で保管してください。日付は管理記録に残せばよく、視聴者に表示するすべての名前に入れる必要はありません。配信元の有効期限が切れたら、その項目だけを置き換えて再生を確認してから更新版を配布してください。

更新情報が視聴者に届く方法を決定する

ローカル ファイルは簡単に検査して非公開で保存できますが、代替ファイルを配布するには別のインポートが必要になる場合があります。ホストされたプレイリストは安定した取得場所を提供しますが、適切なホスティングとアクセス保護も必要です。更新を便利にするためだけにログイン情報を含むファイルを公開しないでください。

自動更新を約束する前に、プレーヤーの更新動作を文書化する必要があります。 URL インポートは、アプリケーションに応じて、再度取得されたり、キャッシュされたり、別の方法で管理されたりする場合があります。すべてのプレーヤーがソースを継続的に視聴していると仮定するのではなく、実際のワークフローについて質問してください。

共有時にコレクションを保護する

共有する前に、すべてのメディア アドレスに埋め込まれたユーザー名、パスワード、トークン、プライベート ホスト名を確認してください。プレイリストは、実質的なアクセスを許可しながらも、無害に見えるほど小さい場合があります。適切なプライベート チャネルを通じて、許可された受信者とのみ共有します。

ログイン情報が誤って公開された場合は、その発行者に交換または失効について問い合わせてください。表示されているファイル名を編集しても、すでに配布されているコピーからシークレットは削除されません。トラブルシューティングの例はサニタイズされた状態を保ち、プライベート コンテンツが不要な場合は公開テスト リファレンスを使用してください。

APTV for Android で独自のサポートされているプレイリストを開き、作成時に新しいエントリをそれぞれ確認します。アプリは再生機能を提供します。あなたは認可されたストリームを提供します。機能を購入しても、期限切れのアドレスを修復したり、不足しているコンテンツを作成したりすることはできません。